EIP-7702: How can an existing EOA execute code?

You want to send 6 tokens to B and 4 to C from one wallet. If you submit the requests separately, the first may succeed while the second fails. You want to combine both transfers into one execution while keeping the tokens at the address you already use.

Moving the assets to a new smart account is one option. But could the existing address run a program itself?

EIP-7702 lets an externally owned account, or EOA—an account controlled by a private key—designate code to execute. Gas sponsorship is one service this change can enable. First, let us look at what changes in the account and which signature authorizes that change.

Two transfers without moving to a new address

Suppose address A holds 100 tokens of T on a network that supports EIP-7702. B and C both start at zero. The target balances are A90/B6/C4, with the total across the three addresses staying at 100. Assume zero decimal places, no minting or burning, no token transfer fees, and no concurrent transactions.

A in this article is an existing EOA. A controls the private key and keeps the same address. We are exploring the same requirement with a different account structure, rather than migrating the separate smart account used in part 1 to this address.

An ordinary EOA can make two direct calls to token contract T's transfer function in separate transactions. If the first sends 6 tokens to B and processing stops before the second transaction, the balances become A94/B6/C0. That is a valid outcome, but it does not meet the intent of treating both transfers as one batch.

Another possibility is to call a contract that contains batch execution code. If that separate contract simply calls T's transfer, however, T sees the contract as the caller. Using A's balance would require moving the assets or adding a spending approval and a mechanism such as transferFrom.

EIP-7702 allows code deployed elsewhere to execute with A's address as the account performing the calls.

A stores an indicator pointing to the code

Suppose code that executes two calls in sequence is already deployed at address D. A designates D as its code target by signing an EIP-7702 authorization.

When the network processes a valid authorization, it writes a delegation indicator pointing to D into A's code field. The byte format is short:

0xef0100 || D's 20-byte address

Here, || means concatenating two byte sequences. When A has this indicator and receives a call, the EVM loads D's code and executes it in A's context. The executing account's address is A, and the storage it uses belongs to A. The specification's delegation indicator rules define this behavior.

When that code calls token contract T, T therefore sees A as the caller. It can use the token balance that T already records for A. There is no transfer of tokens to D or copying of D's storage into A.

Address	Role in this example
A	Holds the tokens and executes the delegated code
D	Holds the deployed code that A will use
Token contract T	Records A's, B's, and C's balances and processes transfers

Reusing D's code does not merge the state of multiple accounts. Each account executes with its own address and storage.

What does the authorization signature approve?

The delegation authorization approves which code to use in my account. EIP-7702 signs over the chain ID, the address of the code to delegate to, and an account nonce. That nonce is checked against the account nonce at authorization processing time to prevent reuse of the same authorization.

Signed value	Meaning in this example
Chain ID	The network where delegation is permitted
D's address	The code designated to execute at A
A's account nonce	The account's sequence value when the authorization is applied

This does not include the instructions to send 6 tokens to B and 4 to C. D's code must separately check who may execute which calls. Approving the code choice and approving a particular action through that code serve different purposes.

For this example, assume D is designed to execute only batch requests sent by A itself. A signs a transaction to its own account containing the two transfer instructions. That transaction signature approves the specific execution, and D checks that the caller is A. Allowing a third party to submit requests would require a separate execution signature or permission policy for D to verify.

Delegation authorizations go into the authorization_list of the new 0x04 transaction type. The outer transaction has its own sender signature, and its sender can differ from the account authorizing delegation. Delegation and execution can also be included in a single transaction. Separating their roles here does not mean two on-chain transactions are required.

The chain ID also has a special value, 0, that does not restrict authorization to one chain. This example specifies the intended network's ID. The signature format and validation order follow the set-code transaction rules.

Both calls execute from A's address

Once delegation is set, A sends a batch execution request to its own address. Assume D treats a failed subcall as a failure of the entire execution.

A signs the transaction
  ↓
Transaction sent to A
  ↓
D's code runs in A's context
  ↓
A → T: send 6 to B
  ↓
A → T: send 4 to C
  ↓
Tokens: A 90 / B 6 / C 4

The intermediate balances after the first call are A94/B6/C0. After both calls succeed, they are A90/B6/C4. If T rejects the second transfer to C and D reverts the whole execution, the first transfer is also reverted. The balances remain A100/B0/C0.

This atomicity comes from the batch execution code chosen for the example. Code could instead ignore a failure and continue to the next call. EIP-7702 alone does not make every batch automatically succeed or revert as a whole.

An ERC-20 transfer can also return false, depending on the contract. D in this example must treat that result as a failure too. Checking only whether the low-level call reverted is not enough.

For this article, assume A pays its own gas. If A starts with 0.01 ETH and the fee charged for the transaction is an illustrative 0.001 ETH, it has 0.009 ETH left. The total of 100 tokens is accounted for separately from the gas expense. A failed transaction can also consume gas. These figures are neither measurements nor fixed fees.

Delegation remains after the transaction

EIP-7702 delegation is not a temporary setting that disappears after one execution. Once A points to D, later calls to A use that code too. There is no need to register the same delegation authorization for every subsequent batch.

To use different code, A changes the delegation target with a new authorization. To clear delegation, a valid authorization specifying the zero address as the target must be processed. This removes A's delegation indicator. It does not also reset the account's storage or spending approvals recorded in token contracts.

There is another distinction to make about failure. Even when one 0x04 transaction both sets delegation and executes the batch, failure of the later batch execution does not undo the delegation already processed. Token balances can return to A100/B0/C0 while A still has its delegation to D. The authorization processing rules explicitly distinguish these two stages.

A failed transaction therefore does not mean every setting has returned to its previous state. The execution result and the account's delegation state need to be checked separately.

Added capabilities need execution permissions

Designating code does not, by itself, complete a wallet's functionality. Batch execution, multiple signatures, permissions restricted to particular apps, and spending limits are features the delegated code can implement. EIP-7702 does not supply those policies as a package.

D's code can affect A's assets and storage. Choosing trusted code and checking who can submit execution requests are part of designing the account's permissions. The existing EOA's private key remains important. Delegation does not remove every aspect of control through that key.

Initialization needs separate consideration too. The constructor that ran when D was deployed does not run again at A. If ownership or permission settings must be written into A, the code must verify who authorizes that initialization. When changing the delegation target, the new code must also interpret the storage left at A appropriately. The specification discusses these issues under initialization and storage management.

This mechanism can also work with ERC-4337. If the delegated code provides the interfaces and validation an ERC-4337 smart account needs, an account using an existing EOA address can participate in that execution flow. Setting delegation alone does not create a Bundler or Paymaster. EIP-7702's design for compatibility with account abstraction describes this connection between account capabilities and execution infrastructure.

This example extended A to execute both transfers at the same address. The next question is who submits the execution request and pays for it. The next article examines how BXB connects a customer account's transaction authority with a sponsor's responsibility for gas costs.