Approval Phishing: How One Signature Drains Your Wallet

On EVM blockchains, tokens like USDC or DAI live in their own smart contracts, not inside your wallet. Your wallet only holds the keys that prove you control a balance. So when an app such as a decentralized exchange needs to move your tokens for you, it cannot just reach in and grab them. You have to grant permission first.

That permission is called an approval. The most common form is the ERC-20 approve function, where you tell the token contract that a specific spender address may transfer up to a certain amount of your tokens. You will run into a few different flavors:

• approve on ERC-20 tokens, which sets an allowance for one spender up to a fixed number of tokens.
• setApprovalForAll on ERC-721 and ERC-1155 NFT contracts. This one is much broader: it lets a spender transfer every NFT you own in that collection, including ones you buy later.
• Permit and Permit2 signatures, a newer pattern that lets you grant an allowance by signing an off-chain message rather than sending an on-chain transaction, usually with no gas cost to you.

Approvals are legitimate, and you cannot avoid them if you want to touch most of DeFi. The catch is that the same mechanism that lets a trustworthy exchange swap your tokens also lets a malicious contract drain them.

Plenty of apps ask for an unlimited approval by default, setting the allowance to the maximum possible value. They do it so you never have to approve again, which is genuinely convenient. It also means the spender contract can move every token of that type in your wallet, forever, until you revoke it.

Attackers love this. A phishing site dressed up as an airdrop claim, a mint, or a yield opportunity will show you an approval prompt that looks routine. Approve it, and the spender address in that transaction belongs to the attacker. The drain need not happen right away. They can wait until your balance grows, or until plenty of victims have approved, then sweep everyone in one go.

Since the malicious transfer is technically authorized by an approval you signed, the token contract sees nothing unusual about it. As far as the chain is concerned, you gave permission. That is what makes approval phishing so effective: the theft is a perfectly normal, valid transaction.

The same logic covers setApprovalForAll on NFTs. One careless approval on a fake marketplace can hand over an entire collection, including pieces you have not even bought yet.

The Permit and Permit2 standards were built to make life easier for users. Rather than paying gas for a separate approval transaction, you sign a message off-chain that authorizes an allowance. The receiving app submits that signature on-chain later, when it actually needs to spend.

That is powerful and convenient, but it changes the threat model. A Permit signature is nothing more than data you sign with your key. It does not show up in a block explorer as a pending approval, and it usually costs nothing, so it feels harmless. There is no on-chain transaction to inspect before the damage is done.

An attacker can build a Permit request that names their own address as the spender, sets the amount to your full balance, and uses a long deadline. Sign it, and they hold a valid voucher to drain that token whenever they like. And because the signing happened off-chain, you might never see a warning that your funds are at stake until they are already gone.

• A regular approval transaction is visible on-chain and can sometimes be caught before confirmation.
• A Permit signature stays invisible until it is redeemed, which can be much later.
• Permit2 in particular can batch approvals across many tokens, so a single signature may expose more than one asset.

The lesson here is simple. A signature request is not automatically safe just because it asks for no gas. Off-chain signatures can be every bit as dangerous as transactions.

Your wallet shows two fundamentally different kinds of requests, and learning to tell them apart is one of the most useful skills you can pick up.

A transaction changes state on-chain and costs gas. Your wallet will show a network fee, the contract address you are interacting with, and often a decoded action such as Approve or Transfer. You can usually inspect the spender and the amount before you confirm.

A signature request asks you to sign data with your private key, and there is normally no gas fee. Some signatures are harmless, like proving wallet ownership to log into a site. Others, such as Permit, Permit2, or an order on a marketplace, authorize the movement of value. Modern wallets try to decode these and show fields like spender, token, value, and deadline.

When a prompt pops up, slow down and check:

• Is this a transaction or a signature? If it is a signature, what type is it?
• What is the spender address, and do you recognize it as the app you meant to use?
• What is the amount or allowance? Is it your full balance or an unlimited value?
• Does the action match what you clicked? Logging in should not require a Permit.

If something simple like connecting or claiming suddenly asks for a token approval or a Permit signature, treat that mismatch as a warning sign.

Attackers are not limited to the basic approve function. The ERC-20 standard also includes increaseAllowance, which bumps up an existing allowance instead of overwriting it. Some phishing flows lean on this to raise permissions quietly, and since the function name sounds technical and harmless, victims sign off on it without grasping what it grants.

Approval phishing also pairs nicely with address poisoning. In an address-poisoning attack, the scammer sends you a tiny or zero-value transfer from an address built to look almost identical to one you use often, matching the first and last characters. Later, when you copy an address out of your transaction history, you might grab the poisoned one by mistake.

Put the two together and the danger compounds. A victim already trained to trust a familiar-looking address may approve or send funds to a contract they never meant to touch. So verify the full address every time, not just the leading and trailing characters, and never copy a destination out of your history without checking it character by character.

Every approval you have ever granted stays live until you revoke it or set it back to zero. After months of using different apps, most active users have piled up dozens of standing allowances, many of them unlimited, to contracts they stopped using long ago. Each one is a door left unlocked.

You revoke an approval by sending a transaction that sets the allowance for that spender back to zero, or by using a reputable approval-management tool that lists your active allowances and lets you clear them. Revoking costs gas, but that is far cheaper than losing your balance.

Make revocation a regular habit, not a one-time cleanup. Review your approvals every so often, especially after you have touched new or experimental apps, and clear out anything you do not actively need. With Permit2 and similar systems, check the approvals registered there too, since they live in a separate contract from classic ERC-20 allowances.

Cutting your exposure up front helps as well. When an app gives you the choice, approve only the amount you need for the action in front of you instead of an unlimited allowance. You will approve more often, but each approval puts only a small, defined amount at risk.