How to Check a Token Approval Before You Sign

Most wallet-draining incidents do not happen because someone stole your seed phrase. They happen because you clicked “Confirm” or “Sign” on a request that quietly handed a smart contract permission to move your tokens. Learning to read that request is one of the highest-value skills in self-custody, and it takes only a minute per transaction once you know where to look.

What is a token approval, and why does it matter before you sign?

On EVM chains like Ethereum, a contract cannot touch your tokens unless you first grant it permission. For fungible tokens this is the ERC-20 approve(spender, amount) function: you name a spender contract and a maximum amount it may move on your behalf. Once approved, that spender can call transferFrom and pull up to that amount at any time, with no further prompt from you.

For NFTs the equivalent is setApprovalForAll(operator, true), which is far broader: it lets the operator transfer every NFT you hold in that collection. Because approvals persist until you change them, a permission you grant today is still live months later. That standing access is exactly what attackers abuse, so the moment to check an approval is before you sign, not after.

How do you tell an approval apart from a simple transfer?

Your first job is to identify what kind of action the prompt is actually requesting. Wallets label these differently, but the vocabulary is consistent:

• Approve / Set approval / Give permission — you are granting a contract the right to spend your tokens later. This is the category that needs the most scrutiny.
• Transfer / Send — tokens leave your wallet immediately to a named address.
• Swap, Deposit, Stake, Mint — an interaction that often bundles an approval step first.

If the wording mentions spending, allowance, approval, or contract access, slow down. A legitimate swap on a decentralized exchange will typically ask for an approval once, then a separate transaction to perform the swap. If a site that should not need spending rights is asking for an approval, treat that as a red flag.

What should you check inside the approval prompt itself?

A modern wallet shows the key fields on the confirmation screen. Read four things every time:

1. The token — which asset is being approved? Confirm it is the one you intend to trade or spend.
2. The spender — the contract address that will receive permission. An unfamiliar or freshly deployed address is a warning sign. Cross-check it against the project’s official documentation.
3. The amount — is it the exact amount you need, or an unlimited allowance? Many dapps default to a max-uint (effectively unlimited) approval so they never have to prompt you again. That convenience means a compromised or malicious spender can drain your entire balance of that token, so prefer a custom, limited amount when your wallet lets you set one.
4. The site URL — confirm the domain in your browser matches the project you meant to visit. Signature and approval phishing almost always rides on a look-alike domain.

What about signatures that have no gas fee?

This is the trap most people miss. Not every dangerous authorization is an on-chain transaction. EIP-2612 “permit” and Uniswap’s Permit2 let you grant an allowance by signing an off-chain message — a gasless approval. Because there is no gas fee and no obvious “transaction,” it feels harmless, but a valid permit signature can authorize a spender just as completely as an on-chain approve.

A permit message is structured EIP-712 typed data, and a good wallet will display its fields in human-readable form: owner, spender, value, nonce, and a deadline. Read the spender and value the same way you would an on-chain approval. Never assume a signature is safe merely because it costs nothing. Be especially wary of raw, unreadable hex or an eth_sign “blank check” style request, which is a classic phishing pattern.

What is blind signing, and how do you avoid it?

Blind signing is approving a request when your wallet cannot decode it into plain language, so you are trusting the interface rather than the data. It is where large losses tend to happen. To avoid it, do not proceed on any prompt you cannot read. Enable your wallet’s security and decoding features — in MetaMask, for example, security alerts can be turned on in settings — so requests are shown in a structured, human-readable form rather than raw bytes. If your wallet still shows only hex, stop and investigate before signing.

How can you simulate what a transaction will actually do?

Simulation runs the transaction against current chain state without broadcasting it, so you can see which balances and allowances would change. Many wallets, including MetaMask and Rabby, now simulate automatically and display a preview of the net effect on your assets before you confirm. That preview is how a wallet can catch an “approve” request that would drain tokens instead of doing what the site claims.

Treat the preview as a strong signal, not a guarantee. Sophisticated malicious contracts have attempted “red pill” attacks that detect when they are being simulated and behave innocently, then act differently once signed; wallet teams have shipped countermeasures, but the safest habit is to combine the simulation with your own manual reading of the spender and amount. You can also inspect the spender contract directly on a block explorer such as Etherscan — check whether it is verified, how old it is, and whether it matches the project’s published address.

How do you review and revoke approvals you have already granted?

Checking before you sign is the priority, but you should also audit what is already live. A free tool like Revoke.cash scans your address across many chains and lists every active approval, the spender, and the allowance amount. Anything you no longer use, or any unlimited approval on a contract you do not fully trust, can be revoked. Technically a revocation is just an approve(spender, 0) transaction (or the NFT equivalent), so it costs gas, but it removes standing risk. Reviewing approvals periodically — and after using any new dapp — keeps your exposure small.

What are the red flags that should stop you from signing?

• An approval requested by a site that has no reason to spend your tokens.
• An unfamiliar spender address, or one that does not match the project’s official docs.
• An unlimited allowance when a small, fixed amount would do.
• A gasless signature whose spender or value you cannot read, or a raw-hex request.
• A domain that is misspelled or different from the one you intended to visit.
• Urgency: “claim now,” “your wallet is at risk,” or an unexpected airdrop prompt pushing you to sign quickly.

When in doubt, reject the request. Rejecting an approval costs you nothing, and you can always redo a legitimate action deliberately. The few seconds it takes to read the token, spender, amount, and URL are the cheapest insurance in crypto.

Sources

• Revoke.cash Learn — What are token approvals
• Ethereum Improvement Proposals — EIP-2612: Permit Extension for EIP-20 Signed Approvals
• MetaMask Help Center — Signature phishing
• Etherscan Documentation
• Ledger Academy — Ethereum token approvals explained