Verified Platforms
Quick Links
Where to Stay Secure
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
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.
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.
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.
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.
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:
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.
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.
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:
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 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.
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.
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.
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.
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.
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.
