Signatures, approvals, and incident response

Name the action before approving it

Four different things are commonly collapsed into the phrase “connect wallet,” and they carry entirely different consequences. A connection typically reveals a public address you select—it is the least consequential and the one people worry about most.

A message signature proves control of an address without moving anything, which is why it is used for logins. It can also authorize structured data whose meaning is not obvious from the text displayed, which is how some of the most damaging attacks work: the prompt looks like a harmless login and grants something else.

A token approval grants a contract ongoing authority to spend a token from your address, up to a limit, until revoked. It does not move anything at the moment you sign, which is exactly why it is dangerous—the consequence arrives later and requires no further action from you. A transaction is the direct case: it transfers assets or calls code now.

Read the scope, not the branding

For any prompt, the fields that matter are the network, the contract being called, the spender receiving authority, the amount or limit, the destination, the method being invoked, and the maximum fee. Wallets vary in how clearly they present these, and some require expanding a details panel to see them at all.

Unlimited approvals are the default in many interfaces because they save the user from re-approving later. The trade is that the contract can spend that token from your address indefinitely, so any future compromise of the contract, its administrator keys, or the interface reaches everything you hold of that token. Approving a specific amount is slightly less convenient and substantially narrower.

A hardware wallet does not resolve this. It protects the key from extraction; it signs whatever you confirm. If the request itself grants excessive authority, the hardware signs that request faithfully. The device improves key security, not judgement.

Contain before improvising

If something has gone wrong, the instinct is to act fast, and fast improvisation usually makes it worse. Work through a fixed sequence instead.

First, stop signing and stop sending—no further approvals, no test transactions, no interaction with the site. Second, establish what authority was actually granted, using a verified approval-review tool reached independently rather than a link offered to you. Third, revoke unnecessary approvals if the keys are still yours alone. Fourth, if the recovery phrase itself may be exposed, revocation is not enough: assets have to move to a wallet generated on a device you trust, and moving them requires fee assets that may themselves be at risk.

Throughout, preserve evidence—transaction hashes, the exact domain, screenshots, timestamps—and contact the wallet or service through a channel you locate yourself. Do not follow unsolicited recovery instructions, and be aware that a public request for help attracts impersonators within minutes.

• Disconnect the suspicious site and stop all signing.
• Review approvals with a tool you reached independently.
• Revoke unnecessary authority while keys are still exclusively yours.
• If the phrase may be exposed, migrate rather than revoke.
• Preserve hashes, domains, and screenshots before anything else.
• Report the fraud through independently verified channels.