EIP-7702 Account Delegation Explained

EIP-7702 account delegation is a protocol-level change that lets an Ethereum externally owned account (EOA) use smart-contract code without moving to a different address. It is aimed at developers building wallets, dApps, and account-abstraction systems that need batching, sponsored transactions, or more flexible authorization. This guide explains what the EIP changes, how its authorization list works, what security assumptions it introduces, and how it relates to ERC-4337 smart accounts.

What is EIP-7702 Account Delegation?

EIP-7702, titled “Set Code for EOAs,” adds a new transaction type that can attach a delegation to an existing EOA. An EOA normally has a balance, a nonce, and a private key, but no contract bytecode. With EIP-7702, the account can point at an implementation contract. Calls to the EOA then execute the implementation’s code in the EOA’s address, balance, and storage context.

The Ethereum project describes an account as an address with a balance, nonce, code hash, and storage root. Traditionally, an EOA has no executable code while a contract account is controlled by code rather than a private key. The Ethereum accounts documentation provides that baseline distinction. EIP-7702 narrows the practical gap: the EOA keeps its address and key-based identity, but it can opt into programmable execution.

The EIP-7702 specification defines this as a delegation indicator rather than a copy of the implementation code. The account’s code becomes a small marker containing the implementation address, and the EVM follows that marker when it executes calls. The implementation is therefore shared by reference, while each delegated EOA retains its own state.

The Problem EIP-7702 Solves

An ordinary EOA is simple and efficient, but its authorization model is rigid. The private key signs each transaction, and each transaction normally maps to one direct call. That design creates friction in several common situations:

• A swap may require an approval transaction followed by a trade transaction.
• A new user may need ETH before a dApp can perform an initial action.
• A wallet may want to enforce spending limits, session keys, or multiple approval rules.
• An application may need to submit several dependent calls atomically.
• A user may want contract-style controls without migrating funds to a new wallet address.

Smart contract wallets can solve these problems, but deploying a new wallet introduces a new address, migration work, and sometimes fragmented support across dApps. ERC-4337 solves the user-operation flow without changing the protocol transaction format, as described in our ERC-4337 smart accounts explainer. EIP-7702 takes a complementary route: it gives an existing EOA a protocol-supported way to delegate execution.

The result is not “free” account abstraction. The user still authorizes the delegation, while the implementation becomes responsible for the additional rules.

How EIP-7702 Works / Architecture

EIP-7702 introduces type-4 transactions with an authorization list. Each authorization tuple identifies a chain scope, an implementation address, and an authorization nonce. The signer signs the tuple, but the transaction that carries it can be submitted by another account. That separation is what makes sponsored execution possible.

The processing flow is:

1. The transaction sender includes one or more authorization tuples in the authorization list.
2. Ethereum verifies each tuple’s signature and checks its chain ID and nonce.
3. The recovered authority address is added to the transaction’s accessed addresses.
4. The protocol writes a delegation indicator, 0xef0100 || implementation_address, to that authority’s code.
5. Calls to the authority execute the implementation code while using the authority’s storage and balance.
6. The transaction’s normal execution phase can use the delegated account to perform one or more actions.

The authorization signature is domain-separated with the EIP’s magic byte and the RLP-encoded tuple. A chain ID of zero or the current chain ID is accepted by the protocol, so applications must make an intentional choice about whether an authorization should be usable across chains. The authority nonce must match the signed nonce, and the signature uses the low-s form required by Ethereum’s signature rules.

The marker is important. EIP-7702 does not copy bytecode into every EOA, which would be expensive and difficult to update. It tells the EVM where to find the code. Because the implementation executes in the authority’s context, a poorly designed implementation can affect the delegated account’s assets and storage. Delegation is therefore an authorization to run a particular program, not merely a cosmetic wallet setting.

Components and Key Concepts

The authority EOA

The authority is the address recovered from an authorization signature. It is the EOA that receives the delegation. Its nonce and balance are not replaced by the implementation. Existing dApps can continue to recognize the same address, but calls to that address now have code to execute while the delegation is active.

The implementation contract

The implementation contains the logic that the delegated EOA runs. It may expose an execution function that accepts a list of calls, validate a session key, enforce a spending policy, or verify a different signature scheme. Since the code is shared by reference, many EOAs can delegate to one audited implementation while keeping separate storage.

Implementation design must account for the execution context. address(this) resolves to the delegated EOA, and state reads and writes use that account’s storage. A developer cannot safely assume that the implementation is running at its own deployment address. Initialization, access control, reentrancy protection, and upgrade behavior must be designed for this context.

The authorization tuple

The tuple contains chain_id, address, nonce, y_parity, r, and s. The address field is the implementation target, not the authority. The signature recovers the authority from the tuple’s other fields and a domain-separation marker.

Delegation and revocation

The protocol writes 0xef0100 followed by the implementation address as the delegation indicator. To change behavior, the authority signs a new valid authorization for another implementation. To revoke delegation, the implementation address is the zero address; the protocol then clears the delegation indicator instead of writing a new one.

An application should show the implementation address and the requested permissions clearly before a user signs. A signature that looks like an ordinary “continue” action in a wallet UI could authorize code with broad control over the EOA’s assets.

Relationship to account abstraction

EIP-7702 and ERC-4337 address related problems through different paths. EIP-7702 changes how an EOA can execute at the protocol level. ERC-4337 uses UserOperation objects, bundlers, and an EntryPoint contract to create a smart-account flow without requiring a new transaction type. A delegated EOA can participate in account-abstraction flows, but developers still need to implement the expected validation and execution interfaces.

This distinction matters operationally. EIP-7702 can reduce migration friction for an existing wallet, while ERC-4337 can provide a standardized relay and paymaster ecosystem. A product may use one, the other, or both depending on its wallet lifecycle and infrastructure requirements.

Real-World Use Cases

Atomic multi-call wallets

A delegated implementation can validate and execute a sequence such as token approval, swap, and deposit in one transaction. The calls can share outputs and either complete together or revert together. This can make a multi-step application flow easier to present and reduce separate signature prompts.

Sponsored onboarding

Because the account that submits the transaction can differ from the authority that signs the authorization, a relayer can pay the network fee. A wallet or dApp can sponsor a first interaction, provided it has safeguards for rate limits, replay prevention, and abuse. Sponsorship changes who pays for execution; it does not remove gas costs.

Session keys and limited permissions

The delegated code can recognize a session key that is valid only for a time window, contract, function, or spending limit. This is useful for games, trading interfaces, and automated workflows where repeatedly exposing a primary key is undesirable. The implementation must enforce the limits on-chain; a UI promise is not a security boundary.

Recovery and policy controls

An implementation can add guardians, multiple signers, delayed actions, or role-based permissions to an existing address. These controls are valuable for treasuries and embedded wallets, but they also make the implementation more complex. Recovery logic that can seize or permanently lock an account requires especially careful review.

dApp-compatible wallet upgrades

Projects that already have users holding assets in EOAs can add programmable behavior without asking every user to bridge funds to a new smart wallet address. The same address can remain visible to contracts, indexing systems, and counterparties, although each integration must be tested against the new execution behavior.

Getting Started / Practical Guide

Start on a test network or local development chain that supports EIP-7702. Choose a small, audited implementation and define exactly which operations it may perform. The implementation should include nonce handling, signature validation, replay protection, and explicit authorization for every execution path. Do not treat a demo contract as a production wallet.

Client libraries are adding helpers for type-4 transactions. The following viem example shows the shape of the flow; use the library version and network support documented by your provider:

import { createWalletClient, http, parseEther } from 'viem';
import { privateKeyToAccount } from 'viem/accounts';
import { sepolia } from 'viem/chains';

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
const implementationAddress = '0x1111111111111111111111111111111111111111';
const recipient = '0x2222222222222222222222222222222222222222';

const walletClient = createWalletClient({
  account,
  chain: sepolia,
  transport: http(process.env.RPC_URL),
});

const authorization = await walletClient.signAuthorization({
  account,
  contractAddress: implementationAddress,
});

const transactionHash = await walletClient.sendTransaction({
  account,
  to: recipient,
  value: parseEther('0.001'),
  authorizationList: [authorization],
});

console.log(transactionHash);

This example authorizes an implementation and sends a transaction carrying that authorization. A production flow should specify the chain and nonce explicitly when the library supports those fields, display the implementation address to the user, and confirm that the RPC provider accepts type-4 transactions. The recipient call is only an example; real delegated execution usually calls an implementation function that validates and dispatches a batch.

Install the client dependency and run the flow against a funded test account:

npm install viem
RPC_URL=https://your-testnet-rpc.example PRIVATE_KEY=0xyour-test-key node delegated-account.ts

Before using real funds, verify the delegation and implementation behavior with a block explorer or an RPC client. Check the account’s code, confirm that it contains the expected 0xef0100 marker, and test both replacement and revocation. Also test malformed signatures, reused authorization nonces, wrong chain IDs, unauthorized callers, reentrancy, and calls that run out of gas.

Operational monitoring should alert on new delegation targets and unusual changes in delegated account storage. A relayer should simulate the complete transaction, limit sponsorship by account and application, and reject implementations outside an allowlist. These controls are as important as the signing code because the relayer is exposed to replay, spam, and denial-of-service attempts.

Common Misconceptions

“EIP-7702 turns every EOA into a permanent smart contract.”

No. It gives an EOA a delegation indicator that can be replaced or cleared through valid authorization. The EOA remains the same address, and its behavior depends on the implementation it has authorized.

“Delegation makes an account safer automatically.”

Delegation adds capabilities, not a guaranteed security upgrade. A malicious implementation, unclear wallet prompt, or broken access-control check can put the EOA’s funds at risk. Users and applications must review the target code and the permissions it grants.

“A relayer can change what the user signed.”

Not without invalidating the authorization. The signed tuple commits to the implementation and nonce. A relayer can submit the authorization, but it cannot substitute another target while preserving the signature.

“EIP-7702 replaces ERC-4337.”

The two systems solve overlapping wallet problems with different mechanisms. EIP-7702 provides protocol-level delegation for existing EOAs, while ERC-4337 defines a user-operation and bundler model. They can be integrated, but one is not a drop-in replacement for the other.

Related Articles

• Account Abstraction: Smart Accounts, Bundlers, and the Future of Ethereum UX
• ERC-4337: Smart Accounts, Bundlers, and the Future of Ethereum Wallet UX
• Chain Abstraction Protocols: Simplifying the Multi-Chain Ecosystem
• EIP-1559 Fee Market Mechanism
• Ethereum Gas Optimization Systems

EIP-7702 is best understood as an execution bridge: it keeps an EOA’s address and existing state while allowing the account to opt into contract-defined behavior. That can improve batching, sponsorship, and wallet policy, but it also moves more security responsibility into implementation code, signing UX, and operational monitoring.