wallet approvals: the permission you forgot you gave

not every drain starts with the team running off. some start with a permission the wallet owner gave months ago and then forgot.

the checklist

• what an approval is. on evm chains, an erc-20 approval lets another address, usually a contract, move up to a set amount of a token out of the wallet without asking again.
• unlimited vs exact. many apps ask for an unlimited allowance. a plain erc-20 approval has no expiry: it stays until it’s used up or overwritten. many wallets let the amount be edited down to what the action needs.
• permit2 is two layers. the token’s approval to the permit2 contract is its own entry, typically unlimited and without expiry. inside permit2, each app gets a separate allowance with an amount and an expiration.
• a signature can be an approval. an eip-2612 “permit” is signed off-chain and costs the signer no gas. once anyone submits it on-chain, it sets an allowance. permit2 offers similar signatures for tokens without eip-2612 support. a popup that says “sign” can do the same job as one that says “approve”.
• revoke is a transaction. revoking a plain erc-20 approval means setting it to zero on-chain, which costs gas. permit2 allowances are revoked inside permit2, and approval overviews often don’t show them.
• separate wallets, as a concept. a wallet that holds long-term funds and never connects to new apps limits what one bad signature can reach.

hypothetical example (made-up wallet, made-up numbers)

a wallet holds 1,000 units of a made-up stablecoin. six months ago it gave an unlimited approval to a swap contract. that contract is later exploited.

the attacker calls transferFrom and moves all 1,000 units. no new signature needed. the old approval was enough.

variant: a fake “claim your airdrop” page asks for a signature. the popup shows a permit with an unknown spender, a huge value and a deadline far in the future. signing is free, which is the point. the drain comes later, when the attacker submits it.

where it leaks

• revoking doesn’t undo the past. tokens already moved stay moved. revoke only stops future pulls under that approval.
• unused signatures don’t show up. a signed but unsubmitted eip-2612 permit isn’t on any approvals page. its deadline can be set so far ahead that it never matters in practice, and eip-2612 has no cancel function. the only way to kill it is to use up its nonce on-chain, for example by submitting a different permit, which costs gas. permit2 has its own nonce-invalidation functions.
• this is evm only. solana uses a different model: a token account has one delegate with a delegated amount, set and removed with separate instructions (token program docs).
• a clean approvals list is not safety. it says nothing about backups, malware, permit2 allowances or the next signature.

the boxer’s rule, which is opinion: he hands his toy to anyone who asks nicely. adorable in a dog, expensive in a wallet.

the version where the team holds the dangerous permissions is in how to spot a rug pull.

nerd corner

• erc-20: approve(spender, value) sets allowance(owner, spender). transferFrom spends it. there is no expiry field (eip-20).
• eip-2612: the owner signs eip-712 typed data (owner, spender, value, nonce, deadline). anyone can submit permit() and pay the gas. the nonce increases when a permit is used. only tokens that implement it support it (eip-2612, eip-712).
• permit2: allowance transfer stores amount, expiration and nonce per owner, token and spender. allowances are revoked with permit2’s own functions, and unused signatures are cancelled by invalidating nonces. both happen on-chain and both cost gas (overview, allowance transfer, signature transfer).

not financial advice. dyor. you can lose all of your money. interests: see /disclosure.