What Is EIP-7702 Delegation? EOA Smart Accounts Explained

EIP-7702 delegation lets an externally owned account (EOA) hand its execution logic to another contract without changing address or surrendering its private key. The code field is set to 0xef0100 plus the delegate address, and later calls run that code inside the EOA's own context, with balance, nonce, and storage still belonging to the account.

It suits readers who already know self-custody wallets and the EVM account model. Ethereum has long had two account types: key-controlled EOAs and contract accounts with code, and only the second could carry custom validation logic, at the cost of a new address. It shipped with the Pectra upgrade and moved custom validation from opening a new account to writing code onto an address already in use.

An authorization tuple holds six fields, and the delegation designator takes 23 bytes: a three-byte prefix plus a 20-byte address. The write path, the limits of the new capabilities, the split with ERC-4337, and whether the delegate can be trusted decide how much control the account keeps after that signature.

Key Takeaways

• EIP-7702 delegation keeps the address, private key, balance, and nonce in place and points only the code field at a delegate contract.

• A type 0x04 transaction writes the delegation through an authorization tuple; the signed message carries no fee fields, and the sender need not be the owner.

• A delegation has no expiry; revoking clears code but not storage, token approvals, or Permit signatures.

• A delegate without receive() or fallback() makes plain ETH transfers revert, and tx.origin no longer implies an account has no code.

• ERC-4337 builds a separate account system while EIP-7702 adds code to existing EOAs, so the two stack.

What Does EIP-7702 Delegation Change About an Externally Owned Account?

Ethereum has two types of accounts: an externally owned account, controlled by a private key, and a contract account, which contains code.

With EIP-7702, what changes is the code field, not the account's identity, because an EOA can temporarily point to contract code without changing its address. Address, private key, balance, and nonce stay where they were; the difference is that the address now carries executable code drawn from another deployed contract.

The field holds a 23-byte delegation designator: the 0xef0100 prefix plus a 20-byte address. When a call targets that EOA, the EVM reads the designator and loads the delegate's code, so the account can behave like smart accounts while the private key remains in control and sender, balance, and storage are all read as the EOA's.

The delegate cannot see state of its own; its execution logic is loaded from the target contract, while storage and sender context remain the EOA's, and writes follow the same logic into storage the EOA never used.

Signatures still come from the original private key, so the account does not become a multisig, and the design is a step toward account abstraction, including the native variant, rather than a change of account type.

Type 0x04 and Authorization Tuples: How Delegation Reaches Contract Code

The write needs a new transaction type, 0x04, whose body carries an authorization list; each tuple is signed by the account holder, while the transaction itself can be sent and paid for by any address, and the authorization specifies which code the account permits to run.

The tuple is [chain_id, address, nonce, y_parity, r, s], and the signed message is keccak(0x05 || rlp([chain_id, address, nonce])); the EIP-7702 specification uses the 0x05 prefix to separate authorization signatures from ordinary transaction signatures, and the message carries no gas or fee fields.

What gets signed is which address the code should point at, not a specific transaction, so some systems pair the authorization with an intent instead. The account can also sign once offline while a sponsor fronts the gas.

Node validation runs in six steps, with the nonce tie making an authorization usable once, at the matching nonce.

The authorization list rides in the transaction body the way an access list extends the transaction format: the chain ID is 0 or matches the local chain (0 means valid on any chain); the nonce is below 2^64-1; ecrecover verifies the signature; the account code is empty or already delegated; the nonce matches the current value; and the code is written as 0xef0100 || address with the nonce incremented.

Revocation follows the same path with the address set to zero, which clears the code hash without a permanent state change to the underlying EOA.

Which Account Properties Stay Unchanged?

Four properties stay as they were, and only code and storage move: the code goes from 0x to the designator, unused storage slots start taking writes, and those values survive revocation. The specification separately lists three onchain invariants that stop holding, covering balance, nonce, and caller identity; the risk section covers them.

1. Address: unchanged, so history, token approvals, and name records keep pointing at one address.

2. Private key: unchanged, and it signs ordinary transactions as well as a new authorization that overwrites or revokes the delegation.

3. Balance: unchanged, because delegation moves no assets and the account still holds them directly.

4. Nonce: keeps counting up, since the authorization consumes one, which blocks replay of the same signature.

Can a Delegated Account Still Receive ETH Normally?

Not by default. Once the account carries code, a plain ETH transfer enters the code execution path; if the delegate implements neither receive() nor fallback(), the transfer reverts and the funds return to the sender.

This issue can occur in common payment flows such as exchange withdrawals, payroll, and airdrops. Wallet software usually reports only a failure, not that the delegate is the cause. Before signing, confirm the target implements a receive function, or route incoming payments through a call that carries calldata, and wallet software should surface that cause more clearly for users.

Figure 1. The EIP-7702 write path: the EOA signs the authorization tuple, a type 0x04 transaction sets the code to 0xef0100 plus the delegate address, and later calls execute that code in the EOA's context.

What Can a Delegated Account Do? Batching, Gas Sponsorship, and Recovery

Delegation turns an EOA from an account that can only sign transactions into an account that behaves like a smart account for everyday users, with the clearest gains in batching, gas sponsorship, and rule-based recovery.

Batching is the most concrete gain: approve and swap can happen in a single transaction, a sponsor can also smooth onboarding or batching by helping complete multiple steps behind the scenes at the right moment, so a single signature settles once and no approval sits unused in between.

Gas sponsorship comes from splitting the signature from the sender: a third party pays, the account needs no ETH up front, and with an ERC-4337 paymaster the cost can rest with the application. That also means some apps can cover gas or smooth onboarding by handling it in the background, but developers should avoid prompting for delegation at the moment a user is simply requesting another feature.

Recovery and session keys lean on the delegate verifying signatures itself, for example with a passkey, a guardian set, or spending limits in place of one key. The delegate can also enforce policy-like functions around transfers or signer use.

The boundary is blunt: whoever holds the private key can always sign a fresh authorization that overwrites the delegation, so recovery here is weaker than in a native smart account and only lowers the cost of a lost key.

A delegation has no expiry. It stays live until a new authorization overwrites it or a zero address revokes it, so the permission is long-lived and needs active management; from a security standpoint, review the scope of what the delegated code can access and control.

How Does EIP-7702 Delegation Differ From ERC-4337 and Account Abstraction?

EIP-7702 adds code to an existing EOA, while ERC-4337 builds a separate account system; as complementary approaches to account abstraction, the two stack rather than replace each other.

ERC-4337 starts from a newly deployed contract, so assets and approvals move across; 7702 starts from the original address and adds code, avoiding migration by letting existing accounts use smart contract behavior without deploying a separate wallet first.

Together they let a 7702 account serve as an account implementation for ERC-4337, and developers can build 4337-compatible flows on top of a 7702-delegated account. That reintroduces an initialization race: between the delegation landing and initialization finishing, anyone can call the initializer and set themselves as owner.

Two fixes exist — initWithSig, which binds the signature to the initialization arguments, or restricting initialization to the EntryPoint.

Is the Delegate Trustworthy? How to Verify It Is Immutable

Delegate only to immutable contracts deployed from standard CREATE2 initcode; the verification mechanism should favor targets with no upgrade path, since proxy contracts, upgradeable contracts, and contracts with a self-destruct path are all poor targets.

Delegation hands execution rights to that code, and the holder receives no change notification. An upgradeable target means the upgrader holds execution power over every account that delegates to it; an immutable one at least fixes the attack surface in advance, where it can be audited. Security exposure rises if delegated code can change after authorization.

Three criteria — immutable code, no proxy, reproducible deployment — become four checks in a block explorer that wallets and developers should verify before granting delegation:

1. Read the implementation and admin slots: a non-zero EIP-1967 slot beginning 0x360894 signals a proxy or upgrade path.

2. Compare onchain bytecode with verified source, confirming constructor arguments and deployed bytecode match.

3. Search for selfdestruct and delegatecall, confirming no branch can erase the code or forward execution elsewhere.

4. Recompute the CREATE2 address from initcode and salt, confirming the deployer cannot substitute another contract at a different address.

What Are the Risks of EIP-7702 Delegation?

Risk sits in three places: bugs in the delegate, account semantics that delegation changes, and the irreversibility of a one-time signature—a security trade-off as much as a functionality upgrade, with the main concern being the broad scope of code that can control the account once authorization is granted.

The tx.origin row has the widest blast radius. A delegated account can execute code inside the call stack, so msg.sender == tx.origin no longer means the caller has no code, and guards built on that comparison stop protecting; nonReentrant or transient-storage locks do not depend on caller identity.

In practice, if wallets do not show the authorization details clearly, users can approve access they did not mean to review. The EIP-7702 guidance in the Pectra docs lists this separately.

A chain_id of 0 widens the third category: the same signature is valid on other EVM chains, so an account can be given code on a chain its holder never considered. Signing devices often omit the chain ID, which is where the trade-off behind enabling delegation on a cold wallet sits.

How Do You Check and Revoke a Delegation?

Checking takes one code read: eth_getCode returning 0x means no delegation, 23 bytes starting with 0xef0100 means the account is a delegated externally owned account, and any other bytecode means it is a contract account.

Delegation is chain-level state, so one address can be delegated on one chain and untouched on another, and every chain needs its own check; the last 20 bytes are the delegate, and a wallet or platform can automate these checks across chains while keeping logs of status checks or changes for auditing and monitoring.

For a quick manual review, checking and revoking a delegation walks through the routine.

Revocation happens inside the wallet: sign a new authorization with the address field set to zero and the node clears the code hash, returning the account to a plain EOA, while external dApps generally cannot do it for the holder, and if wallet teams support revocation workflows, any requests to act on a holder’s behalf should still require the holder’s own approval.

Revocation removes delegated code but does not remove prior smart contract approvals or other access already granted to apps, and OpenZeppelin's EOA delegation notes draw that boundary.

Summary

EIP-7702 buys an EOA programmability with one signature: address and key stay put, the code field points at a delegate, and execution runs in the account's own context.

The price is changed semantics and long-lived permission: plain incoming payments can fail, tx.origin is no longer an EOA, a chain_id of 0 signature travels across chains, and revocation clears only code.

FAQ

Does EIP-7702 turn my wallet into a multisig?

No. Delegation changes only the code field, and signatures still come from the original private key, so a single key holder can transact independently and can overwrite the delegation with a new authorization. A delegate that demands multiple signatures can be bypassed by that key as well.

How can I check whether my wallet is delegated under EIP-7702?

Call eth_getCode on the address. A return of 0x means no delegation; 23 bytes starting with 0xef0100 means it is delegated, with the last 20 bytes naming the delegate; other bytecode means a contract account.

Delegation is recorded per chain, so check each one, and wallets or admin systems may keep logs of those checks for review. In short, the answer may vary only in interface details between wallets, but the underlying code check is the same.

How do I revoke an EIP-7702 delegation?

Sign a new authorization with the address field set to zero from inside the wallet, and the node clears the code hash once validation passes. Only the account holder can sign it, and external dApps usually cannot act on their behalf.

Does a delegation expire, and do earlier token approvals survive revocation?

A delegation has no expiry and stays live until overwritten or revoked. Revocation clears only code, leaving storage, ERC-20 approvals, and Permit signatures untouched.

My key never leaked — can a malicious EIP-7702 authorization still drain the account?

Yes. The signature is a transfer of authority: with it, an attacker can write a delegation pointing at a malicious contract and gain broad access to the account, moving assets without ever touching the private key.

Check the chain ID and target address in the tuple, and sign only for immutable contracts; wallet teams should also verify the signer’s job before granting internal delegation-related approvals on behalf of an organization.