Hindi pare-pareho ang wallet popup: alamin kung ano talaga ang hinihingi

Paano mabilis na makikilala ang uri ng wallet request?

Tingnan kung may gas, readable message, spender, asset change o contract call. Karaniwang walang gas ang simpleng address connect. Hindi agad napupunta sa block ang message signature. On-chain transaction ang approve at transfer. Maaaring walang gas sa pag-sign ng permit ngunit puwedeng isumite ito ng ibang tao para buhayin ang allowance.

Iba-iba ang wording ng bawat wallet. Buksan ang “Details,” “Data,” “Permission” o “Advanced.” Kapag hindi ipinapakita ang mahalagang field, hindi sapat na ebidensiya ang reassurance ng mismong website. Hindi nawawala ang lehitimong asset kapag ni-reject ang request; maaari mong simulan muli mula sa official flow.

May request sa wallet — puwede ba itong pirmahan?

Magdesisyon ayon sa aktuwal na nakasulat sa popup, hindi sa label ng button sa website. Sa table sa ibaba, may dalawang kondisyon ang bawat “puwede”: ang domain sa address bar ay binuksan mo mula sa official website o docs, at talagang kailangan ang hakbang na ito sa ginagawa mo ngayon. Kapag hindi natupad ang kahit isa, ituring itong reject.

Walang mawawalang asset sa pag-click ng Reject o Cancel, at hindi ka aalisan ng eligibility ng lehitimong project; buksan lang ulit ang page mula sa official link. Kung hindi sigurado, magtanong sa public support channel na nakasulat sa docs ng project, dala ang screenshot ng popup (takpan ang balance); huwag sagutin ang nag-aalok ng “tulong” sa DM.

Ano ang nakikita ng website kapag nag-Connect Wallet ka?

Karaniwang nakikita nito ang piniling public address, active chain at kakayahan ng wallet; hindi pa ito spending approval. May privacy cost pa rin. Public ang transaction history at maaaring iugnay ng site ang address sa browser session, social login o campaign profile.

Nakakabawas ng hindi kailangang exposure ang hiwalay na testnet wallet. Unawain ang kaibahan ng isa pang account sa parehong seed at wallet na may ganap na bagong seed. Hindi awtomatikong nakikita sa chain ang relasyon ng parehong seed, pero maaaring mabuo ang link mula sa transfers at paggamit. Iwasang ikonekta ang high-value wallet sa hindi kilalang task page.

Ituring na bagong request ang bawat popup pagkatapos ng connect. Madalas na pattern sa phishing ang harmless connection muna, tapos approve o permit kapag nakasanayan nang mag-confirm ng user. Hindi ginagawang safe ng unang popup ang pangalawa. Kapag sunod-sunod ang request, kanselahin at basahin ang expected steps sa official docs.

Ang pag-disconnect sa Connected sites ay nagtatapos sa front-end session, hindi sa on-chain approval. Hindi rin nabubura ang allowance sa pag-clear ng browser history, pag-lock ng wallet o pag-reinstall ng extension. Magkaiba ang privacy connection at blockchain permission.

Kailan mas mababa ang panganib ng personal_sign login?

Mas limitado ang panganib kapag readable ang message, tama ang domain, malinaw ang purpose at may nonce, pero hindi pa rin ito dapat blind sign. Nagbibigay ang EIP-191 ng prefix para hindi mapagkamalan ang signed data na ordinaryong transaction. Hindi nito pinatutunayang tapat ang layunin ng message.

Ano ang laman ng maayos na login message?

Dapat makita ang service domain, wallet address, login statement, random nonce, issued time at, kung kailangan, expiry. Itugma ang domain sa browser at sa message. Naiintindihan ang “Sign in to example.org”; hindi malinaw ang ibang domain, bukas na terms o hindi kaugnay na asset statement.

Hindi katumbas ng zero risk ang zero gas

Lokal na ginagawa ng wallet ang message signature kaya walang gas. Maaari pa rin itong gamitin ng service bilang patunay na pumayag ang controller ng address. Sa maling kamay, puwede itong maging login token, marketplace order o ibang authorization. Fee information lang ang gas; hindi ito permission score.

Ano ang gagawin sa hex message?

Kapag hindi mabasa ang payload, huwag pumirma at hanapin sa project docs ang eksaktong method. Kung kaunti lang ang display sa hardware wallet, tingnan ang full data sa desktop wallet interface. Hindi independent explanation ang “safe verification” na nakasulat sa page dahil page mismo ang gumawa ng request.

Hindi kailangang i-type sa form ang seed phrase, password o OTP para sa login signature. Wallet ang gumagawa ng signature. Kapag may hiwalay na form na humihingi ng secret, isara ang flow.

Bakit may panganib pa rin ang malinaw na EIP-712 typed data?

Inaayos ng EIP-712 ang data sa domain, types at fields para mabasa ng wallet; hindi nito ginagawang harmless ang permission. Ginagamit ito sa marketplace orders, governance votes, permit, smart-account actions at delegation. Basahin ang domain at message sections.

Domain fields

Tingnan ang name, version, chainId at verifyingContract. Kapag testnet ang sabi ng page ngunit mainnet ang chainId, tumigil. Itugma ang contract sa official docs o verified explorer. Text lang ang name at madaling kopyahin; mas mabigat ang contract address at chain context.

Message fields

Ikaw ba ang owner? Sino ang spender o operator? Gaano kalaki ang value? Ano ang deadline at nonce? Kapag scientific notation ang malaking integer, buksan ang details at unawain ang token decimals. Hindi magkapareho ang maliit na test allowance at unlimited value para sa unknown spender.

Deadline at replay

Maaaring magamit nang mas matagal ang open o napakalayong deadline. Karaniwang humahadlang sa replay ang nonce, pero nakadepende sa contract implementation. Hindi kayang i-audit ng user ang buong code mula sa popup; kaya kailangan ang official contract at documented flow.

Kahit “Login” ang pangalan ng field, maaaring permit o order ang underlying type. Basahin ang wallet method at verifying contract, hindi ang caption sa social post.

Ano ang kaibahan ng approve, permit at setApprovalForAll?

Lahat ay maaaring magbigay ng kapangyarihan sa ibang address, ngunit magkaiba ang sakop na asset at paraan ng pag-submit. Nagbibigay ang ERC-20 approve ng allowance sa spender. Ipinapahayag ng EIP-2612 permit ang allowance sa signature na maaaring isumite ng relayer. Maaaring saklawin ng NFT setApprovalForAll ang buong collection.

Tatlong field sa approve

Itugma ang token contract, spender at amount. On-chain transaction ang approve kaya may gas. Nakakatipid sa susunod na gas ang unlimited allowance pero pinalalaki ang exposure kapag na-compromise o nagbago ang contract. Hindi tugma sa normal na testnet task ang paghingi ng mainnet stablecoin approval.

Tunay na permission ang permit kahit walang gas

Maaaring “signature request” lang ang label ng wallet, ngunit bumubuo ng spending allowance ang owner, spender, value, deadline at verifyingContract. Puwedeng isumite ng attacker ang signature. Hindi ito kinakansela ng disconnect. Pagkatapos ng kahina-hinalang permit, tingnan kung nagamit na sa chain at alamin ang token-specific revocation; ilipat ang mahalagang asset kung kailangan.

Buong NFT collection ang operator permission

Hindi lang isang NFT ang setApprovalForAll. Kapag “verify ownership” o “mint pass” ang dahilan pero mainnet collection-wide approval ang request, hanapin ang official explanation. Hindi proporsyonal sa test badge ang malawak na permission sa mahalagang collection.

Nananatili ang approval kahit magsara ang website, i-delete ang app o i-disconnect ang session. Nagbabago lamang ito kapag naubos ang allowance, ginawa itong zero, ni-revoke ang operator o may contract-specific na kondisyon. Mag-review pagkatapos ng high-permission action at sa pag-alis sa project.

Anong fields ang hindi dapat laktawan sa transaction popup?

Itugma ang network, From, To, value, token changes, contract method at inaasahang resulta. Maaaring “Claim,” “Mint” o “Verify” ang button, pero ang data ang nagtatakda ng on-chain action. Hindi awtomatikong safe ang transferFrom, multicall o unknown method dahil maganda ang label.

1. Expected testnet ba ang chain ID? Kanselahin kung mainnet gas symbol ang lumabas.
2. Tamang test wallet ba ang From address, hindi holding wallet?
3. Tugma ba ang To address sa official contract o intended recipient?
4. Kung hindi zero ang native value, naiintindihan mo ba kung bakit may ipinapadalang asset?
5. May hindi inaasahang outgoing token o NFT ba sa changes?
6. Kaugnay ba ng kasalukuyang task ang method at parameters?
7. Basahin ang simulation kung mayroon, pero huwag ituring na garantiya.

Hindi security score ang gas. Puwedeng mura ang malicious transfer. Hindi rin awtomatikong scam ang failed simulation; maaaring RPC o decoder ang problema. Kapag magkasalungat ang page at wallet, huwag mag-confirm at magtanong sa official technical support.

Maaaring magbago ang logic ng upgradeable proxy. Kasalukuyang state at decoder ang nakikita ng simulation; puwedeng hindi nito masaklaw ang delayed execution, reused signature o future upgrade. Mahalaga pa rin ang limited permission at verified source.

Anong anim na hakbang ang puwedeng gawing routine bago pumirma?

Domain—network—request type—target—scope—exit path ang gamitin sa parehong ayos. Mas matatag ito kaysa follower count, influencer endorsement o magandang interface.

1. Domain: Pumasok mula sa official website o docs; tingnan ang spelling at subdomain.
2. Network: Suriin ang chain ID at selected account; gumamit ng hiwalay na test wallet.
3. Type: Connect, message, typed data, allowance o transaction?
4. Target: Itugma ang contract, spender, operator, recipient at token.
5. Scope: Unawain ang amount, unlimited flag, NFT collection, deadline at replay.
6. Exit: Alamin kung paano mag-disconnect, revoke, cancel o maglipat ng asset.

Buksan ang details kapag may hindi malinaw. Kung hindi pa rin maipaliwanag, kanselahin. Mahina ang risk-reward ng pagbibigay ng main-wallet permission para sa hindi tiyak na airdrop. Nagbibigay ng oras ang lehitimong project; red flag ang countdown at private admin pressure.

Sa mobile, truncated ang address. Kopyahin at ihambing ang buong official address, pero huwag i-paste sa public chat. Huwag ipakita ang WalletConnect QR sa public screen o screen share. Huwag mag-import ng seed sa shared phone o computer shop.

Nagkamali ng pirma sa approve, permit o setApprovalForAll — ano ang gagawin ngayon?

Alamin muna kung anong uri ang napirmahan, saka sundin ang katumbas na hakbang. Kung nag-connect lang sa kahina-hinalang site at walang pinirmahan, sapat nang i-disconnect ito sa Connected sites ng wallet; ligtas ang asset. Kung hindi mo matandaan ang napirmahan, hanapin ang sarili mong address sa block explorer at tingnan kung may Approve, Set Approval For All o hindi kilalang Transfer sa mga huling record. Walang hakbang sa ibaba na nangangailangan ng seed phrase; scam ang anumang “fix tool” na humihingi nito.

Nakapag-approve o setApprovalForAll: gawing zero ang permission sa revoke page

1. I-type mismo ang URL at buksan ang revoke tool, halimbawa revoke.cash, o ang Token Approval Checker ng Etherscan (etherscan.io/tokenapprovalchecker; sa BNB Chain, ang page na may parehong pangalan sa BscScan). Huwag i-click ang “revoke link” na ipinadala sa DM o group.
2. I-connect ang wallet, o i-paste muna ang address para tumingin; ilipat ang network sa chain kung saan ka nag-approve, dahil hiwalay ang record ng approval sa bawat chain.
3. Ayusin ayon sa oras, hanapin ang hindi kilalang spender o operator, at i-click ang Revoke.
4. May lalabas na transaction sa wallet; tiyaking revoke ang ginagawa nito (gawing 0 ang approve amount, o false ang setApprovalForAll), at kaunting native coin ang kailangan pang-gas. Kung walang gas ang wallet, magpadala muna ng kaunti.
5. Pagkatapos maging successful ang transaction, i-refresh ang list at tiyaking wala na ang linyang iyon. Nasa gabay sa pag-revoke ng approval ang mas detalyadong hakbang.

Pinipigilan lang ng revoke ang mga susunod na transfer; hindi na babalik ang nakuha na. Kung patuloy na bumababa ang balance, ilipat muna ang natitirang coin at NFT sa bagong wallet bago mag-revoke.

Nakapirma ng permit o Permit2 signature: tingnan muna kung naisumite na sa chain

Signature lang ang permit; nagkakabisa lang ito kapag isinumite ng kabilang panig sa chain. Buksan ang address mo sa block explorer at tingnan kung lumabas na ang spender nila sa approval record o mga huling event ng token:

• Lumabas na: i-revoke tulad ng nasa itaas, at tingnan kung nakuha na ang token balance.
• Hindi pa lumalabas: pinakaligtas na ilipat agad ang token sa ibang wallet, para walang makuha ang allowance ng signature. Puwedeng subukang kanselahin ang kahina-hinalang signature sa Signatures page ng Revoke.cash, pero sila mismo ang nagsasabing kadalasang isinusumite agad ng scammer ang signature, kaya madalas hindi na umaabot.

personal_sign login message lang ang napirmahan: kadalasang walang mawawalang coin, pero gawin ang tatlong ito

Hindi magagamit bilang transfer transaction ang ordinaryong message signature na may EIP-191 prefix, at hindi rin ito ang EIP-712 structured data na kailangan ng permit; kaya kadalasang hindi nito maililipat ang token mo. Ang gagawin:

1. Alalahanin o tingnan sa screenshot ang pinirmahang teksto. Kung hindi lang login ang nakasulat kundi may authorize, order, key o trading, pumunta sa official website ng platform na iyon, tingnan ang logged-in devices, sessions at API keys, at alisin isa-isa.
2. I-disconnect ang site sa wallet; i-reject ang lahat ng susunod na approve o permit mula roon.
3. Kung sa pekeng site ka pumirma, hawak na nila ang address mo; maaaring may dumating na pekeng airdrop token at “claim link” — huwag i-click. Hindi kailangang magpalit ng wallet dahil lang sa login message.

Nawawala agad ang coin pagkapadala: hindi approval ang problema, nag-leak na ang private key o seed phrase

Kapag nagpadala ka ng native coin sa wallet at ilang segundo lang ay napunta na sa hindi kilalang address, may ibang may hawak ng private key mo. Walang silbi ang revoke, at makukuha rin ang gas na ipapadala mo. Huwag nang magpadala sa address na iyon; gumawa ng bagong wallet gamit ang bagong seed phrase, ilipat agad ang kaya pang ilipat, at iwanan nang tuluyan ang lumang address.

Nakuha na ang asset: itabi ang ebidensya at dumaan lang sa official na channel

Hindi na mababawi ang on-chain transfer. Ihanda ang transaction hash (TxID), ang address mo, ang address ng tumanggap, ang domain ng phishing site at screenshot ng popup. Kung napunta ang asset sa deposit address ng isang exchange, dalhin ito sa official support ng exchange na iyon; may tsansang ma-freeze ang bahaging hindi pa naiwi-withdraw. I-report ang phishing domain sa official support ng wallet, at tumawag sa CICC hotline 1326, ang 24/7 na scam hotline ng gobyerno. Pangalawang scam ang sinumang nangangakong “mare-recover” o “ma-a-unfreeze” ang pondo kapalit ng bayad; hindi naniningil nang pauna ang lehitimong ahensya.

Tatlong maikling sitwasyon

Login message

Readable ang statement, tugma ang domain, may nonce at issued time, at walang asset field. Mas limitado ang risk ngunit may privacy cost kapag ini-link ang address sa profile. Mas mainam ang activity wallet kaysa holding wallet.

Testnet swap approval

Testnet talaga ang chain, test asset ang token at official router ang spender. Maaaring expected ang approval, pero tingnan kung puwedeng custom amount sa halip na unlimited. I-review matapos ang task.

Mainnet permit na tinawag na verification

Reward ang sabi ng page pero mainnet chainId, stablecoin contract at unknown spender ang typed data. Hindi safety signal ang kawalan ng gas. I-reject, i-report ang domain at tingnan kung may naunang signature.

Karaniwang tanong

Mga pangunahing teknikal na sanggunian

• EIP-191: Signed Data Standard
• EIP-712: Typed Structured Data
• ERC-20: approve and allowance
• EIP-2612: permit
• Ethereum.org: Transactions
• MetaMask Wallet API: Sign data
• MetaMask Support: Protect yourself
• Revoke.cash: permit signature at pagkansela nito
• MetaMask MIP-3: pagtigil ng eth_sign