EIP-7702 EOA Code Delegation: Authorizations and Risks

A conventional EOA signs transactions with a private key and has no executable code stored at its own address. EIP-7702 lets that account point to code already deployed elsewhere. When code-executing operations reach the delegated account, the client loads the target’s code and runs it in the account’s context. The code lives at another address, while the delegated account supplies the address, balance, and storage context.

This is not a migration to a new contract address, and it does not replace the private key. The original address and key remain. A valid delegation indicator still allows the EOA to originate ordinary transactions. What changes is that a call can run account logic as though code were attached to the EOA; the standard does not automatically split one key into safer roles.

The EIP-7702 specification defines this through a new type-4 set-code transaction and an authorization list. Ethereum.org’s Pectra EIP-7702 guide likewise describes a pointer to code that is already deployed. A wallet label such as “smart account enabled” does not tell you the account’s actual validation rules, recovery method, or delegated code.

Start by separating who holds the private key from who deployed or controls the delegated code. Check whether the code can be changed, who can upgrade it, and what it can do with the account’s assets and storage. Those are central security questions, not details supplied by the EIP itself.

The set-code transaction is identified by transaction type byte 0x04. It has the ordinary outer transaction fields plus an authorization list. Each tuple contains a chain ID, a code address, the authority account’s nonce, and a signature approving that tuple. The authority signs the authorization; the transaction sender separately signs the outer transaction. One person can fill both roles, or they can be different accounts.

Because a sender can include another person’s valid authorization, inspect what the wallet is asking the authority to approve. A chain ID normally limits an authorization to one chain; chain ID zero allows broader use across chains that support the transaction. That does not mean the same authorization will succeed everywhere: the chain must support EIP-7702 and the account nonce and state must still match. A broad chain scope can, however, expose a signature to use on another supported chain.

An authorization may be skipped if its nonce does not match the authority account or another validation step fails. One wrong character in the target address can point to different code. Compare the network, account, and exact target address in the signing preview and a trusted block explorer; a vague prompt about “upgrading” or “saving gas” is not enough to identify the permission.

Ethereum.org’s transaction documentation describes type-4 transactions as including an authorization list. The outer transaction still has gas conditions and a fee payer; submitting through another address does not by itself make execution free. EIP-7702 type-4 transactions are also distinct from ERC-4337 UserOperations and paymasters, covered separately in the smart-account guide.

After a valid authorization, the EOA’s code is set to a marker made from the 0xef0100 prefix and the target address. The client recognizes this marker and loads code from that target when executing a call. The account address shown in a wallet can therefore differ from the address whose code is running. Verify both addresses.

Code comes from the current chain where the delegation is used. A target address on another network does not cause that network’s code to run here. The same 20-byte address can have different code—or no code—on different chains. Check the deployment and verified source on each chain instead of relying on a name, icon, or matching address alone.

Delegated code runs with the authority account’s execution context and can use its storage. Depending on its logic, it may send the account’s ETH or tokens, call external contracts, and change stored values. EIP-7702 itself does not add automatic rules such as “only this token” or “one call per day.” Any restriction must be implemented and correctly enforced by the delegated system.

If the target is a proxy or otherwise upgradeable, the code you inspect today may not be the code used later. Check the administrator, implementation-change powers, delays, and public upgrade process. An unknown upgrade authority is an ongoing trust risk for as long as the delegation remains.

Delegated code is not a plug-in that the protocol confines to a narrow permission set. A faulty authorization check can permit asset transfers, token approvals, arbitrary external calls, or changes to account storage. An audit badge does not prove that the exact address and version in your signing request match the audited code or scope.

The EIP’s security considerations warn that delegate logic may need to bind replay protection, target and calldata, ETH value, and gas conditions to an authority’s signature. If important fields are omitted, a sponsor or another party may be able to submit a request different from the signer’s intent, or cause a transaction to fail. Inspect which calls the code validates and whether an outside caller can bypass those checks.

For example, a wallet may bundle a token approval and a swap into one confirmation. Check whether both operations succeed or revert together, whether the approval is limited to the amount needed, and whether it can later be reduced. If a paymaster or service covers fees, check who pays and under what conditions. Read the full preview so a friendly “free” label does not hide the calls or permissions being authorized.

Security depends on the actual permissions and upgrade controls, not just the target’s reputation. Check which contracts the account can call, how signatures are validated, who holds emergency or upgrade powers, and whether deployed code matches verified source. If a request comes from an unfamiliar address or an unsolicited message, pause and compare it with the wallet’s official documentation.

EIP-7702 processes the authorization list before the outer transaction’s execution. The specification says that if execution later fails or reverts, delegation indicators already processed are not rolled back. Do not assume that the entire account state returned to its starting point just because the transaction receipt reports failure. Check the receipt and the account’s current code separately.

This matters with batched calls, initialization, and transactions submitted by a sponsor. The authorization may be valid while a later call fails, leaving the delegation active even though the intended setup or app action did not complete. If the authorization tuple itself was not valid, it may not have been applied. Inspect the type-4 transaction, authority account, nonce, and current code pointer rather than relying on a single success/failure label.

A wallet’s “failed” status may summarize failure during authorization processing, an external call, or another execution step. If the result is unclear, compare the transaction hash, signed authority and nonce, and account code using a trusted chain tool. A retry may encounter a changed nonce and make the previous authorization unusable; check for duplicate or already processed submissions first.

The distinction is important whenever a user expects every part of one confirmation to be atomic. Trying a feature on a test or low-value account can help reveal its behavior, but it does not prove that the code is safe. Before using a funded account, know how to check the signed chain scope, target, calldata, and state that could remain after a failed call.

A new authorization can point the account to different code. The EIP also defines clearing the marker by authorizing the null address, returning the account’s code to the empty-code state. That operation removes the delegation indicator; it is not a universal cleanup or recovery command.

If delegated code wrote values into account storage, clearing the marker does not automatically erase them. A token allowance recorded by an ERC-20 contract is also separate from the account’s code. A previous unlimited allowance may need to be revoked at the token contract. Clearing delegation does not reverse tokens already sent, external contract changes, or completed transactions.

New code may reuse the same account storage, so two versions that interpret the same storage slots differently can conflict. Check the storage layout and migration plan before switching code. If compatibility is uncertain, a new delegation may lock the account or make old state behave unexpectedly; the protocol does not offer a general storage wipe as part of changing the pointer.

Choose the response based on the problem. If the code may be malicious, promptly review a wallet-supported clearing or trusted replacement flow. If token allowances were granted, use the separate token approvals and allowances guide. If the private key or seed is exposed, clearing code does not recover control of that key; follow the wallet recovery guide and assess moving assets to a safe new account.

First confirm in the wallet’s official documentation that the wallet supports EIP-7702 on the selected network. Compare the network and chain ID, account, exact delegation target, code verification status, and any proxy or upgrade administrator. Make sure you understand whether chain ID zero gives the authorization broader scope or whether it is limited to one chain. If the signing screen is unclear, look for wallet documentation that explains the authorization data before approving it.

Next, distinguish the authorization signature from the outer transaction sender and fee payer. A different sender may submit the transaction, but that does not change what the authority signed. Sponsorship also does not make delegated code safe or limit it to expected calls. Compare the type, authorization list, call targets and calldata, and any token allowance change with the preview.

If delegation is already active, do not stop at whether the transaction succeeded. Inspect the account’s current delegation marker and the code address it points to. If it differs from what you expected, pause further calls and approvals; avoid sending repeated or random replacement authorizations. For outer transaction fees, see the Ethereum gas-fee guide; for an EOA nonce or pending transaction, see the pending transaction guide.

EIP-7702 standardizes a transaction format that connects an EOA to deployed code. Batching, sponsored fees, session permissions, and recovery can be built on top of that mechanism, but they are features of particular code and services. Not every wallet or delegate uses the same rules or supports every feature.

Seeing “smart account” in an interface does not tell you who holds the signing key, who can upgrade code, or who can change recovery. Check the actual implementation and settings. If a wallet does not support the selected chain or feature, it may display the delegation state differently than expected. Verify support before changing a funded account.

The Ethereum Foundation’s Pectra mainnet announcement describes EOAs pointing to delegated code and later replacing or revoking that authorization. The standard’s capabilities and how a specific wallet presents them to users are separate questions. ERC-4337 UserOperations and paymasters are another account-abstraction path, not the type-4 authorization itself.

This guide explains account mechanics and does not recommend a particular wallet or delegate. Start with the goal—batching, fee sponsorship, session permissions, or recovery—then identify which code and service implement it and what trust they require. Compare the smart-account and ERC-4337 guide and pending transaction guide for adjacent mechanics.