EIP-7702 vs ERC-4337: Which Account Abstraction Is Safer?

By the Guardian team Updated November 2026 6 min read

Quick answer. Use ERC-4337 smart accounts for key rotation and recovery, accepting EntryPoint, bundler and paymaster dependencies. Use EIP-7702 to upgrade existing EOAs; the original key keeps full control. Or combine them: a 7702 EOA can run 4337 account code.

Watch: EIP-7702 vs ERC-4337: Which Account Abstraction Is Safer? 1:56

Video transcript

EIP-7702 and ERC-4337 both give users smart accounts, but they fail in different ways. ERC-4337 trades key risk for infrastructure risk. EIP-7702 drops the infrastructure and keeps the key risk.

ERC-4337 account code can rotate keys and build in recovery. With EIP-7702, an existing EOA runs delegate code, but its original key keeps full control.

In June 2025, The Block reported Wintermute's finding that over 80 percent of EIP-7702 delegations pointed to copies of one sweeper contract, built to drain wallets with leaked keys.

Phishing needs just one signature. An authorization signed with chain ID zero is valid on every chain, so show the delegate address before users sign.

Delegation also breaks old assumptions. Guardian's public reports found bypassed allowlists, has code checks that now pass, and signatures that stop validating. The EIP warns origin checks can break too.

Smart accounts move trust into the EntryPoint. In 2023, Fireblocks found UniPass wallets where anyone could swap the trusted EntryPoint. They were patched, and Fireblocks says all funds are safe.

Give new users and treasuries a 4337 smart account. Existing users can keep their address with 7702 and an audited delegate. Or combine both, guarding the EOA key as the master key. Exchanges should refuse unplanned authorizations.

Guardian audits delegates, account code and paymasters, and pentests wallet signing flows. Read the full comparison, or talk to Guardian before your users sign.

EIP-7702 went live on Ethereum mainnet with the Pectra upgrade on May 7, 2025. Wallet and app teams now have two routes to smart accounts.

ERC-4337 gives users a new contract account. EIP-7702 lets an existing EOA run contract code at its own address.

They fail in different ways. Here is how each works, where each breaks, and when to combine them.

How Each Works

EIP-7702: code on an EOA

EIP-7702 adds a transaction type, 0x04, that carries a list of authorizations. Each one is signed by an EOA's own key and names a delegate contract.

The EOA's code becomes a 23-byte pointer: 0xef0100 plus the delegate's address. Calls to the EOA then run the delegate's code.

The delegation stays until the key signs a new one.
Delegating to the zero address clears it.
An authorization signed with chain ID 0 is valid on every chain.

ERC-4337: a contract account

ERC-4337 needs no consensus change. Users sign a UserOperation, which travels through a separate mempool.

Bundlers package UserOperations into one call to the EntryPoint.
The EntryPoint is a singleton contract that validates and executes them.
Paymasters can pay gas on a user's behalf.
Factories deploy the account on first use.

The account's own code decides what counts as a valid signature. A lost or leaked key can be replaced.

Security Compared

Risk	EIP-7702	ERC-4337
Root key	The original EOA key keeps full control	Set by account code; can be rotated
Recovery	Can be added; the original key can override it	Can be built in, with no permanent key
Phishing surface	One signed authorization installs code	Malicious modules or account upgrades
Upgrades	Re-delegation; old storage stays	Whatever upgrade logic the account defines
Infrastructure	None required; sponsors need a relayer	EntryPoint, bundlers, paymasters
App assumptions	EOAs now have code	Accounts are contracts from the start

In short: ERC-4337 trades key risk for infrastructure risk. EIP-7702 removes the infrastructure and keeps the key risk.

Key and Recovery Risk

With EIP-7702, the EOA's private key never goes away. Nethermind puts it plainly: "If the private key of the EOA is compromised, the attacker will have full control over the account."

That key can also bypass the delegate's own rules. Guardian's Ethena Pay review found a raw ECDSA signature could authorize what a delegated owner's ERC-1271 policy rejected (L-14, acknowledged).

Attackers already use 7702 against leaked keys. In June 2025, The Block reported Wintermute's finding that over 80% of EIP-7702 delegations pointed to copies of one sweeper contract.

Wintermute nicknamed it CrimeEnjoyor. It sweeps wallets whose keys have leaked.

Phishing is the second path. SlowMist urged wallet providers to prominently display the target contract to cut phishing risk, The Block reported.

One signature is enough, as with Permit2 phishing. In a December 2025 paper, researchers showed one chain ID 0 authorization installing the same delegate on three test chains.

The Binance case

Exchanges are targets too. In the Binance hack, Binance says the attacker set up EIP-7702 delegations. These gave an attacker-controlled contract "partial execution rights" over a hot wallet.

Suspending withdrawals alone could not stop them, Binance says. The hot wallet used multi-party computation (MPC), so "there was no single private key" to revoke them at once.

TRM Labs advises treasury teams to:

alert on any delegation: code at an address that should have none
keep a tested, pre-approved way to sign a revocation
reject EIP-7702 authorizations unless they are expected
treat requests for many authorizations across nonces as a sign of compromise

Delegate and Storage Risk

A 7702 account is only as safe as its delegate. The EIP warns that a poorly implemented delegate can let an attacker take "near complete control over a signer's EOA."

Nethermind's April 2025 analysis flags two design risks:

Initialization. Delegation runs no initcode, so setup in a later call can be front-run.
Storage. Re-delegating does not clear storage, so a new delegate can misread old slots.

The EIP adds two more points:

Signed setup. Delegates must check that setup calldata is signed by the EOA's key.
No rollback. Delegations stay in place even if the rest of the transaction fails.

The EIP calls changing delegates "a security-critical operation that should not be done lightly." When in doubt, it recommends clearing storage first.

What 7702 breaks in your contracts

Any contract that assumed EOAs have no code needs a second look. These are from Guardian's public reports:

Allowlists and KYC gates: a listed EOA can delegate to code that relays calls for anyone (Manifest, Nashpoint, Limit Break).
Contract checks: a delegated EOA has a code size of 23, so "has code" checks pass (246 Club).
Signatures: an EOA's unused signatures can stop validating once it has code (USDT0).
Delegate trust: a delegated account can also send ordinary transactions, skipping its template (Veranta).
Gas: a delegated recipient can burn forwarded gas and stall a batch (Ethereal).
tx.origin guards: the EIP says checks like tx.origin == msg.sender can break.

Bundler and Paymaster Risk

ERC-4337 moves trust into shared contracts. The standard says the EntryPoint "will need to be audited and formally verified" because it is a central trust point.

Accounts must accept calls only from a trusted EntryPoint. Fireblocks showed what happens when that slips.

In 2023, it found that UniPass wallets with the 4337 module accepted an empty signature that could reach a setEntrypoint function. Anyone could swap the trusted EntryPoint and take over the wallet.

Several hundred users were exposed. UniPass patched the vulnerable wallets in a whitehat operation, and Fireblocks says all funds are safe.

Paymasters keep a deposit at the EntryPoint, which pays for every operation they approve.
Paymaster stakes are never slashed; they only resist Sybil attacks.
Bundlers are how UserOperations reach a block. Plan for one going offline.

EIP-7702 avoids the EntryPoint, not every dependency. The EIP warns that sponsored 7702 transactions can make relayers spend gas without being repaid.

Using Both Together

The two are not rivals. EIP-7702 was designed so an EOA can point at existing ERC-4337 wallet code and join 4337 bundles.

ERC-4337 now supports this directly. Bundlers must include each UserOperation's 7702 authorization, and the operation hash can commit to the delegate address.

Use that commitment. Without it, the standard says an operation "can be potentially executed against a modified account."

New users and treasuries: a 4337 smart account, with no permanent key.
Existing users keeping their address: 7702 to an audited, widely used delegate.
Both: delegate to 4337 account code, and guard the EOA key as the master key.
Exchanges and custodians: refuse to sign authorizations you did not plan.

How Guardian Helps

Guardian's smart contract audits cover delegates, account code, paymasters and the contracts they touch. The findings linked above come from those public reports.

For wallet teams, a browser extension pentest checks signing flows: whether what gets signed matches what the user saw. See all audits and pentests.

Frequently Asked Questions

Is EIP-7702 safe?

Used carefully, yes, but it adds risk. The original key keeps full control, one authorization can install malicious code, and the delegate's bugs become yours. Use an audited delegate, show its address before signing, and avoid chain ID 0 authorizations.

How do I revoke an EIP-7702 delegation?

Sign an authorization to the zero address and submit it in a type 0x04 transaction; EIP-7702 then resets the account's code. If the key may be compromised, that is not enough: the attacker can delegate again, so move the funds.

Does EIP-7702 replace ERC-4337?

No. EIP-7702 gives an EOA code. ERC-4337 is the system for validating, bundling and sponsoring account operations. ERC-4337 now accepts 7702 authorizations, so an EOA can delegate to 4337 account code and use bundlers and paymasters.

Can EIP-7702 remove a compromised key?

No. A delegate can add signers, limits and recovery, but the original EOA key can still sign transactions and new authorizations. If that key may be exposed, move assets to a fresh account instead of delegating.

Sources

Audit your smart account before users sign

Guardian reviews 7702 delegates, 4337 accounts and paymasters, and the contracts whose assumptions they break.

Get an audit quote Explore audits and pentests