July 9, 2026. A whale on Ethereum loses $990k USDT. No private key stolen. No contract exploit. The attacker did one thing: convinced the user to sign a token approval transaction. Then, in a single bundle, drained everything.
This is not new. Token approval phishing is as old as DeFi. But the weapon has been upgraded. The attacker used Multicall—a standard contract optimization—to execute three transferFrom calls in one atomic transaction. The victim had no time to react. The wallet alert never fired.
Let me be clear. This is not a protocol bug. This is a feature of the ERC-20 standard being weaponized. The approve / transferFrom pair is the backbone of DeFi composability. You approve Uniswap to spend your tokens, and later you swap. But when a user approves a malicious contract, that contract can drain the entire allowance in one block. And Multicall makes it silent, fast, and irreversible.
Context: The Approval Attack Surface
Scam Sniffer's latest report shows a 200% year-over-year increase in phishing losses. The attack vector is consistent: a fake front-end, a convincing interface, a signature request. The user signs approve for infinite allowance. Then the attacker calls transferFrom to move the funds. In 2025, the drain was slow—multiple transactions, block by block. Wallets could blacklist the attacker's address after the first transfer. But now, with Multicall, everything happens in one transaction.
Trust the code, verify the trust. The code executed is legitimate. The transferFrom is valid because the user granted approval. The Ethereum protocol did exactly what it was designed to do. The fault lies in the user's trust decision, not in the execution.
Core: How Multicall Makes Attacks Harder to Detect
Let me break down the attack from a technical perspective. The victim interacts with a phishing site that mimics a legitimate DeFi app. The site asks for a token approval. The user signs an approve transaction, granting the attacker's contract unlimited access to their USDT.
Step one: user signs approve(spender=0xMalicious, amount=infinite).
Step two: the attacker's contract receives the approval. It calls transferFrom(victim, attacker, 990k USDT). But instead of making three separate transactions (USDT on Ethereum), the attacker bundles them into one call using Multicall.
Ethereum's Multicall contract (0xcA11bde05977b3631167028862bE2a1739768A11) is a widely used utility that allows batched calls. The attacker's contract calls Multicall.aggregate([transferFrom1, transferFrom2, transferFrom3]). The result: three separate token transfers execute within the same block, all before the victim's wallet can detect the first transfer.
Standard wallet alerts check for known malicious addresses or suspicious transferFrom patterns. But because Multicall is a legitimate contract, the warning system looks at the outer call (Multicall) and sees a benign interaction. The inner calls are opaque to the wallet's front-end logic. The victim sees a single transaction labeled 'Multicall'—no red flags.
Complexity hides the truth; simplicity reveals it. Here, the attacker uses complexity (batching) to hide the truth (the theft). The wallet's simplicity (only checking top-level calls) becomes its blind spot.
Contrarian: Security Tools Are Not the Solution
Most commentary on this event will call for better wallet alerts, more transaction simulation, and improved blacklists. That is backward. The real contrarian insight: these tools create a false sense of security. They make users believe they can safely click any link as long as the wallet doesn't flag it. But the wallet cannot flag what it cannot see.
The Ethereum protocol allows any user to call any function on any contract, provided they have the necessary approvals. This is by design. The problem is not a missing feature; it is the user's inability to verify the consequences of a signature. Transaction simulation (e.g., Rabby's simulation) can help, but it requires the user to actually check the simulation results. In practice, users ignore them.
Security is not a feature; it is the foundation. But here the foundation is solid. The vulnerability is not in the code—it is in the human. The industry's obsession with building better detection tools avoids the uncomfortable truth: users must change their behavior. Never approve unlimited allowances. Use revoke.cash weekly. Only approve specific amounts for specific contracts. And never, ever approve a contract you have not verified off-chain.
Yet the industry will not say this because it reduces onboarding speed. The tension between usability and security is the root cause. The attacker exploits this tension.
Takeaway: The Arms Race Has Begun
This attack is not an outlier. It is a template. Over the next six months, I expect a wave of similar attacks targeting high-value wallets. Attackers will use on-chain data to identify addresses with large token balances and existing approvals. They will craft phishing sites that mimic popular dashboards or yield farms. And they will use Multicall or similar batching to drain funds before the victim blinks.
The defensive response must be two-fold: mandatory transaction simulation (not optional) in every wallet, and a cultural shift that treats signing an approval as seriously as handing over your private key. Until then, the math doesn't lie. Every 200% increase in phishing losses tells us one thing: the attacks are working, and the defenders are behind.
A bug fixed today saves a fortune tomorrow. But this is not a bug. It is a design trade-off that we refuse to acknowledge. The question is not whether the next whale will get drained—it is when.
