Understanding EIP-7702: Set-Code Transactions for EOAs

EIP-7702 is one of the most interesting recent changes to Ethereum account behavior.

It does not remove the distinction between EOAs and contract accounts, but it does let an EOA install a delegation indicator in its code slot and execute contract code while still being able to originate transactions.

That makes EIP-7702 an important bridge between traditional EOAs and smart-account-like UX.

Ethereum accounts before EIP-7702

Ethereum has two broad account categories:

  • EOAs (externally owned accounts)
  • contract accounts (smart contracts)

At the state level, every account has four fields:

  • nonce
  • balance
  • storageRoot
  • codeHash

For a normal EOA:

  • codeHash is the hash of empty code
  • storageRoot is the root of an empty storage trie by default

So EOAs did not “gain” these fields with EIP-7702. They already existed in the state model. What changes is that an EOA can now delegate execution to contract code and make meaningful use of its own storage.

What EIP-7702 introduces

EIP-7702 introduces a new EIP-2718 typed transaction: Type 4, also called the set-code transaction.

Its purpose is to let an EOA set a delegation indicator in its code slot.

The transaction contains an authorization_list, and each authorization tuple has this shape:

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

At a high level:

  • address is the contract whose code will be used
  • nonce is part of replay protection for the authorizing account
  • y_parity, r, and s are the signature fields

If a tuple is valid, the protocol writes this value into the authorizing account’s code slot:

0xef0100 || address

This value is not ordinary contract bytecode. It is a special delegation indicator.

How delegated execution works

Once an EOA has a valid delegation indicator, calls to that account execute the delegated code, but in the context of the EOA.

That means:

  • the storage used is the EOA’s storage
  • the balance is the EOA’s balance
  • the address context is still the EOA’s address

Informally, people sometimes call this a “smart EOA”, but it is better to think of it as an EOA with delegated execution rather than a brand new native account type.

A key protocol change here is that Ethereum explicitly allows an account whose code is a valid delegation indicator to still originate transactions.

Why EIP-7702 matters

The motivation for EIP-7702 is not just “EOAs can have code now.” The more important point is what that enables at the wallet and application layer.

The EIP is explicitly designed around three UX improvements:

  • batching — multiple operations can be composed into a single user flow
  • sponsorship — another party can pay for execution on the user’s behalf
  • privilege de-escalation — users can authorize more limited sub-keys or permission models instead of always using full account authority

This is why EIP-7702 matters in practice: it moves standard EOAs closer to smart-account UX without requiring users to migrate to a new address.

EIP-5792 is different

EIP-5792 is not the same thing as EIP-7702.

EIP-5792 is a wallet JSON-RPC standard for methods such as wallet_sendCalls, wallet_getCallsStatus, and wallet_getCapabilities.

EIP-7702 is a protocol-level transaction type. EIP-5792 is a wallet interface that applications can use to access richer wallet behavior.

The two can complement each other, but they solve different problems.

Ethereum transaction types in practice

The transaction types most commonly discussed on Ethereum today are:

  • Type 0 — Legacy transactions
  • Type 1 — Access List transactions (EIP-2930)
  • Type 2 — Dynamic Fee transactions (EIP-1559)
  • Type 3 — Blob transactions (EIP-4844 / proto-danksharding)
  • Type 4 — Set-code transactions (EIP-7702)

A practical way to think about them:

  • Type 0 is the original format
  • Type 1 adds access lists
  • Type 2 is the standard/default modern transaction format
  • Type 3 adds blob-related data for rollup data availability
  • Type 4 adds delegated code for EOAs

Type 0 and Type 1 are still valid, but in day-to-day usage Type 2 is the format most users and wallets encounter.

Subtle but important behaviors

A few details in EIP-7702 are easy to miss, but they matter:

  • Delegation is persistent. It stays in place until it is changed or cleared.
  • Clearing is built in. Setting the delegated address to the zero address clears the code back to the empty-code hash.
  • Authorization processing happens before execution begins.
  • A revert does not undo delegation changes. If transaction execution fails later, successfully processed delegation indicators remain in place.
  • The transaction sender pays for the authorization tuples, even if some are invalid or duplicated.
  • If the same authority appears multiple times, the last valid tuple wins.
  • The account being authorized must have empty code or already be delegated. This mechanism is not a way to overwrite arbitrary existing contract code.
  • Delegation resolution stops after one hop. If delegated code points to another delegation, clients do not keep following the chain.

One subtle EVM detail worth knowing

There is also an important code-introspection nuance.

During delegated execution, CODESIZE and CODECOPY operate on the delegated code being executed. But EXTCODESIZE on the EOA still reflects the delegation indicator stored in the account itself.

That difference is subtle, but it is exactly the kind of thing that matters when reasoning about tooling, security assumptions, and low-level EVM behavior.

Final takeaway

EIP-7702 does not turn EOAs into ordinary smart contracts. It gives EOAs a protocol-native way to delegate execution to contract code while preserving their ability to send transactions.

That makes it a pragmatic step toward better wallet UX: batching, sponsored execution, and finer-grained permission models — without forcing users to abandon their existing addresses.