ERCs, Solved
the standard · since May 2024
// core eip · proposed may 2024 · pectra account primitive · ready

What is EIP-7702?

The protocol patch that lets EOAs borrow smart-account behavior — without removing the EOA root key.

EIP-7702 ·EIP-7702 ·by Vitalik Buterin + Sam Wilson + Ansgar Dietrichs + lightclient

updated · 4 min read · by ercs-solved maintainers

EIP-7702 is the most important account-abstraction patch Ethereum has shipped since ERC-4337 went live. It answers the question ERC-4337 could not answer cleanly: how does an address that already owns assets, approvals, ENS, reputation, and history become programmable without moving everything to a new contract account?

The answer is delegation. The price is that the address still has an EOA root.

[ jump to what's broken → ]
on this page
  1. What is EIP-7702?
  2. At a glance
  3. Origin story
  4. The spec
  5. What's broken
  6. residual ECDSA key remains
  7. Delegated EOAs are hybrid accounts
  8. Initialization and storage are wallet problems
  9. Authorizations are a new phishing surface
  10. It is not a permission vocabulary
  11. LUKSO alternative
  12. EIP-7702 vs LSP0+LSP6+LSP20+LSP25
  13. When to use which
  14. FAQ
  15. Sources
  16. Keep reading
at a glance

The standard, in one card.

Standard
EIP-7702
Track
Core
Created
7 May 2024
Activated
Pectra, May 2025
Transaction type
SET_CODE_TX_TYPE 0x04
Delegation marker
0xef0100 || address
Closest account stack
ERC-4337 EntryPoint v0.8
LUKSO contrast
LSP0 + LSP6 + LSP20 + LSP25
how the standard came to be

The origin story.#

ERC-4337 deliberately avoided protocol changes. That was its strength: it could ship by deploying an EntryPoint contract and an off-chain bundler network. But avoiding protocol changes meant existing EOAs stayed outside the model. A user could deploy a smart account, but their original address, approvals, ENS, assets, and history stayed behind.

EIP-7702 was created in May 2024 to patch that gap at the protocol layer. Its motivation names three UX goals directly: batching, sponsorship, and privilege de-escalation. In practice, that means a normal Ethereum address can temporarily behave like wallet code: one click can approve and swap, a sponsor can pay gas, and a session key can be delegated a smaller set of powers than the main key.

  1. May 2024 Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, and lightclient create EIP-7702. ↗
  2. May 2025 Ethereum's Pectra upgrade activates EIP-7702, and ERC-4337 EntryPoint v0.8 adds native support for delegated EOAs.
  3. 2026 Wallets and account-abstraction stacks continue converging around 7702 + 4337, while residual key revocation remains an active design topic.
the spec, end to end

What EIP-7702 actually is.#

EIP-7702 EIP-7702 interface solidity 
// EIP-7702 is a protocol transaction type, not a contract ABI.
// The set-code transaction payload is RLP-encoded:
//
// rlp([
//   chain_id,
//   nonce,
//   max_priority_fee_per_gas,
//   max_fee_per_gas,
//   gas_limit,
//   destination,
//   value,
//   data,
//   access_list,
//   authorization_list,
//   signature_y_parity,
//   signature_r,
//   signature_s
// ])
//
// Each authorization tuple:
struct Authorization {
  uint256 chainId;
  address delegationTarget;
  uint64 nonce;
  uint8 yParity;
  bytes32 r;
  bytes32 s;
}
//
// Installed account code:
// 0xef0100 || delegationTarget
EIP-7702 interface, grouped
tx: SET_CODE_TX_TYPE · destination · data · authorization_list
auth: chain_id · address · nonce · y_parity · r · s
installed: 0xef0100 · delegation target
wallet layer: batching · sponsorship · session keys · validation logic

EIP-7702 adds a set-code transaction type. The transaction contains one or more authorization tuples. Each tuple is signed by an EOA and names the delegate code address the EOA wants to use. The protocol writes a small delegation indicator into the account's code slot: 0xef0100 || address. When code execution touches the EOA, clients load and execute the target contract code.

That sounds like the EOA has become a contract. It has not, fully. It has delegated behavior. The original signing key remains capable of authorizing a different delegation unless another future mechanism disables that authority.

the integration tax

What's broken about EIP-7702.#

EIP-7702 is a major improvement, not a mistake. The important question is what kind of account it creates. A delegated EOA is powerful because it preserves an existing address. It is risky because it preserves the same root authority that made EOAs hard to recover in the first place.

  1. The residual ECDSA key remains.#

    EIP-7702 gives an EOA code-like behavior, but the original private key is still the account's root authority. If that key is compromised, an attacker can sign a new authorization tuple and point the account at hostile code. Recovery above the delegation is not authoritative unless the residual key can be revoked.

    EIP-7702 EOA key signs another authorization
    residual root override risk recovery not final
    LSP0 + LSP6 contract account + controllers
    no hidden root controller rotation authoritative recovery
    workarounds tried
    • hardware-wallet-rooted EOAs
    • EIP-7851 draft for ECDSA disablement
    • fresh contract account migration
    • strict wallet warnings for authorizations

    read the deep-dive

  2. Delegated EOAs are hybrid accounts.#

    A 7702 account has an address with delegation code, but it is still an EOA-shaped account in important ways. Tools, contracts, and assumptions built around 'EOA has no code' and 'contract has deployed storage and init flow' now meet a third category.

    EIP-7702 EOA address executes delegated code
    hybrid semantics tooling gap invariant breaks
    LSP0 account is always a contract
    predictable ERC-725 storage contract semantics
    workarounds tried
    • wallet-specific detection
    • account abstraction SDK wrappers
    • defensive tx.origin assumptions
    • simulation before signing

  3. Initialization and storage are wallet problems.#

    A 7702 delegation points to code; it does not deploy and initialize a new account contract in the normal sense. Delegate implementations execute against the EOA's account context, so wallet authors must handle initialization ordering, storage layout, and delegate replacement carefully.

    EIP-7702 delegation target executes in EOA context
    init hazards storage collision implementation trust
    LSP17 + ERC-725Y standard extension + account data store
    registered selectors typed keys replaceable modules
    workarounds tried
    • guarded initialization
    • namespaced storage
    • single-vendor delegate discipline
    • formal storage-layout reviews

  4. Authorizations are a new phishing surface.#

    The signature a user is asked for is no longer just a transaction or a permit; it can change what code controls the account. Wallet UI has to explain delegation authority clearly enough that non-technical users do not sign away execution control.

    EIP-7702 sign Authorization(chainId, target, nonce)
    high authority hard to explain phishing target
    LSP6 grant controller permissions
    scoped calls inspectable revocable
    workarounds tried
    • human-readable delegation registries
    • wallet allowlists
    • simulation
    • short-lived delegates where possible

  5. It is not a permission vocabulary.#

    EIP-7702 installs delegation. It does not standardize session keys, spending limits, recovery, app permissions, received assets, profile metadata, or relay policy. Those features live in the delegated wallet implementation and the ERC-4337 stack around it.

    EIP-7702 delegate to wallet code
    mechanism only wallet-specific no shared policy
    LSP6 + LSP25 permissions + relay on the account
    standard policy gasless native tool-readable
    workarounds tried
    • ERC-4337 smart account implementations
    • ERC-7579 modules
    • wallet SDKs
    • vendor-specific permission schemas

    read the deep-dive

the LUKSO alternative

LUKSO designed it differently.#

The LUKSO account stack takes the opposite route. It does not try to retrofit code onto an EOA. A Universal Profile is a contract account from the start. LSP6 defines controllers and permissions. LSP20 verifies calls inline. LSP25 handles relayed execution. LSP3 and ERC-725Y give the account a standard data model.

This does not help an existing Ethereum address keep its history. EIP-7702 wins that use case. The LSP win is cleaner semantics: no hidden EOA root, no hybrid account category, and no wallet-specific permission vocabulary sitting behind a generic delegation pointer.

spec to spec, at a glance

EIP-7702 vs LSP0+LSP6+LSP20+LSP25 in one table.#

row EIP-7702 LSP account stack
account root EOA private key remains contract account controlled by LSP6
upgrade shape delegation target pointer account modules/extensions and Key Manager replacement
permission model wallet implementation decides LSP6 permission bitfield + allowed calls/data keys
gasless flow usually through ERC-4337 bundler/paymaster infrastructure LSP25 executeRelayCall on the account
identity/data not specified ERC-725Y + LSP3 profile data
main advantage upgrades existing Ethereum addresses in place clean account semantics from genesis
be honest about scope

When to use which.#

people also ask

FAQ.#

  • What is EIP-7702? #

    EIP-7702 is an Ethereum protocol change that lets an EOA delegate execution to contract code through a signed authorization. It gives existing addresses smart-account-like behavior without redeploying or moving assets.

  • Is EIP-7702 the same as ERC-4337? #

    No. ERC-4337 is a higher-layer smart account architecture built around UserOperations, EntryPoint, bundlers, and paymasters. EIP-7702 is a protocol transaction type that lets an existing EOA point to contract code. EntryPoint v0.8 can use 7702 accounts, so the two are complementary.

  • Did Pectra activate EIP-7702? #

    Yes. Ethereum's Pectra upgrade in May 2025 activated EIP-7702, making EOA delegation available at the protocol layer.

  • What is the residual-key problem? #

    A delegated EOA still has its original private key. If that key is stolen, the attacker can sign another EIP-7702 authorization and replace the delegate code, bypassing recovery or session limits implemented above the delegation.

  • How does LUKSO differ from EIP-7702? #

    LUKSO Universal Profiles are contract accounts from genesis. Authority lives in controllers managed through LSP6, not in a residual EOA key. Gasless execution is LSP25 on the account, and profile data uses ERC-725Y/LSP3.

glossary 4 terms used on this page
EOA
Externally Owned Account: an Ethereum account controlled by a secp256k1 private key.
authorization tuple
The signed EIP-7702 data structure that names a chain, delegation target, nonce, and signature.
delegation indicator
The account-code marker 0xef0100 followed by the delegation target address.
residual key
The original EOA private key that remains able to sign new authorizations after delegation is installed.
primary sources

Where this page draws from.#

  1. EIP-7702: Set Code for EOAs
  2. ERC-4337: Account Abstraction Using Alt Mempool
  3. LUKSO LSP0 ERC725 Account
where to go next

Keep reading.#