LibraryData and agents2024Design paperCorpus record
Set Code for EOAs
EIP-7702. Vitalik Buterin, Sam Wilson, Ansgar Dietrichs and Matt Garnett.
A transaction can temporarily, for the transaction's authority, delegate an externally owned account's code to a contract. The key still signs. The code that runs can batch, sponsor, or limit what the key may do.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
A wallet that asks a user to delegate code should show the code's address and how to clear it.
The five-minute read
The defect
Account abstraction that requires a new contract account leaves every existing key behind.
The rule
A transaction can temporarily, for the transaction's authority, delegate an externally owned account's code to a contract. The key still signs. The code that runs can batch, sponsor, or limit what the key may do.
How it is put together
The signer is still the key. The code is delegated, not a new permanent account, in the form the EIP specifies. Revocation is part of the design. A delegation that cannot be removed is a bug.
Where the claim stops
The EIP's security depends on the code being delegated. A malicious delegation empties the account.
One action, walked through
- The key signs an authorisation that names the code.
- The transaction sets that delegation.
- Calls then execute the delegated code under that account.
- What address is the account delegating to?
The argument, unpacked
Why it is still on the desk
A wallet that asks a user to delegate code should show the code's address and how to clear it.
After the text
Ethereum shipped this with the Pectra upgrade. The EIP is the rule. A wallet's user interface is not.
What has to be true
- The EIP's security depends on the code being delegated. A malicious delegation empties the account.
- This is not 4337, though wallets may use both.
- A delegation is a capability. Treat it as one.
What happened after the paper
Ethereum shipped this with the Pectra upgrade. The EIP is the rule. A wallet's user interface is not.
What to check before you use the idea
- What address is the account delegating to?
- How is the delegation cleared?
- Can the delegated code move assets without a further prompt?
Terms
- Delegation
- A pointer from an externally owned account to code it will run.
- Authorisation
- The signature that permits that pointer.
The problem the paper names
Account abstraction that requires a new contract account leaves every existing key behind.
What the design proposes
- The signer is still the key.
- The code is delegated, not a new permanent account, in the form the EIP specifies.
- Revocation is part of the design. A delegation that cannot be removed is a bug.
How the mechanism is specified
- The key signs an authorisation that names the code.
- The transaction sets that delegation.
- Calls then execute the delegated code under that account.
What this page does not treat as proven
- The EIP's security depends on the code being delegated. A malicious delegation empties the account.
- This is not 4337, though wallets may use both.
- A delegation is a capability. Treat it as one.
Why a venture studio still reads it
A wallet that asks a user to delegate code should show the code's address and how to clear it.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.