EIP-7702 Delegation Risks: What to Check Before Signing
One signature can make your account run someone else’s code. What should your wallet check before it signs?
IN 30 SECONDS
An EIP-7702 delegation is a signed permission that makes an ordinary account run a contract’s code. A badly built delegate can hand an attacker near-complete control, and attackers already use this. Wallets should check the chain, the nonce and the delegate’s audited code before signing.
KEY TAKEAWAYS · 3
- A 7702 delegation persists until replaced, and the 7702 spec warns a poorly built delegate can give an attacker near-complete control of the account.
- A USENIX Security ’26 paper associated over 63% of the 7702 authorizations it studied, on seven chains before 15 July 2025, with malicious attacks on EOAs.
- Before signing, a wallet should check the chain and the nonce, and that the delegate is on an audited list with matching code.
On this page
What can go wrong with an EIP-7702 delegation?
IN SHORT A 7702 delegation hands your account to the delegate’s code, so a badly built delegate can cost you the account.
WORDS TO KNOW
- EOA
- An “externally owned account”: a plain Ethereum account controlled by one private key.
- Delegate
- Under EIP-7702, the contract whose code an ordinary account points to and runs as if it were its own.
- Authorization
- The signed message that makes an EOA point at a delegate. It names the chain, the delegate’s address and a nonce.
- Nonce
- A counter of the transactions an account sends and the authorizations processed for it, so an old signature can’t be replayed.
What follows comes from the spec and a USENIX Security ’26 paper.
IN PLAIN WORDS
EIP-7702, created in May 2024, is Final and live since Pectra on 7 May 2025. It lets an EOA An “externally owned account”: a plain Ethereum account controlled by one private key. See the glossary sign an Authorization The signed message that makes an EOA point at a delegate. It names the chain, the delegate’s address and a nonce. See the glossary that points it at a Delegate Under EIP-7702, the contract whose code an ordinary account points to and runs as if it were its own. See the glossary. The old key still works too. The spec is blunt about the risk:
A poorly implemented delegate can allow a malicious actor to take near complete control over a signer’s EOA.
A delegation persists until replaced, and it isn’t rolled back if the transaction fails. An authorization with chain_id 0 is valid on every chain.
WATCH OUT
No setup code runs during delegation, so an observer can send the setup call first (front-run it), unless the setup checks the EOA key’s signature over its own setup data. Storage also survives a switch of delegate, so the spec recommends ERC-7201 namespaces.
If the delegate is also a 4337 account, ERC-4337 adds a MUST: its setup function only accepts calls from entryPoint.senderCreator(). The reason: the EntryPoint can’t tell whether a 7702 account was already set up.
Coming up next: Is anyone exploiting this yet?
What attackers already do with 7702 delegations
IN SHORT The risk is not theory: a USENIX Security ’26 paper associates over 63% of the 7702 authorizations it studied with malicious attacks on EOAs.
The figures come from the USENIX Security ’26 paper. Some attackers re-delegated their own accounts to harmless contracts after an attack, to evade detection. So judging an account takes its full authorization history, not only its current code.
WATCH OUT
Do your contracts use msg.sender == tx.origin to mean “a direct call”? Since 7702, the spec says, that check still identifies an EOA but no longer pins the top-level call. Guards built on it fail, such as those against sandwich trades and reentrancy.
The paper counts 124 malicious contracts in its contract-targeted class. There, an upgraded account keeps its EOA identity to get past checks like this one.
Five checks before the wallet signs
IN SHORT Each check rests on a spec rule, but refusing chain_id 0 and keeping an allowlist are wallet policy, not protocol rules.
Users shouldn’t keep the allowlist themselves. The paper notes that in common wallet UIs, users may only see a summary like “upgrade account”, not the delegate’s address or code.
BEFORE THE WALLET SIGNS
Step 1. Request. A dapp asks the wallet to sign a 7702 authorization.
- Request A dapp asks the wallet to sign a 7702 authorization.
- Chain: refused chain_id 0 is valid on every chain, so the wallet refuses it, and any chain that isn’t this one.
- Nonce If the EOA also sends the transaction, use its nonce plus one: the sender’s nonce goes up first. A zero delegate address is a reset: nothing more to check.
- Allowlist The delegate must be on your list of audited contracts.
- Code, then sign The deployed code must match the audited build. Only then does the wallet sign.
ITEM GET
Check before you sign
FAQ
Sign a new authorization to the zero address, which EIP-7702 treats as a reset: the code goes back to the empty code hash. Storage the old delegate wrote stays. Pick a next delegate whose storage can’t collide, or clear it first with a contract built for that.
Read its code. A delegated EOA holds a marker, 0xef0100 followed by the delegate’s address. Then read its past authorizations too, because current code alone can mislead.
Sources: EIP-7702, ERC-4337, Huang et al., USENIX Security ’26.
STAGE CLEAR
What you now know
- Why a 7702 delegate is a handover of the account, and which spec rules make it risky.
- What the field data shows, and the five checks a wallet should run before it signs, two of them wallet policy.
Check yourself
Tap or click a question to see the answer.
A dapp lets a caller in only if the caller is the account that signed the transaction, to keep programmable accounts out. Does that still work?
No. The check still identifies an EOA, but since 7702 that EOA may run delegate code, so it no longer proves a direct call.
You finished every stage published so far in this series. Back to the series map
Web3 x AI engineer, former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft.
Have a project to ship or a role to fill?
Discuss your project or roleMy work at the web3 x AI intersectionOpen-source tools I build
Follow the engineering notes
Get new articles on production AI and smart contracts by email.