Approval Phishing: How the Token Approval Exploit Actually Works

Approval phishing is the attack that does not need your seed phrase. It works because every token you hold on an EVM chain can be spent by a second address that you yourself authorised, and because the standard that defines that authorisation was written in 2015 with no expiry date, no spend limit by default, and no requirement that the wallet tell you who the spender is. Most explainers stop at "do not click suspicious links". This piece walks through the actual on-chain primitives, what a signature grants versus what a transaction grants, and which defences hold up under scrutiny. It is a factual reference and it does not constitute investment or financial advice.

What does a token approval actually grant?

An ERC-20 approval grants a named address a standing right to move your tokens out of your wallet, up to a numeric cap, with no further permission from you. The mechanism is defined in EIP-20, which has been Final since its creation on 19 November 2015 by Fabian Vogelsteller and Vitalik Buterin. Three functions carry the whole weight of it. The token owner calls approve(address _spender, uint256 _value). The token contract records the result in a mapping readable through allowance(address _owner, address _spender). The spender then calls transferFrom(address _from, address _to, uint256 _value) at any later moment, and the tokens move.

Two properties of that design are what the attack exploits. First, the allowance has no expiry. It persists until the owner sets it to a lower number, and it survives the owner moving tokens out and later moving tokens back in. Second, the value is an unsigned 256-bit integer, so a dApp asking for the maximum representable value is asking for a permanent claim on your entire balance of that token, present and future. An approval is therefore best understood as a standing payment mandate on one token, not a one-off permission for a single trade.

EIP-20 itself anticipated a problem, though not the one that now dominates losses. The specification advises that clients "set the allowance first to 0 before setting it to another value for the same spender" to prevent an attack vector, while declining to enforce it in the contract for backward compatibility. That note is about a front-running race between the owner and an existing spender. It says nothing about a user being tricked into naming a hostile spender in the first place.

The NFT equivalent is worse in one respect. EIP-721, Final since 24 January 2018, defines setApprovalForAll(address _operator, bool _approved), described in the specification as a way to "enable or disable approval for a third party (operator) to manage all of msg.sender's assets". There is no amount to limit. It is a boolean, and the specification states plainly that "the operator can manage all NFTs of the owner".

Approval primitives on EVM chains and what each one concedes

Primitive	Standard	What it grants	Visible on chain when granted
approve(spender, value)	EIP-20 (Final, 2015)	Right to transferFrom up to value, no expiry	Yes, costs gas, emits Approval
increaseAllowance(spender, added)	Non-standard, removed from OpenZeppelin v5	Adds to an existing allowance	Yes, costs gas
setApprovalForAll(operator, true)	EIP-721 (Final, 2018)	Control of every NFT in that collection, no cap	Yes, costs gas
permit(owner, spender, value, deadline, v, r, s)	EIP-2612 (Final, 2020)	The same allowance, set by an off-chain signature	No, only when the signature is redeemed
Permit2 PermitSingle	Uniswap Permit2	Amount plus an expiration timestamp, held inside the Permit2 contract	No, only on redemption
EIP-7702 authorisation tuple	EIP-7702 (Final, in Pectra)	Sets code at your own account address	Yes, as a 0xef0100 delegation indicator

Why is a stolen approval different from a stolen private key?

An approval theft leaves your key intact, which is exactly why victims often do not realise anything has happened. Microsoft Threat Intelligence named this pattern "ice phishing" in a post dated 16 February 2022, describing it as tricking users into "signing a transaction that delegates approval of the user's tokens to the attacker" rather than stealing credentials. Their framing of the mechanism is blunt. In a legitimate flow the spender is a protocol contract, and in the attack "the attacker merely needs to modify the spender address to attacker's address".

The practical consequence is a timing asymmetry that favours the attacker. Chainalysis, in a post updated 17 June 2026, describes the window directly. Once approval is obtained, "the scammer can now drain the victim's wallet whenever they please. They might move instantaneously or lurk until an ideal moment, like right after the victim deposits fresh funds from their exchange." A wallet that looks fine today can be emptied the hour after your next exchange withdrawal lands. That patience is not a quirk of the attacker's tooling. It is the economically rational play, and it is why the question "was I affected" cannot be answered by checking your balance.

The clearest demonstration of what this costs at scale was the BadgerDAO incident. Microsoft's analysis records that the attacker compromised Badger's Cloudflare infrastructure, injected a script into the front end that requested ERC-20 approvals to an attacker address, and took "$121 million" from "almost 200 accounts within 10 hours" in December 2021. No contract in the protocol was broken. The signing prompt arrived inside a real application at a real domain, and the users who approved it had no reliable way to tell. The attack surface is the signing prompt, not the smart contract, which is why a contract audit and a trusted URL together are still not sufficient protection.

How did signatures make this worse than transactions?

EIP-2612 moved approvals off chain, and in doing so removed the two frictions that used to give victims a chance to think. The standard, Final since 13 April 2020, adds permit, which sets allowance[owner][spender] from a signed EIP-712 message rather than from a transaction sent by the owner. The signed struct is Permit(address owner, address spender, uint256 value, uint256 nonce, uint256 deadline). The user pays no gas and sends no transaction. A relayer or the attacker submits it later. Permit turned an approval into something you can concede by accident, with no gas spent, no transaction sent and no entry in your own activity history to audit afterwards.

That is a genuine usability improvement and a serious security regression at the same time. Because nothing touches the chain at signing time, there is no on-chain record for a monitoring tool to find. Revoke.cash states the limitation about its own product plainly, which makes it a usefully honest vendor source even though a vendor explainer is not a primary source: "a platform like Revoke.cash can never determine which signatures you've signed." It also notes the gap in wallet behaviour, that many wallets "now display a warning when you sign an onchain approval, but for Permit signatures, these kinds of warnings are absent".

Uniswap's Permit2 adds a second layer. Its PermitDetails struct carries a token, a uint160 amount described as "the maximum amount allowed to spend", a uint48 expiration described as the "timestamp at which a spender's token allowances become invalid", and a nonce. PermitSingle wraps that with a spender and a sigDeadline, the "deadline on the permit signature". The expiration is a real improvement over EIP-20, because a Permit2 allowance can lapse on its own. The complication is that your ERC-20 approval now points at the Permit2 contract while the per-application allowances live inside Permit2, so there are two separate things to inspect and revoking one does not revoke the other. Permit2 shortens how long a given risk lasts and doubles the number of places you have to look to confirm you are clean.

EIP-2612's own Security Considerations section lists front-running, censorable signatures, zombie approvals created against address(0), chain replay if the domain separator is not rebuilt after a split, and the observation that "the standard EIP-20 race condition for approvals (SWC-114) applies to permit as well". Notably absent from that list is the phishing failure mode that now accounts for most of the money.

On-chain approval compared with an off-chain Permit signature, from the victim's point of view

Property	approve transaction	Permit or Permit2 signature
Gas paid by victim	Yes	No
Appears in wallet activity history	Yes	No
Discoverable by a revoke tool	Yes	No, until redeemed
Wallet risk warning typical	Commonly shown	Often absent, per Revoke.cash
Built-in expiry	None	EIP-2612 deadline, Permit2 expiration
How to cancel before use	approve(spender, 0)	Advance the nonce, which is a race

What is blind signing and why does it sit at the centre of this?

Blind signing is approving data your wallet cannot render into a sentence you could evaluate. EIP-712, Final since 12 September 2017, exists because of it, and its motivation names the problem exactly: "currently signed messages are an opaque hex string displayed to the user with little context about the items that make up the message." Typed structured data and a domain separator let a wallet show you a named struct with named fields instead of a hash.

The worst case was eth_sign, which signs an arbitrary hash. MetaMask's MIP-3, created 15 May 2024 and marked Accepted with stability Deprecated, is explicit that "the eth_sign method's capability to sign arbitrary data makes it vulnerable to phishing attacks" because "the hex data being signed can't be decoded and made readable to the signer". A hash is a one-way function, so no amount of wallet engineering can recover what it represents, which makes a legible warning technically impossible rather than merely missing. MIP-3 also records that the method had been disabled by default for a year before removal, because "there is still a risk that users are enticed to re-enable it when they should not".

EIP-712 solved legibility of structure, not legibility of meaning. A correctly rendered Permit struct still shows a spender as a hex address and a value as a large integer, and the user is left to decide whether that address is a well-known router or a drainer deployed nine minutes ago. ERC-7730 is the current attempt to close that gap, defining a JSON format that maps contract calls and EIP-712 messages to plain language. Its own text argues that "properly validating a transaction on a hardware wallet's screen (also called Clear Signing) is a key element of good security practices for end users". It is worth stating what ERC-7730's status actually is rather than overselling it. ERC-7730 remains a Draft created on 7 February 2024, which means clear signing is a direction of travel and not a protection you can currently rely on across arbitrary contracts.

One remediation here is already complete and instructive. OpenZeppelin issue 4583, opened 7 September 2023 and closed 12 September 2023, proposed removing increaseAllowance and decreaseAllowance from its ERC-20 implementation. The stated reasons were that the functions are "not part of the EIP-20 specs", that they "may allow for further phishing possibilities", and that the race condition they fixed was "not critical nor high in the wild". The issue cites, as context, a user who "lost $24m since he got tricked into signing a malicious increaseAllowance payload". The v5.0.0 release notes record the outcome in one line: "ERC20: Removed the non-standard increaseAllowance and decreaseAllowance functions." That fix removed one convenient lure from the most widely used token library and left the underlying primitive exactly as it was.

The incident behind it is independently documented. Cointelegraph, reporting on 7 September 2023 and citing PeckShield, recorded a loss of 9,579 stETH worth about $15.5 million and 4,851 rETH worth about $8.5 million, roughly $24 million in total, taken on 6 September 2023 in two transactions after the victim signed Increase Allowance authorisations.

How much money does approval phishing actually move?

The honest answer is that nobody publishes a clean total, and the figures most often quoted measure different things. The most specific dataset comes from Scam Sniffer, whose 2025 annual report dated 3 January 2026 puts wallet-drainer phishing losses at $83.85 million across 106,106 victims on Ethereum and EVM chains, down 83 percent and 68 percent respectively from $494 million and about 332,000 victims in 2024. Average loss per victim fell to $790 from $1,488. Only 11 incidents exceeded $1 million, against 30 in 2024, and the largest single loss was $6.5 million through a Permit signature in September.

The breakdown by authorisation type within those large cases is the most mechanism-relevant figure in the public record, and it is the reason this article treats Permit as the current centre of gravity rather than classic approve.

Scam Sniffer 2025 losses in cases above $1 million, by authorisation type (sample is 11 incidents only)

Authorisation type	Cases	Losses
Permit and Permit2	3	$8.72m
Approve and increaseApproval	3	$5.62m
Direct transfer	2	$4.87m
EIP-7702 batch	2	$2.54m
setApprovalForAll	1	$1.23m

Three caveats belong next to that table rather than in a footnote. The sample is 11 incidents, so a single case landing differently would reorder the ranking. Scam Sniffer is a commercial security vendor publishing its own measurement, which is neither a primary record nor peer reviewed. And the category boundaries are the vendor's own, so the "direct transfer" cases are not approval abuse at all and appear here only to show relative scale. No public dataset isolates approval phishing from the broader scam category, so every headline total in this space is either narrower or far broader than the mechanism itself.

Larger numbers exist but cover much wider categories. Chainalysis reports at least $14 billion lost to on-chain scams in 2025 with a projection toward $17 billion, and an average payment per scam address up 253 percent year on year. Its approval-phishing enforcement figures are narrower and worth separating out. Operation Spincaster is described as disrupting $162 million in losses, and Operation Atlantic as freezing $12 million while tracing $45 million and identifying more than 20,000 victims across Britain, Canada and the United States. Those are enforcement tallies, not market totals.

The government figure in this space is broader still. The FBI Internet Crime Complaint Center's 2025 annual report, released 6 April 2026, recorded 1,008,597 complaints and $20.877 billion in reported losses, of which cryptocurrency-related fraud accounted for $11.366 billion across 181,565 complaints, close to 55 percent of all reported losses and up 22 percent year on year. Within that, $7.2 billion was attributed to cryptocurrency investment fraud. One disclosure is owed to the reader here. The IC3 report does not break out approval phishing as a category, and the PDF did not render as text when retrieved for this article, so the figures above come from reporting of it rather than from reading the source document. The primary PDF is linked in the sources for anyone who wants to check it.

Finally, the trend is not monotonic. Scam Sniffer figures reported by Decrypt on 9 February 2026 put January 2026 signature-phishing losses at $6.27 million across about 4,741 wallets, with victim counts up 207 percent on December, a single case of $3.02 million via permit and increaseAllowance on SLV and XAUt tokens, and two wallets accounting for roughly 65 percent of the month's total. Annual declines in this category track market activity rather than any improvement in wallet safety, so a falling yearly total is not evidence that the mechanism has been fixed.

Does the drainer being a business change the defence?

It changes who you are up against, which matters for how you budget attention. The clearest documented case is Inferno Drainer, a drainer-as-a-service operation measured by Scam Sniffer and reported by Infosecurity Magazine on 16 January 2024 as having taken nearly $88 million from over 137,000 victims between November 2022 and November 2023, across around 16,000 phishing domains, with the developers keeping 20 percent of takings and affiliates 80 percent. Published totals for this single operation range from roughly $81 million to $88 million depending on the source and the cut-off date, which is a fair indicator of how loose this measurement is in general.

The structural point is that whoever builds the drainer is not whoever finds you. Affiliates handle the lures, the kit handles the signature logic, and the revenue split rewards volume over precision. Volume economics mean you are usually not being targeted personally, you are being enumerated, so a defence that depends on recognising a specific scam will eventually meet one it has not seen. That separation of infrastructure from distribution mirrors a pattern visible across digital finance, including the rise of social trading platforms.

Does EIP-7702 make approval phishing worse?

Partly, but the most alarming headline figures about EIP-7702 are measuring something else, and saying so matters more than repeating the scare. EIP-7702, Final and created 7 May 2024, shipped in the Prague and Electra upgrade listed in EIP-7600, which names "EIP-7702: Set EOA account code" among the eleven core EIPs. It lets an externally owned account set code at its own address by signing an authorisation tuple of [chain_id, address, nonce, y_parity, r, s], after which the account carries the delegation indicator 0xef0100 followed by the delegate address. The EIP's own Security Considerations state that "a poorly implemented delegate can allow a malicious actor to take near complete control over a signer's EOA".

So the phishing variant is real. A victim who signs an authorisation naming a hostile delegate installs attacker logic at their own address, and because the delegate's behaviour is opaque at signing time, this is blind signing with the whole account as the stake. Scam Sniffer's 2025 data records two such batch cases totalling $2.54 million.

The much larger delegation counts do not belong in that column. Wintermute research reported by The Block on 1 June 2025 found that over 80 percent of EIP-7702 delegations pointed at "copy-pasted versions of the same basic code", a contract it nicknamed CrimeEnjoyor, which automatically sweeps wallets whose private keys have already leaked. Wintermute has since stated that EIP-7702 is not flawed and is safe to use in retail wallets, and that users of trusted wallets cannot authorise those contracts because such wallets delegate only to their own audited code. Taylor Monahan, quoted in the same report, put the distinction as the key issue being "the underlying compromise of users' private keys". Conflating sweeper activity on already-compromised keys with approval phishing inflates the apparent size of the signing problem, so this article counts only the $2.54 million that Scam Sniffer attributes to batch-signature phishing.

Which defences hold up, and which do not?

Revocation works on on-chain allowances and does nothing about a signature already in an attacker's possession. Setting an allowance to zero is just approve(spender, 0), which is what Etherscan's token approval checker at etherscan.io/tokenapprovalchecker deep-links your wallet to send, with equivalents on Arbiscan, Polygonscan and other explorers. Microsoft's 2022 post recommended exactly this, periodically revoking allowances through that tool. Each revocation is a separate transaction and costs gas, which is the real reason most people never do it.

The limits are worth being precise about. Revoking does not recover funds already moved. Against an attacker holding a valid Permit signature, invalidating it by advancing the relevant nonce is a race rather than a remedy, and attackers typically redeem as soon as they can. And an off-chain signature you have already given cannot be enumerated by any tool, so after a suspected phishing interaction you are working from memory rather than from a list. Revocation is maintenance that limits tomorrow's exposure, and it is never a remedy for a drain that has already executed.

Defences against approval phishing, with what each one cannot do

Defence	Stops	Does not stop	Cost to user
Revoke on-chain allowances periodically	Dormant approve and setApprovalForAll grants	Unredeemed Permit signatures, past theft	Gas per revocation
Approve exact amounts, never the maximum	Open-ended future claims on a balance	A single approval sized to what you hold today	More transactions and more gas
Separate holding wallet from interacting wallet	Exposure of the bulk of holdings	Losses inside the interacting wallet	Operational friction, transfer fees
Hardware wallet with clear signing	Some blind signing on supported contracts	Contracts with no ERC-7730 descriptor	Device cost, patchy coverage
Check both Permit2 layers	Forgotten sub-allowances inside Permit2	Signatures not yet redeemed	Attention, two places to look
Refuse eth_sign style prompts	Arbitrary hash signing	Legible but hostile EIP-712 structs	None, and MetaMask removed the method

Two habits do more than the tooling. Treat the spender address in any approval or Permit prompt as the field that matters, because that is the one the attacker changes, and treat a request for the maximum amount as a reason to stop rather than a formality. Approvals you granted years ago to protocols you no longer use are the cheapest item on this list to clean up, and the one almost nobody has ever looked at. This is the same unglamorous custody discipline that institutions have been forced to formalise as regulators engage with digital assets, visible in both the FDIC guidance on banks holding bitcoin and the Basel III capital treatment of crypto exposures. Retail users carry a version of the same risk without the committee.

How strong is the evidence behind each claim here?

Below is a self-assessment of the load-bearing claims in this article, including the places where the evidence is thinner than the confident tone of most coverage would suggest. Where a claim rests on a single commercial vendor dataset, treat the number as directional rather than settled.

Evidence strength for each claim made in this article

Claim	Evidence type	Strength
approve grants spend rights of unlimited duration up to a cap	EIP-20 specification text, Final	Strong, it is the standard itself
setApprovalForAll grants control of a whole collection	EIP-721 specification text, Final	Strong
Permit signatures are invisible until redeemed	EIP-2612 text plus a vendor statement from Revoke.cash	Strong on mechanism, vendor source for the tooling limit
Permit is now the largest loss category by value	One vendor dataset, sample of 11 incidents	Weak as a general claim, adequate for 2025 large cases
BadgerDAO cost $121m via injected approval prompts	Microsoft Threat Intelligence analysis, 2022	Moderate to strong, single analyst source
Annual phishing losses fell 83 percent in 2025	Scam Sniffer annual report	Moderate, unaudited vendor measurement
$11.366bn of US-reported 2025 fraud losses involved crypto	FBI IC3 report, read via secondary reporting	Strong source, weak verification path in this article
EIP-7702 phishing is a small share of 7702 delegation activity	Wintermute on-chain research via The Block	Moderate, and it contradicts common headlines
Clear signing will materially reduce blind signing	ERC-7730, still Draft	Weak, this is a forecast and not a measured result
Revoking is a race against a held Permit signature	Mechanism inference plus vendor guidance	Moderate, no public measurement of win rates

Frequently asked questions

Can an attacker drain my whole wallet with one approval?

They can drain the specific token you approved, up to the amount you approved, from the account that granted it. An ERC-20 approval is per token and per spender, so an approval on one stablecoin does not expose an unrelated token. It does not give access to native ETH, and it does not expose your private key or any other wallet you control.

Why did my wallet not warn me when I signed?

Most likely because you signed an off-chain message rather than sending a transaction. Revoke.cash notes that the wallet warnings common for on-chain approvals are "absent" for Permit signatures. There is no transaction to simulate and no gas estimate to show, so the prompt can look like a routine sign-in.

Does revoking approvals get my money back?

No. Revocation prevents future transfers under that allowance and has no effect on tokens already moved. It is still worth doing immediately after any suspected phishing interaction, to close off repeat theft using access the attacker would otherwise keep.

Is a hardware wallet enough on its own?

Not on its own. A hardware wallet protects the key, and approval phishing does not need the key. It helps only to the extent that its screen renders what you are signing into something you can evaluate, which depends on contract-level metadata that ERC-7730 is still standardising in Draft form.

Are NFT approvals riskier than token approvals?

In one specific sense, yes, because setApprovalForAll has no numeric cap and covers every item in a collection including ones you buy later. By measured loss it is the smaller category, with Scam Sniffer recording one case above $1 million through this route in 2025 at $1.23 million. Anyone holding fractionalised or collection-level exposure should read it alongside the structural questions raised about fractional NFTs as an investment vehicle.

Why are stablecoins so often the asset drained?

Because they are widely held, widely integrated, and several major implementations support EIP-2612 permit, which is the lowest-friction authorisation path available to an attacker. The policy environment around these instruments is moving quickly, as set out in the Q2 2026 US Treasury stablecoin guidelines, but none of that regulation changes what an approval on an ERC-20 contract grants.

Sources

• EIP-20: Token Standard, Final, created 19 November 2015
• EIP-721: Non-Fungible Token Standard, Final, created 24 January 2018
• EIP-712: Typed structured data hashing and signing, Final, created 12 September 2017
• EIP-2612: Permit Extension for EIP-20 Signed Approvals, Final, created 13 April 2020
• EIP-7702: Set Code for EOAs, Final, created 7 May 2024
• EIP-7600: Hardfork Meta, Prague and Electra, lists the Pectra EIP set
• ERC-7730: Structured Data Clear Signing Format, Draft, created 7 February 2024
• Uniswap Permit2, AllowanceTransfer concepts, struct and field definitions
• MetaMask MIP-3, eth_sign deprecation, Accepted, created 15 May 2024
• OpenZeppelin issue 4583, removal of increaseAllowance and decreaseAllowance, September 2023
• OpenZeppelin Contracts v5.0.0 release notes
• Microsoft Threat Intelligence, Ice phishing on the blockchain, 16 February 2022
• Scam Sniffer 2025 annual phishing report, 3 January 2026, commercial vendor measurement
• Chainalysis, What is approval phishing, updated 17 June 2026, commercial vendor
• FBI IC3 2025 Internet Crime Report (PDF), released 6 April 2026, primary document that did not render as text for this article
• Decrypt, Signature phishing up 200 percent as January losses pass $6m, 9 February 2026
• Cointelegraph, Crypto whale loses $24m in staked Ethereum to phishing, 7 September 2023, citing PeckShield
• The Block, Wintermute on EIP-7702 delegation risk, 1 June 2025
• Infosecurity Magazine, Inferno Drainer spoofs over 100 crypto brands, 16 January 2024, citing Scam Sniffer and Group-IB
• Revoke.cash, What are EIP-2612 permit signatures, vendor explainer, not a primary source