# EIP-7702: when a plain account runs contract code

> EIP-7702 lets a regular account delegate to contract code with a signed authorization. What a type 4 transaction carries, and what to record about it.

Source: https://hashspan.dev/learn/eip-7702-delegation

## Short answer

EIP-7702 adds a transaction type, 0x04, that carries signed authorizations. Each one lets a regular account (an EOA) point its code at a contract, so calls to the account run that contract's code. An authorization names the chain, the contract address and the account's nonce; chain id 0 makes it valid on every chain, and the zero address clears the delegation.

Figure: EIP-7702: the agent's account signs an authorization with chain_id, address and nonce, anyone sends it in a type 4 transaction, and the account then runs the delegated contract's code; hashspan records the authorization count, addresses and chain ids on the send span.

## What changed in Pectra?

Until EIP-7702, an account was either a key (an EOA) or a contract. EIP-7702 adds a transaction type that lets an EOA set code on itself ([EIP-7702](https://eips.ethereum.org/EIPS/eip-7702)). It went live on Ethereum mainnet with the Pectra upgrade on 7 May 2025 ([ethereum.org](https://ethereum.org/roadmap/pectra/)).

The account doesn't copy code. It stores a pointer, a delegation, to a contract. Calls to the account then run that contract's code, with the account's own storage and balance.

## What is in an authorization?

A type 4 transaction carries a list of authorizations. Each is signed by the account that delegates:

| Field | Meaning |
|---|---|
| `chain_id` | The chain it's valid on, or `0` for every chain |
| `address` | The contract to delegate to; the zero address clears the delegation |
| `nonce` | The account's nonce, so the authorization can be used once |
| `y_parity`, `r`, `s` | The signature |

The transaction itself can be sent by anyone. So the account that delegates and the account that pays don't have to be the same.

## Why should an agent care?

An agent's wallet that delegates hands its behaviour to someone else's code. After that, every call to the account runs that code. Three questions matter later:

- **Which contract?** The delegated address decides what the account can do.
- **On which chains?** A chain id of 0 sets the same delegation on any chain where the nonce matches.
- **When?** The transaction that set the delegation is where to look when the account starts acting differently.

**In a hashspan trace:**
Since 0.9, `@hashspan/viem` records the authorization list on the send span of a type 4 transaction, from `sendTransaction` and `writeContract`. On a local chain, one authorization signed for a freshly deployed contract gave:

  - `blockchain.tx.authorization.count`: `1`
  - `blockchain.tx.authorization.addresses`: `["0x5fbdb2315678afecb367f032d93f642f64180aa3"]`
  - `blockchain.tx.authorization.chain_ids`: `[31337]`

Signatures and nonces are never recorded. The addresses follow the address mode, so they can be hashed or left out; at most 64 authorizations are listed, all are counted. The [transaction attributes](https://hashspan.dev/docs/reference/attributes/transactions#blockchaintxauthorizationcount) describe each field.

## FAQ

### Does the account become a smart contract?

Its code becomes a delegation indicator pointing at a contract, and calls to it run that contract's code. It keeps its address and its key, and can still sign transactions.

### What does chain id 0 in an authorization mean?

The authorization is valid on any chain. That's convenient, and riskier: the same signature can set the delegation wherever the nonce matches.

### How do I remove a delegation?

Sign an authorization for the zero address. The account's code is reset to empty.