EIP-7702: What It Means When Your Address Has Code

The change is one pointer

Before Pectra, an Ethereum address had code or it did not. A contract account had code; an externally owned account had none, and every transaction from it was a plain transfer or a call out. Wallets built their security model on that split: an EOA cannot be made to run logic without a transaction signed by its key.

EIP-7702 removes the split. It introduces a new transaction type that carries an authorization list, and each authorization is a tuple:

[chain_id, address, nonce, y_parity, r, s]

Applying a valid tuple sets the account’s code to 0xef0100 || address — a fixed prefix followed by the delegate’s address. From that moment the account is still an EOA in every way that matters for signing, but a call to it executes the delegate’s code.

That is the entire mechanism, and it is worth holding onto because the vocabulary around it is misleading. Nothing was migrated, wrapped or custodised. A pointer was written into a code slot, and the account now forwards execution to whatever that pointer names.

What the spec actually requires

The details decide what can go wrong.

The tuple is processed before execution, after the sender’s nonce increments. An authorization is checked and applied at the top of the transaction, not as part of its execution trace.

The nonce must match the authority’s nonce, and applying an authorization increments the authority’s nonce by one. A tuple signed for a stale nonce is invalid; a tuple for the current nonce is a one-shot instrument.

The delegate address may be the zero address, which clears the code. This is the revocation path, and it is the single most important line in the EIP for anyone who has ever delegated. Resetting the code hash to the empty code hash returns the account to a plain EOA.

A chain id of 0 is valid on every chain. The verification step accepts either 0 or the current chain’s id. Multi-chain accounts get one signature for all of them; a signature obtained on a testnet with chain id 0 is also valid on mainnet.

Delegations survive a revert. The EIP is explicit: if transaction execution results in failure, the processed delegation indicators are not rolled back. A transaction that appears to have failed in a block explorer can still have installed a delegate.

Delegation chains are not followed. If the delegate itself points at another delegation, clients retrieve only the first code and stop. There is no cascade to audit, which is one fewer complication than the design could have had.

What the risks actually are

The EIP’s own security section is unusually direct, and it lists the failures in the order a wallet developer would hit them.

Replay protection. A delegate that acts on a signature must include a nonce in what it signs, or a malicious actor can reuse the signature and repeat its effect. This is the failure mode that turns a convenience feature into an unlimited standing instruction.

Signing over the whole call. The notes say the delegate should require a signature over value, gas, target and calldata. Without the target and calldata, a malicious actor may call arbitrary functions in arbitrary contracts; without the gas, a sponsor can grief the signer by making the call run out of gas. The summary sentence is the one to remember: a poorly implemented delegate can allow a malicious actor to take near-complete control over a signer’s account.

Front-running initialisation. Contracts are normally deployed by running initcode, which sets storage at the same moment as code. A delegation writes code without running initcode, so the account’s storage starts empty and the first caller can try to initialise it. The EIP requires wallet developers to verify that the setup calldata is signed by the account’s key via ecrecover, so the account can only be initialised with values its owner approved.

Storage management. Switching from one delegate to another is described as security-critical and not something to do lightly, particularly when the new code was not designed as an upgrade of the old. Delegates are expected to namespace storage so that two implementations cannot silently share slots.

None of these are attacks on the private key. All of them are attacks on the signature — what was signed, for which chain, under which nonce, and what the delegate does with it afterwards.

Reading a 7702 signature request

A user cannot audit Solidity in a popup. What a user can do is recognise the shape of the request and ask three questions.

1. What is the delegate address? It should be a contract with a public audit trail, a published upgrade policy, and — ideally — a documented way to exit. A delegate that cannot be revoked is not a delegation, it is a migration, and the EIP always allows revocation while the key is held.
2. Which chain id is in the tuple? Zero means every chain. If the wallet is being asked to sign for a single network, a zero here is a mismatch worth stopping on.
3. What does the delegate do with signatures it receives? The EIP’s requirements — nonce, value, gas, target, calldata — describe what a correct implementation signs over. A delegate that asks for a bare approval is the exact shape the security notes warn about.

The same discipline that clear signing versus blind signing argues for applies here with a twist. In a blind signature, the risk is that you approved a call you did not read. In a 7702 authorization, the call may be one you never make: the delegate decides later, on your behalf, within whatever bounds the contract enforces.

Where this fits with account abstraction

EIP-7702 is often described as account abstraction arriving at ordinary wallets, and that is roughly right, with one important difference. A smart contract wallet is a new address with code from birth; a 7702 account is an old address that has been given code. The consequences for a user are practical:

• The address does not change, so balances, allowlists and history stay where they are. That is the main reason wallets adopt it.
• Batching becomes possible. Once delegated, an account can invoke multiple calls per transaction, which is what makes approve-and-swap in one signature feasible.
• The key can stay the same. Passkeys and session keys are a separate layer, covered in passkeys and account abstraction, that a delegate contract can implement on top.

The cost is that the account’s behaviour is now a function of code it did not ship with. A wallet that delegates to a contract with an upgrade key has, in practice, an upgrade key on every one of its users’ addresses. That sentence is not in the EIP; it is the consequence of the EIP meeting a proxy pattern.

A short checklist

• If an address shows a 0xef0100 code prefix, it has a delegate. Treat its execution as third-party code.
• To revoke, authorise the zero address. It costs a transaction and restores an empty code hash.
• Do not assume a failed transaction changed nothing; the authorization list is processed first.
• Prefer delegates that sign over the full call and publish how they are upgraded.
• Remember that the address itself no longer tells you what it does. That is the genuine loss in this design, and it is why what an address reveals now has one more exception.

Risk note. The mechanism, revocation rule, nonce handling, revert behaviour and security considerations in this article were read from the EIP-7702 specification on 2026-10-30. Wallet implementations differ in what they expose; the specification is the floor, not the product. Nothing here is investment advice.