- A token approval is a standing on-chain allowance that lets a smart contract pull a token from your wallet with no further signature, and it stays live until you revoke it.
- The drain runs through transferFrom(), which never asks you to sign again, so checking only the transactions you approved leaves every forgotten allowance open: that gap drained the $7.5M jaredfromsubway.eth bot on June 21, 2026 through 66 counterfeit-token approvals it issued itself.
- Revoking only closes the door against future draws, so audit and cancel unused approvals on a schedule before you become a target, not after the tokens are already gone.
The most profitable predator on Ethereum was not hacked. No stolen key, no leaked seed phrase, no bug in its code. On June 21, 2026, the bot that had pulled an estimated $60 million a year out of other people's trades was drained of more than $7.5 million through token approvals it had granted itself and forgotten to close.
The danger was never the transaction it signed.
It was the permission it left standing afterward.
This walkthrough stays with Tao, the bridge between structure and instinct at Kodex, the one who reads a mechanism slowly enough to feel where it bites. He takes apart what a token approval really grants, why the standing allowance outlives the trade that created it, and how to find and revoke the ones already sitting in your wallet.
Tao starts with his own. He opens the approval list, the record of every contract he has ever allowed to move his tokens, and scrolls. A decentralized exchange he used once in 2024. A bridge he tried and abandoned. Two NFT marketplaces. A staking contract whose name he no longer recognizes. Nineteen open approvals. Four of them unlimited.
He signed every one of these. He remembers almost none of them.
"None of these are attacks," he says. "That is what bothers me." Each was a normal click on a normal day. Each is still live.
What a token approval actually authorizes
The thing Tao is looking at is not a payment. It is a permission.
When you trade on a decentralized exchange, the exchange's contract has to move your tokens for you. ERC-20 tokens do not let a contract reach into your wallet by default, so first you sign one transaction that says: this contract may spend up to this amount of this token, on my behalf, from now on. In the token's code that call is approve(spender, amount). It writes a single number, an allowance, into the token contract next to your address.
That allowance is keyed to three things: the token, your wallet, and the one spender contract you approved. Approve a different contract, or a different token, and you have written a separate allowance. Nothing ties them together and nothing cleans them up. This is why the list grows. Every approval is its own door, and the token contract remembers each one until you go back and shut it.
After that, the spender takes the tokens with a second call, transferFrom(), which pulls from your balance without asking you again. This is the deeper meaning of who controls a token: ownership on-chain is not who holds the coin, it is who is permitted to move it.
The approval is not the trade.
It is the standing grant that makes every future trade possible.
And it does not expire on its own. The allowance you wrote in 2024 is exactly as valid today, sitting in the token contract, waiting, until the day you set it back to zero.
The transaction you sign is not the transaction that drains you
Here is the question that undoes careful people. If you only ever signed approvals, never a withdrawal, how does anything leave your wallet without your signature?
Because the withdrawal was never yours to sign.
approve() is the transaction you see. It creates the allowance. The drain runs on transferFrom(), called by the spender, against the permission you already granted. No popup. No confirmation. Nothing for you to check, because from the chain's point of view you already said yes.
| What happens | approve() | transferFrom() |
|---|---|---|
| You sign it | Yes, once | No, never again |
| It creates | a standing allowance | a withdrawal that spends the allowance |
| It runs | the moment you approve | any time the allowance stays open |
| In your wallet | a normal approval prompt | nothing to confirm |
The signature is the door.
The withdrawal is someone walking through it later, while you are asleep.
This is why "I checked every transaction I signed" is not protection. The transaction that empties the account is the one you do not sign. It is also why an approval drain is a different animal from the scams that steal your keys: no phishing site caught Tao's seed phrase, no malware copied his private key. The attacker never needs them. He needs a permission you already gave.
How a $7.5M bot got drained by its own approvals
jaredfromsubway.eth was, for two years, the most active sandwich bot on Ethereum, named in research for roughly 70% of sandwich attacks on the network between late 2024 and late 2025. It made its money front-running other people's swaps. It was automated, fast, and very hard to fool.
Someone fooled it with its own logic.
Over weeks, the attacker deployed 66 counterfeit token contracts, fakes built to imitate WETH, USDC, and USDT, and wrapped them in liquidity pools designed to read as profitable opportunities. The bot's whole job was to spot a profitable route and take it. To take these routes, it approved attacker-controlled helper contracts to spend its tokens. crypto.news traced how the trap closed: early on the approvals looked harmless, because each trade used the allowance immediately. Later, the attacker built routes that left the allowance open.
That was the whole attack.
CoinDesk put the drain at more than $7.5 million, and the security firm Blockaid confirmed what it was not: not a contract bug, not phishing, not a private-key leak. The bot authorized spending on pools it could not tell were fake, and the standing permissions it left behind were swept clean. Real WETH, USDC, and USDT pulled out, and pushed through Tornado Cash.
The trap worked because on-chain data wears an air of authority. It is real code on a real chain, and the bot trusted a liquidity pool the way everyone trusts a confirmed transaction. Fabricated and false are not the same as fake-looking. A pool can be genuine code, fully on-chain, and still be bait. Reading the data perfectly is no defense when the data was built to be read.
Tao sets his coffee down. "It checked the same thing I check," he says. "Is this trade profitable, is this contract safe. And it died on the permission, not the trade."
The bot's defense was the obvious one: verify the transaction in front of you. Its exposure was the permission behind it. Strip away the $7.5 million and the counterfeit pools, and the mechanism is the one sitting in Tao's wallet, and probably yours. Any contract you ever approved can spend up to its allowance until you take that allowance back.
Why your wallet quietly fills with open doors
Tao's nineteen approvals did not arrive all at once. They accumulated the way they always do.
Four forces fill a wallet with open permissions:
- Unlimited by default. An approval can be capped at the exact amount you are spending, but the one-click option is usually the maximum the token allows, an allowance large enough to cover your entire balance, with no expiry. Convenient on the day. Open-ended forever after.
- Approval fatigue. The prompts look identical, so you stop reading them. The fiftieth approval gets the same reflex click as the first.
- Disconnecting is not revoking. Hitting "disconnect wallet" ends your session with the site. It does not touch the allowance. The permission lives in the token contract whether the tab is open or closed.
- The contract can change underneath you. An approval you gave a safe-looking protocol stays valid if that protocol is later exploited, its admin keys compromised, or it is upgraded into something else. Your allowance does not know the difference.
This is the same blind spot that protecting your wallet from malware in your tools lives in: the threat is rarely the thing you are watching. It is the trusted, boring permission you granted once and stopped thinking about.
A forgotten approval is not dormant.
It is armed.
Does revoking an approval get your stolen crypto back?
No. And this is the part that stings.
Revoking an approval sets the allowance back to zero. It closes the door against the next withdrawal on that permission. It cannot reach back through a door that already swung. Tokens that were pulled are gone, settled, final, and on-chain there is no support line to call and no transaction to reverse.
So revoking is not a cleanup you reach for after something breaks. It is what you do while nothing is wrong, so there is no open allowance waiting when an approved contract turns hostile. You revoke before you are a target, because afterward the only door left to close is the one the attacker already used. Securing the wallet, the way securing your wallet lays it out, is a set of habits you build in the quiet, not in the emergency.
The time to close a door is before someone walks through it.
How to see and revoke your approvals
Your approvals are public.
So is closing them.
Every allowance you have granted is recorded on-chain against your address. You can read the list on a block explorer's token-approval checker, or in one of the wallet tools that present the same on-chain data more plainly, revoke.cash among them. Kodex sells no revoke product and has no reason to push one. The point is the habit, not the brand.
Three moves:
- Read the list. Sort by most recent, or by largest allowance. Anything you do not recognize, or no longer use, is a candidate to close.
- Revoke what you do not need. Revoking is itself an on-chain transaction, so it costs a small gas fee, cents on an L2, more on Ethereum mainnet when the network is busy. That fee is the cheapest insurance you will buy all year.
- Prefer limited over unlimited. When a wallet offers to cap an approval at the amount you are actually spending, take it. You will approve a little more often. You will never again carry an open-ended allowance you forgot about.
Tao works down his nineteen. The bridge he abandoned: revoked. The unlimited USDC approval to an exchange he has not touched in a year: revoked. The two he still uses, he caps to a limited amount and keeps. Six minutes. A few cents in gas.
"That is the whole defense the bot didn't have," he says.
The allowance audit, on a schedule
The lesson of the $7.5 million is not that the bot was careless. It read every trade. It is that reading the trade was never enough, because the exposure was never the trade.
So the discipline is small and repeatable. Before you sign an approval, read it as four questions: what token, how much, to whom, for how long. Then put a revoke pass on a cadence, monthly, or every time you finish with a protocol, the same way the Survival Framework treats risk as something you manage before the position moves against you, not after. Carrying fewer open allowances is exactly the kind of structural exposure Kodex's Pattern Intelligence is built to surface: the quiet, repeated habit that costs nothing until the one day it costs everything.
The bot that drained everyone else died on a door it left open. The forgotten approvals in your wallet are the same door.
Close them while they are still boring.
FAQ
What is a token approval?
A token approval is permission you grant a smart contract to spend a specific token from your wallet, up to a set amount, through the approve() function. It is what lets a decentralized exchange, bridge, or marketplace move your tokens during a trade. The permission stays active until you revoke it.
Does disconnecting my wallet revoke its approvals?
No. Disconnecting ends your session with a site but leaves every allowance you granted untouched in the token contract. An approved contract can still spend against that allowance after you disconnect. Only an on-chain revoke transaction sets the allowance back to zero.
What is an unlimited (infinite) approval?
An unlimited approval sets the allowance to the maximum value the token allows, so the contract can spend any amount of that token, with no cap and no expiry. It saves you from re-approving, and it means one compromised contract can reach your entire balance of that token. A limited approval caps the spend at the amount you actually need.
Can a hardware wallet stop an approval drain?
Not on its own. A hardware wallet protects your private key, but you still sign the approve() with it, and signing on a device does not revoke a standing allowance. The protection is reading approvals before you grant them and revoking the ones you do not need, hardware or not.
How often should I revoke token approvals?
A monthly pass is a reasonable rhythm, plus a revoke any time you stop using a protocol or finish a one-off interaction. The goal is to carry as few open allowances as possible, so a contract that turns hostile later finds nothing of yours still permitted.
You cannot revoke a paper allowance, but you can drill the blind spot behind one. Open a position in the Kodex simulator without a cap on your downside, walk away, and watch the loss arrive from the exposure you left standing rather than the entry you approved. Set the cap up front and run the same market again: the danger moves from invisible to bounded, and the habit of closing risk in the quiet becomes muscle long before it can cost you anything real.
