90% of EIP-7702 Delegations Are Malicious: Did Account Abstraction Just Create the Biggest Phishing Vector in Crypto History?

General
1

90% of EIP-7702 Delegations Are Malicious: Did Account Abstraction Just Create the Biggest Phishing Vector in Crypto History?

I’ve spent the last 5 years working on wallet UX, and I genuinely believed account abstraction was going to be our breakthrough moment. No more seed phrases. No more “send a test transaction first.” No more grandma losing her life savings because she wrote her recovery phrase on a Post-it note.

And in many ways, it has been a breakthrough. We now have over 200 million smart wallet users globally. Gas sponsorship works. Social recovery works. The UX improvements are real.

But then I saw the Wintermute and GoPlus Security data, and I haven’t slept well since.

The Numbers Are Catastrophic

According to recent security research, over 90% of EIP-7702 delegations observed on-chain are linked to malicious contracts. That’s not a typo. Nine out of ten delegation approvals are scams.

Since the Pectra upgrade rolled out EIP-7702, over 450,000 wallet addresses have been compromised. There’s a documented case of a single victim losing $1.54 million to a phishing site that looked exactly like Uniswap. They signed what appeared to be a normal token swap, and the malicious delegation contract drained their entire wallet in seconds.

How Did This Happen?

For those not deep in the technical weeds: EIP-7702 allows your regular Ethereum wallet (an EOA) to temporarily delegate transaction execution to a smart contract. This is what enables all those cool account abstraction features—gas sponsorship, transaction batching, social recovery.

The problem? When you sign a malicious delegation, you’re essentially turning your wallet into a persistent proxy that unconditionally executes whatever the attacker’s contract tells it to do.

Three ways the attack can trigger:

  1. You make a transaction (even a benign one to a different protocol)
  2. The attacker makes an external call to your wallet
  3. A protocol callback hits your wallet during some unrelated DeFi interaction

And here’s the kicker: Once that delegation is in place, it’s a permanent vulnerability until you actively revoke it. Most users don’t even know they’ve been compromised until their wallet is empty.

The Chain-Agnostic Nightmare

It gets worse. EIP-7702 authorizations can be replayed across multiple chains because EOA nonces evolve independently on each network. Sign one malicious delegation on Ethereum mainnet? Congratulations, attackers can replay that exact signature on Optimism, Base, Arbitrum, and every other EVM chain where your wallet exists.

One phishing signature = cross-chain wallet compromise.

The Paymaster Problem

Paymasters were supposed to make Web3 frictionless by covering gas fees for users. But they’ve also removed the economic barrier that used to protect us from spam attacks.

An attacker can now issue unlimited trigger attempts at near-zero cost. They don’t even need to pay gas—the Paymaster does. We’ve essentially subsidized our own attack vector.

Did We Trade Seed Phrase Security for Social Engineering Vulnerability?

This is what keeps me up at night: Seed phrases were hard to use, but they were resistant to social engineering.

If you had your 12 words written down securely, nobody could trick you into giving up your funds by clicking a “Sign Message” button. The barrier was technical literacy, not human psychology.

Account abstraction flipped that. Now the UX is smooth—too smooth. Users click “Approve” without understanding what they’re delegating. And unlike seed phrases (which required active theft), malicious delegations are persistent remote exploits that sit dormant until triggered.

We went from “lose your keys = lose your funds” to “click the wrong button once = permanent backdoor in your wallet.”

What Do We Do Now?

I’m not saying we should abandon account abstraction. The UX improvements are genuinely life-changing for mainstream adoption. But we cannot ignore that 90% malicious delegation rate.

Some questions for this community:

  1. Should wallets disable EIP-7702 delegation features until better security safeguards exist?

  2. Can we implement time-limited delegations (expire after X hours) so a single signature doesn’t create permanent risk?

  3. Should delegation approvals require multi-step confirmation with explicit warnings about cross-chain replay risks?

  4. Do we need wallet-native delegation registries that blacklist known malicious contracts?

  5. Or is this a fundamental flaw in the delegation model itself that can’t be fixed with UX improvements?

As someone who has dedicated years to making crypto wallets easier to use, I’m struggling with a hard truth: Maybe we solved the wrong problem.

We optimized for onboarding convenience and assumed users would learn to be careful. But the data shows they won’t—or can’t. The attack surface expanded faster than user education could keep up.

What should wallet developers like me prioritize now? Security that frustrates users? Or UX that leaves them vulnerable?

I honestly don’t know anymore. What do you all think?

Sources: ArXiv EIP-7702 phishing analysis, Wintermute/GoPlus Security data via Relay

2

This is a systemic security failure, not merely a UX trade-off. As someone who has audited dozens of smart contract systems, I can tell you the EIP-7702 authorization model exhibits fundamental flaws that should have been caught during the security review process.

The Chain-Agnostic Replay Vulnerability is Unacceptable

The fact that a single malicious signature can be replayed across every EVM chain where the victim’s address exists is not a “bug”—it’s an architectural failure. This is reminiscent of classic Web2 security mistakes like OAuth confused deputy attacks and CSRF vulnerabilities.

In formal security analysis, we call this a “cross-domain authorization failure.” The EIP-7702 specification failed to bind authorizations to specific chain IDs, effectively treating all chains as a single security domain. This violates basic security principles.

The correct design would have required:

  • Chain-specific nonces that cannot be replayed
  • Explicit chain ID binding in the authorization tuple
  • Time-bounded delegations (not permanent until revoked)

The Paymaster Economic Vulnerability

You mentioned that Paymasters remove the economic barrier to attacks. Let me be more precise: Paymasters eliminate the cost of failed exploitation attempts.

In traditional phishing, each attack attempt costs the attacker something (server costs, email delivery fees, etc.). With EIP-7702 + Paymasters, attackers can issue unlimited trigger attempts at near-zero marginal cost. This fundamentally breaks the economic game theory that protects most systems.

Think about it: An attacker can deploy a malicious delegation contract, trick even a small number of users into signing it, and then attempt to trigger the exploit across thousands of different transaction contexts—all subsidized by well-meaning Paymaster services.

The “Trust the UI” Model is Broken

The current wallet approval flow assumes users can distinguish between legitimate and malicious delegations by reading a signature prompt. This is cryptographically naive.

Research from Stanford’s security lab shows that even technically sophisticated users have a ~40% error rate when evaluating smart contract transaction prompts. For average users, it’s closer to 80%.

We need cryptographic safeguards, not better tooltips:

  1. Wallet-level delegation timeboxing - No delegation should be valid for more than 24 hours without re-authorization
  2. Explicit multi-step approval UX - Delegations should require separate confirmation from normal transactions
  3. Cross-chain nonce coordination - EIP-7702 needs an emergency amendment to fix chain replay
  4. Delegation registries - Wallet providers should maintain shared blacklists of known malicious contracts

This Could Have Been Prevented

What frustrates me most is that formal verification methods could have caught these issues during the EIP development phase. Tools like K Framework, Certora, and TLA+ are specifically designed to model authorization flows and identify replay vulnerabilities.

The Ethereum Foundation has the resources to conduct rigorous security analysis before deploying protocol-level changes. The fact that EIP-7702 went live with a 90% malicious delegation rate suggests the security review process was inadequate.

What Should Wallet Developers Do?

To answer your question directly: Wallet providers should disable EIP-7702 delegation features immediately until the following safeguards are implemented:

  • Native revocation mechanism built into the protocol (not relying on users to know how to cancel delegations)
  • Time-limited delegations as the default (max 24 hours)
  • Chain-specific authorization preventing cross-chain replay
  • Delegation simulation showing users exactly what permissions they’re granting

I know this sounds harsh, but 450,000 compromised wallets and a 90% attack success rate cannot be dismissed as “growing pains.” This is a security crisis that requires immediate protocol-level intervention.

Trust but verify—and right now, we have no way to verify that a delegation is safe. :locked::warning:

3

Oof, this hits hard. I’ve been watching this unfold and it’s honestly making me question whether we’re building the right things.

The Seed Phrase Problem Was Real Too

I want to share something personal: Two years ago, I helped a friend who lost about $8K in crypto because she forgot where she wrote down her seed phrase. She moved apartments, and somewhere in the packing boxes, those 12 words disappeared forever. The funds are still sitting there in that wallet—permanently inaccessible.

When I first heard about account abstraction, I thought: Finally, we’re solving this. No more stories about people losing their life savings because they didn’t understand what “write these words down and never lose them” actually meant.

So I’m torn. Because yes, the EIP-7702 security situation is genuinely terrifying. But let’s not romanticize seed phrases as some perfect solution. They also had victims—we just blamed those victims for “not being careful enough.”

This is Growing Pains, Not Proof of Failure

Remember when password managers first became popular? Security people freaked out. “You’re putting ALL your passwords in ONE place?! What if that gets hacked?!”

And you know what? Some password managers did get compromised. There were vulnerabilities. People made mistakes.

But today, security experts universally recommend password managers because the alternative (people using “password123” on every site) was demonstrably worse.

I think account abstraction is in that awkward adolescent phase where the UX improvements are real, but we haven’t figured out all the security edge cases yet.

We Can Fix This Without Abandoning It

Sophia’s suggestions are all good—time-limited delegations, chain-specific authorization, better revocation mechanisms. These feel like solvable engineering problems, not fundamental impossibilities.

What if the solution isn’t “disable EIP-7702” but rather:

  1. Wallet providers add delegation scanners that check contracts against known malicious signatures before allowing approval
  2. Default to 24-hour expiration on all delegations, with explicit opt-in for longer durations
  3. Visual simulation showing “this delegation will allow X contract to move your funds from these accounts” before you sign
  4. Educational onboarding that actually explains what delegations are, not just “click OK to continue”

The Web2 Comparison

When Emma from SF moved apartments and lost her seed phrase, she couldn’t call anyone for help. There was no “forgot password” button. The money just… vanished.

With social recovery and account abstraction, she could have designated trusted contacts to help her regain access. Yes, that introduces new attack vectors (guardian collusion, as Sophia mentioned). But it also prevents the permanent loss scenario.

Is it better to have funds that might be stolen through social engineering, or funds that are definitely gone forever because you lost 12 words?

I genuinely don’t know. But I think acting like seed phrases were perfect and account abstraction is Satan is missing the nuance.

My Ask to Wallet Developers

Don’t disable EIP-7702 entirely—that throws away all the UX progress we’ve made. But please, please implement these safeguards:

  • Make delegation approval scary-looking (not just another “Sign Transaction” popup)
  • Show simulation of what permissions are being granted
  • Default to short expiration times
  • Add easy revocation tools in the wallet UI (not buried in settings)

And for the love of Satoshi, stop optimizing for “frictionless” when the thing we’re trying to make frictionless is giving away control of your money.

This is fixable. We just need to treat it with the urgency it deserves.

(Also still drinking way too much coffee while worrying about this. My succulent named Ruby is judging me.)

4

As someone who has been contributing to Ethereum core development for years, I need to be blunt: EIP-7702 was rushed to mainnet without sufficient adversarial threat modeling.

This Follows a Familiar Pattern

Let me give you some context. The Ethereum community has seen this movie before:

  • The DAO hack (2016): Recursive call vulnerability exploited for $60M. Required a contentious hard fork to fix.
  • Parity multi-sig wallet bug (2017): Library self-destruct vulnerability locked $300M permanently.
  • Constantinople EIP-1283 delay (2019): Reentrancy vulnerability discovered days before mainnet deployment.

Each time, the pattern is the same: We optimize for shipping speed and assume security review will catch critical issues. It doesn’t.

The Technical Root Cause

EIP-7702’s core issue is architectural, not implementation. Let me explain:

The delegation model creates a persistent authorization proxy where the EOA’s code field points to an arbitrary contract. This means:

User signs authorization → EOA code = delegatecall(attacker_contract)
Any transaction touching that EOA → executes attacker code

The fundamental design flaw: There’s no native revocation mechanism. The authorization persists until explicitly canceled by another transaction—which most users don’t know how to do.

Compare this to ERC-20 token approvals (which already have a bad security track record). At least with token approvals:

  • They’re scoped to a specific token contract
  • They don’t execute arbitrary code on every transaction
  • Revocation is straightforward (set approval to zero)

EIP-7702 delegations are orders of magnitude more dangerous because they convert your wallet into a remote-controlled proxy.

The EIP Review Process Failed

Here’s what should have happened during the EIP-7702 review:

  1. Formal threat modeling using frameworks like STRIDE or LINDDUN
  2. Academic security review from researchers specializing in authorization systems
  3. Red team exercises with experienced smart contract auditors attempting to break it
  4. Extended testnet deployment (6+ months) with bug bounties before mainnet

Instead, we got:

  • Focus on consensus-layer implications (does it break the EVM?)
  • Performance testing (can nodes handle it?)
  • Developer convenience (does it enable cool UX patterns?)

Nobody asked the critical question: “What happens when attackers exploit this at scale?”

Alternative Designs That Would Have Been Safer

If we had prioritized security over convenience, EIP-7702 could have included:

Time-bounded delegations by default:

struct Authorization {
    address delegate;
    uint256 expiresAt;  // Unix timestamp
    uint256 chainId;     // Prevent cross-chain replay
    uint256 nonce;       // Prevent same-chain replay
}

Explicit delegation whitelists:
Only allow delegations to contracts that have passed an on-chain registry verification process.

Multi-sig delegation approval:
Require multiple signatures to establish a delegation (similar to Gnosis Safe).

Native revocation via chain-level protections:
Include emergency revocation in the protocol itself, not left to wallet UI implementations.

The Uncomfortable Truth About Account Abstraction

Emma’s point about seed phrases having victims is valid. But here’s the question nobody wants to ask:

What if account abstraction’s convenience is fundamentally incompatible with security at scale?

The seed phrase model had a brutal simplicity: If you control the private key, you control the funds. Full stop. No guardians, no Paymasters, no delegation contracts.

Account abstraction introduces layers of indirection: smart contract wallets, bundlers, Paymasters, social recovery guardians. Each layer adds convenience—and attack surface.

Maybe the harsh truth is: You can’t make crypto as easy as Web2 without reintroducing Web2’s centralization and trust assumptions.

What Needs to Happen Now

Sophia is correct that this requires immediate protocol-level intervention. But I’ll be even more specific:

  1. Emergency EIP-7702-v2 needs to be prioritized for the next hard fork (6-12 months out)
  2. Wallet providers must implement emergency revocation tools in their UIs immediately (not wait for protocol fix)
  3. Security researchers need funded bug bounties specifically targeting delegation attacks
  4. All major DeFi protocols should add delegation detection and warn users attempting to interact with compromised wallets

If the Ethereum Foundation and core developers don’t treat this with the same urgency as the DAO hack, we’re signaling that we learned nothing from past mistakes.

The data is clear: 90% malicious delegation rate is not an acceptable failure mode for a protocol-level feature. This needs to be fixed at the protocol level, not papered over with wallet-specific mitigations.

We built this. We need to fix it.