The data is unambiguous. Over the past three months, 3.66 million transactions on Ethereum have utilized the new EIP-7702 delegation mechanism. Of those, 63%—roughly 2.3 million—were malicious. The total stolen value: $2.36 million. The exposed value: $10.14 million. These numbers come from a comprehensive forensic analysis of the Ethereum mainnet following the Pectra upgrade activation on May 7, 2025. The study, published by a USENIX-affiliated research team, is not a theoretical exercise. It is a cold, empirical audit of a live protocol change. And the conclusion is stark: the security assumptions underpinning EIP-7702 have been systematically broken within its first quarter of operation.
For context, EIP-7702 is a landmark Ethereum improvement proposal that allows externally owned accounts (EOAs)—the classic wallet addresses controlled by private keys—to assume smart contract capabilities temporarily. Instead of migrating to a full smart contract wallet, an EOA can delegate its execution to a piece of code, retaining the same address while gaining programmable logic. This is a crucial step toward account abstraction, enabling gas sponsorship, batched transactions, and other advanced features without forcing users to abandon their existing addresses. The upgrade was celebrated as a pragmatic compromise between the old EOA model and the full power of ERC-4337. But the compromise, as the data shows, came with a hidden cost: the delegation mechanism opened a new attack surface that the ecosystem was not prepared to defend.
The Core: How the Attack Works
The research team analyzed the full set of 3.66 million delegation transactions by extracting data from Ethereum's historical state—a dataset of 22.8 billion prior transactions. They identified 242 distinct malicious contracts that were used as delegation targets. The attack flow is elegant in its simplicity. A user receives a phishing link, connects their wallet, and signs a transaction that delegates their EOA to a malicious contract. The contract then has full authority to execute arbitrary code on behalf of the user's address. This includes transferring ERC-20 tokens, approving spending on DeFi protocols, or even interacting with other contracts in ways that simulate the user's identity.
What makes this particularly dangerous is the re-binding attack. The delegation code is not static. The malicious contract can be updated or replaced after the initial delegation. The research team documented cases where a user approved a seemingly benign contract—one that appeared to perform a simple gas-sponsorship function—and then, hours later, the contract's code was swapped to a theft function. The delegation remained valid, and the user's wallet showed no indication of change. The code doesn't lie. The code was malicious from the start, but the re-binding made it invisible to casual inspection.
Furthermore, the researchers uncovered over 500 contract addresses deployed via CREATE2, a technique that allows pre-computation of a contract's address before it is deployed. These contracts were not yet on-chain during the study, but their addresses are deterministic. Any of them could be activated at any time with malicious delegation logic. This is a ticking time bomb. The attack surface is not limited to the 242 known contracts; it includes 500 dormant ones that can be triggered instantly.
Why Old Defenses Fail
EIP-7702 fundamentally alters the security model of Ethereum transactions. Previously, smart contracts could rely on tx.origin to identify the original sender of a transaction. Many DeFi protocols used this as a defense against phishing: if a transaction was initiated by a smart contract rather than an EOA, the protocol could reject it. With EIP-7702, tx.origin now points to the EOA that delegated, not the contract that executed the code. This single architectural change invalidates all existing security checks that depend on distinguishing between EOA and contract origins. Audits are opinions, not guarantees. The assumptions that were audited for pre-Pectra contracts are now brittle.
I have seen this pattern before. During my forensic audit of the IDEX smart contracts in 2017, I identified a similar mismatch between the design assumptions and the actual execution environment. The developers assumed that the liquidity pool would only be called by the main trading contract, but a reentrancy path allowed direct calls from external accounts. The fix was simple—a state variable check—but the damage was done. EIP-7702's designers assumed that delegation would be a one-time, atomic operation. They did not account for the possibility of code re-binding or the scalability of social engineering attacks. The result is a systemic vulnerability that requires a protocol-level response.
The Contrarian Angle: The Feature Is the Flaw
The conventional narrative around EIP-7702 is that it is a stepping stone toward full account abstraction. The security issues are considered growing pains, to be fixed with better wallet UIs, signed transaction previews, and hardware wallet integration. But the data suggests a more uncomfortable truth: the dynamic delegation model itself is inherently insecure. The ability to delegate arbitrary code to an EOA is a feature that cannot be made safe without sacrificing the very flexibility that makes it attractive.
Consider the re-binding attack. The only way to prevent it is to freeze the delegation code after the initial deployment—a "code freeze" mechanism that would require a new EIP. But that would turn EIP-7702 into a static upgrade model, akin to a proxy contract that cannot be changed. That would limit its utility for use cases like modular smart wallets or DAO-controlled accounts. The alternative is to require all delegation targets to be audited and whitelisted by the wallet provider. This shifts the security burden from the user to the wallet, but it reintroduces centralization and undermines the permissionless ethos of Ethereum.
My own experience reverse-engineering Compound's cToken interest rate models in 2020 taught me that the most elegant technical solutions often hide the most dangerous assumptions. The Compound team assumed that the liquidation thresholds would never be triggered in a fast market crash. They were wrong. Similarly, the EIP-7702 designers assumed that users would never delegate to untrusted code. They were wrong. The market does not care about good intentions. It cares about exploitability.
The Takeaway: A Fork in the Road for Account Abstraction
The Ethereum ecosystem now faces a critical decision. Either we accept that EIP-7702, as deployed, is a security liability that will require aggressive mitigation—including wallet-level denial of delegation to unknown contracts, mandatory code freeze for high-value accounts, and continuous monitoring of the 500 CREATED2 contracts—or we pivot toward a different account abstraction model that does not grant code execution authority to the user's address directly. The lock step is to harden the delegation process with zero-knowledge proofs that verify the integrity of the delegation code before it is executed. But that adds latency and complexity.
Over the next 12 months, I expect a wave of security infrastructure products targeting EIP-7702. Auditors will publish new checklists. Wallet providers will implement "delegation guards" that warn users about suspicious targets. The USENIX study itself is a catalyst for this change. But the market will not forgive another $10 million exposure. The code doesn't lie. The data is clear. The question is whether the Ethereum community will act before the next wave of attacks. The debugging of the economy happens one block at a time. But this time, the bug is in the protocol itself.
