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). It went live on Ethereum mainnet with the Pectra upgrade on 7 May 2025 (ethereum.org).
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.
