Skip to main content

EIP-7702: Native Code Delegation for EOAs

Smart-Account Evolution at a Glance​

DateWhat it introducedWhat devs gained
EOA (2015)Single secp256k1 key, nonce, ETH gasSimple, but no batching, no paymasters, no custom logic
EIP-4337 (2021)UserOperation, EntryPoint, bundlers, paymastersBatching, pay for gas in tokens, plug-in validation — but required deploying a new contract
ERC-7579 (2023)Standard module slots (validator, executor, hook…)Drop-in extensions: session keys, spending caps, guardians
EIP-7702 (2024)SetCodeTransaction (type 0x04) — permanent delegate pointerTurn any existing EOA into a 4337 wallet with one tx

Key idea: 7702 is the missing bridge — it lets legacy EOAs join today’s 4337/7579 ecosystem without moving funds or changing address.

Overview​

EIP‑7702 lets a plain Externally Owned Account behave like a programmable wallet—without changing its address or moving funds. A new transaction type, SetCodeTransaction (0x04), writes a delegation indicator (0xef0100 || delegate_address) into the account’s code slot. From that moment, every external or internal call to the account transparently executes the code at delegate_address in the EOA’s own storage and balance context. The owner can later update or remove the delegation with another SetCodeTransaction.

This permanent, opt‑in pointer unlocks powerful patterns:

  • Atomic call batching – one signature can approve, swap, and stake in a single transaction.
  • Gas sponsorship – anyone can call the account and pay the fee; the delegate code verifies the user’s intent.
  • On‑chain policy logic – spending caps, time locks, per‑app sub‑keys, or alternative auth (e.g. WebAuthn) can be enforced inside the delegate contract.

At the same time, 7702 keeps the core EOA model intact. Transactions are still signed with the original secp256k1 key; the global nonce rules and ETH‑denominated gas costs remain unchanged; and the protocol itself knows nothing about sub‑keys, paymasters, or account abstraction. Those features live entirely in the delegate contract, which can be swapped or cleared at any time by the account owner.

Key Concepts​

Native Delegation with SetCodeTransaction​

EIP-7702 defines a new transaction type (0x04) called SetCodeTransaction. This transaction installs a special bytecode in the EOA:

0xef0100 || delegate_address

This instructs the EVM to delegate execution to delegate_address whenever the EOA receives a call. Importantly, the EOA continues to exist as a regular account with its own key, nonce, and ETH balance.

Transaction Format​

SetCodeTransaction (0x04) = rlp([
  chain_id,
  nonce,
  max_priority_fee_per_gas,
  max_fee_per_gas,
  gas_limit,
  destination,
  value,
  data,
  access_list,
  authorization_list, // NEW
  y_parity,
  r,
  s
])

Authorization List​

To prevent unauthorized code delegation, the authorization_list requires off-chain approval from the account’s owner:

authorization_list = [[
  chain_id,
  delegate_address,
  nonce,
  y_parity,
  r,
  s
], ...]

This structure ensures only code explicitly approved by the user (via ECDSA signature) can be delegated to.

---------------------- | ------------------------------------------------------------------------------------ | | Atomic call batching | Approve → swap → stake in one transaction. | | Gas sponsorship | Any relayer can pay the fee; delegate code checks the user’s signed intent. | | On‑chain policy logic | Spending caps, time locks, app‑specific sub‑keys, WebAuthn verification, etc. | | Reversibility | Owner can clear or update the pointer at any time with another SetCodeTransaction. |

⚠️ 7702 itself does not add session keys, passkeys, or token‑gas payments; those live in the delegate contract.

Using EIP-7702 with Smart-Account Workflows​

EIP-7702 is the bridge between a plain EOA and the 4337 smart-account world. One signed message + one transaction turn an address you already own into a fully programmable wallet—while keeping the same key, balance, ENS, and history.

What 7702 adds on top of 4337​

4337 alone4337 + 7702
Requires deploying a contract (factory call, CREATE2 gas, new address)Re-uses the existing EOA address—no factory, no asset moves
Batching, sponsorship, modules only after deploymentAvailable immediately after a single “upgrade” tx
Hard to migrate legacy usersSeamless one-click upgrade for any EOA

Using EIP-7702 with Smart-Account Workflows​

EIP-7702 is the bridge between a plain EOA and the 4337 smart-account world. One signed message + one transaction turn an address you already own into a fully programmable wallet—while keeping the same key, balance, ENS, and history.

What 7702 adds on top of 4337​

4337 alone4337 + 7702
Requires deploying a contract (factory call, CREATE2 gas, new address)Re-uses the existing EOA address—no factory, no asset moves
Batching, sponsorship, modules only after deploymentAvailable immediately after a single “upgrade” tx
Hard to migrate legacy usersSeamless one-click upgrade for any EOA

Conceptual upgrade flow​

  1. Select wallet logic
    Pick any contract that already implements 4337 validation (e.g. Kernel, Simple7702Account, or your own module bundle). Call it delegate.

  2. User signs one authorization hash

    authHash = keccak256(chainId ‖ delegate ‖ nonce)
    signature = sign(authHash, EOA_private_key)

    This proves the EOA owner allows that delegate.

  3. Install the delegate code — choose one of two ways

    PathWhat gets broadcastWho pays L1 gas
    A. Direct / RelayedA single SetCodeTransaction (0x04) that contains authorization_list = [authTuple] and writes 0xef0100‖delegate into the code slot.Sender (self-fund) or any relayer that signs & pays the tx.
    B. Bundled (4337)A UserOperation with extra field eip7702Auth = authTuple. The bundler turns it into SetCodeTransaction + handleOps inside one L1 tx.A paymaster inside the UserOp can cover the fee, giving a true “gasless” upgrade.

  4. Done — the address is now a smart-account
    From the next block every call first executes the delegate in the EOA’s own storage/balance context, so all 4337 features—batched actions, paymasters, session keys, 7579 modules—work exactly as if the wallet had been factory-deployed.

  5. Optional: Clear or swap the delegate

Developer takeaway​

  • No new primitives to learn — keep building with the same 4337 abstractions; 7702 is just a pre-upgrade step.
  • No address migration pain — users keep the identifiers and approvals they already use.
  • Reversible — the owner can clear or swap the delegate with another SetCodeTransaction at any time.

EIP-7702 turns create a smart wallet into upgrade the key you already have — giving every existing account the modern UX of batching, gas sponsorship, and modular extensions without touching their funds.

Demo​

Play Chess with WebAuth session to avoid signing a transaction every move:

https://chess.gblend.xyz

References​

Standards & Specifications​

Official Documentation & Resources​

Development Tools & SDKs​

  • viem - TypeScript library for interacting with Ethereum.
  • permissionless.js - TypeScript utilities built on viem for ERC-4337 account abstraction.
  • Module SDK - SDK for developing modules compatible with ERC-7579.
  • Smart Sessions SDK - Tools for implementing session-based authentication.
  • ModuleKit - Comprehensive toolkit for module developers by Rhinestone.
  • ERC-7579 Compatible SDK - Official tooling for building with the ERC-7579 standard.

Reference Implementations​

Testing & Deployment​

Registries & Metrics​

Educational Content​

Video Resources​

Articles & Guides​