The Ethereum mainnet is not waiting for wallets to catch up. EIP-7702 shipped as part of the Pectra upgrade on May 7, 2025, and it changed one of the oldest assumptions in the Ethereum account model. An externally owned account can now temporarily behave like a smart contract by authorizing a code delegation. That was supposed to be the low-friction path to account abstraction. It is. The problem is that the low-friction path also became a fast lane for abuse.
A recent security analysis treated EIP-7702 not as a marketing upgrade but as a live attack surface. The result is unflattering. Within three months of the feature going live, the analysis found more than 3.66 million authorization transactions, and about 63% were tied to malicious use. More than 1.01 million accounts appeared to be involved in suspicious activity. Roughly 1.97 million accounts had been exposed to malicious code, while 196,800 accounts were directly attacked and lost about $2.36 million in Ether and ERC-20 tokens. That is not a large share of Ethereum value, but it is large enough to prove that the feature is already being exploited at scale.
The core idea behind EIP-7702 is technically coherent. It lets an EOA keep its address while borrowing smart-contract capabilities for a limited period. That avoids the heavier migration path of moving users into a separate smart-wallet contract. For Ethereum, that matters because the address itself is a store of identity, history, custody assumptions, and social trust. The protocol gives users a way to add programmability without forcing them to abandon an old account. That is a real design win. It also creates a new trust boundary: a human-owned key now grants a piece of code temporary control over account behavior. In audit terms, that shifts the risk from raw key compromise to authorization compromise. The private key may still be safe. The session created from it may not be.
This is where EIP-7702 becomes dangerous for older code. Many legacy contracts still rely on rules that assumed accounts were simple. The most important one is the difference between msg.sender and tx.origin. Under the old model, that distinction carried meaningful weight. After EIP-7702, the model is less stable. Delegated accounts can alter the way signatures, authorizations, and caller relationships behave. Contracts that treat old EOA assumptions as permanent are now working against a protocol whose semantics just changed. That is not theoretical. The security analysis found that the largest cluster of malicious contracts, accounting for about 55% of malicious addresses, was focused on protocol interactions. A second large cluster, about 20%, used phishing-style wallet redirects. Another group used deceptive rebinding. In practice, attackers are not waiting for exotic exploits. They are weaponizing the new authorization flow itself.
The rebinding behavior is especially concerning. The report found that roughly 10.3% of malicious EIP-7702 accounts repeatedly changed their delegated code and later returned to a benign or neutral contract. On the surface, that looks like cleanup. In reality, it is evasion. It makes simple scanners and dashboards less useful because an address can stop looking malicious after an exploit window closes. The user sees a familiar account again. The contract history does not. That matters because EIP-7702 is a permissioning feature, and permissioning only works if the system can distinguish trusted behavior from temporary compromise.
There is another signal that the problem is not limited to opportunistic scams. The analysis identified about 500 suspicious CREATE2 deployments that were not directly tied to the known malicious addresses. Those kinds of clusters usually mean automation, not one-off bad actors. It suggests there is already infrastructure-level activity around EIP-7702 abuse. If attackers can generate contracts at scale, the defensive side has to move from blacklist thinking to behavioral detection. Blacklists will always lag.
What should be read carefully is that this is not a protocol-breaker in the sense of a consensus fault. Ethereum is still functioning. The damage is narrower than that. But infrastructure changes are not judged only by whether the chain halts. They are judged by whether the downstream ecosystem can safely absorb the new semantics. Here, the answer is not yet yes. Wallets, DeFi protocols, bridges, and compliance tooling all depend on older mental models of the EOA. EIP-7702 did not remove that dependency. It exposed it.
The market reaction should also be treated correctly. A $2.36 million loss does not by itself reprice Ethereum. It does, however, create a security premium for anything built on account delegation. The more the market believes that EIP-7702 is merely a UX upgrade, the wider the gap between adoption and actual readiness. If the abuse rate keeps climbing, the damage will be less about price and more about trust in wallet behavior, DeFi authorization patterns, and the assumption that an EOA is still a stable unit of identity.
The real issue is timing. EIP-7702 reached users before the ecosystem reached a mature defensive standard. The report itself notes that adoption was unusually fast: over 3.66 million transactions in roughly three months. The malicious ratio of 63% shows that attackers moved faster than defensive controls. That is the uncomfortable part. Account abstraction was supposed to mature slowly, behind careful wallet UX, better permissioning, and clearer user warnings. Instead, the protocol feature is now ahead of the safety stack. The contract executes. The ecosystem has to pay for the gap.
A second blind spot is false comfort from benign-looking recovery. When a malicious delegation is removed and the account appears normal again, users and tools tend to reset their risk assessment. That is the wrong response. The account was not restored to innocence. It was restored to a default appearance. Every delegation event should be treated as audit history, not as a transient state that disappears when the code is cleared. This is a direct application of a basic security rule: trust no one, verify everything, build twice.
There is also a subtle economic effect. EIP-7702 improves compatibility by letting assets stay at familiar addresses while gaining smart-account features. That is beneficial for user continuity. But continuity is not the same as safety. If users believe their old address remains the same object as before, they may not understand that it can now execute delegated logic. That creates a consent problem. The protocol can authorize something valid. The user can still be misled about what was authorized. Economic design cannot fix that alone. Wallet UX and contract review have to close the gap.
The implications for DeFi are concrete. Any protocol still relying on old EOA assumptions should treat the review as urgent. Contracts that use tx.origin for anti-phishing checks, or that assume a plain address cannot carry delegated behavior, need a second look. Bridges and multi-step DeFi flows are especially exposed because attackers can hide inside protocol transitions. Layer-2 deployments matter too, because even if the feature originates on Ethereum L1, downstream systems inherit the new semantics whenever they interact with delegated accounts.
The security service industry should also expect a short window of demand. Audits, on-chain monitoring, and wallet risk scoring will all benefit from the fact that the old rules no longer hold. But that demand should not be confused with resolution. More audits are necessary. They are not sufficient. The ecosystem needs a durable model for delegated account permissioning, not another report cycle after the next phishing wave.
The contrarian point is this: EIP-7702 may still be the right direction for Ethereum, but the first phase of its rollout looks less like account abstraction and more like account exposure. Composability is leverage until it is liability. Ethereum gained a powerful way to make EOAs programmable. It did not yet prove that the ecosystem can safely tell the difference between a legitimate authorization and a theft-enabling one. That distinction is not cosmetic. It decides whether account abstraction becomes a foundation or a liability layer.
The next test is whether the next million EIP-7702 transactions look different from the first 3.66 million. If malicious delegation keeps rising above 70%, the feature will be treated as a systemic wallet-risk problem. If wallets, DeFi protocols, and auditors move toward whitelisted delegation, rollback visibility, and stronger caller validation, the upgrade can still mature into something useful. If they do not, Ethereum will have upgraded its accounts while leaving the front door of trust half-open.
The question is not whether EIP-7702 works. It does. The question is whether Ethereum is ready to trust it.