EIP-7702 Wallet Delegation: What You Authorize and What Persists

A wallet can keep the same Ethereum address while gaining programmable behavior. EIP-7702 makes that possible, but the decision to enable it deserves the same attention as a security-sensitive account change.

Status checked November 6, 2026: Ethereum's Pectra overview confirms that the upgrade, including EIP-7702, activated on mainnet on May 7, 2025. Support on another network, in a particular wallet, or through a specific service still needs its own verification.

The authorization changes account behavior

Under EIP-7702, a type-4 transaction carries signed authorizations. An authorization includes a chain ID, a delegate address, and an account nonce. A nonzero chain ID binds it to that chain; a chain ID of zero permits use across chains, subject to each chain's nonce and other validation rules. Valid processing writes a delegation indicator, 0xef0100 followed by the delegate address, into the authorizing account's code. Calls to that account then execute the delegate's code in the account's context.

The delegation persists beyond the transaction. A later valid authorization can change it, and authorizing the zero address can clear it. If the transaction's execution fails, already processed delegation changes remain. A failed application action therefore does not establish that the account's delegation stayed unchanged.

The authorization signs the delegation choice; it does not, by itself, express a complete policy for every later action. Application permissions belong in the chosen account implementation and its authorization scheme.

Programmability still needs a security design

Ethereum's 7702 implementation guidelines emphasize that the original private key retains account control. Delegating to code with multiple-signature checks does not remove that key's ability to bypass those checks. Treat any promised recovery or spending policy as a property to examine in the full wallet design.

The same guide highlights initialization and storage migration hazards. Initial setup needs authentication of its parameters; changing the delegate does not wipe the account's existing storage. An implementation that interprets old slots differently can behave unexpectedly after migration.

For an application team, a useful review question is: which component authorizes which action? Write the answer for the wallet, the delegate implementation, the sponsor, and the user interface separately. A label such as “smart account enabled” leaves too many decisions hidden.

Separate the account change from a user's task

Consider a hypothetical application that asks a user to approve a contract interaction and then perform an action. Its product goal is clear: fewer separate confirmations. That goal does not tell the user whether their account is changing permanently, which code will control future calls, or how they can reverse the change.

Our engineering recommendation is to review those as distinct decisions, even when a wallet presents them in one flow:

• Explain the intended task in ordinary language before showing technical details.
• Identify the account and network involved in the delegation decision.
• Make the selected implementation recognizable and provide a review route for it.
• Describe the wallet's supported way to inspect, replace, or clear a delegation.
• Test the failure screen so it does not claim that every account change was undone.

This is a review framework, not a suggestion that an application should collect raw authorization signatures itself. A clear interface should help the user understand the authority they are granting without requiring them to decode transaction bytes.

Discover wallet capabilities explicitly

The Wallet Call API separates an application's desired calls from a wallet's implementation. It defines capability discovery through wallet_getCapabilities and submission through wallet_sendCalls. Whether a batch must be atomic is an explicit requirement, with support exposed through the wallet's atomic capability.

These are wallet-facing interfaces. Adding a normal Ethereum RPC endpoint to an application does not establish that the connected wallet supports them.

For integration testing, we recommend keeping a small capability matrix: wallet version, chain ID, requested feature, returned capability, and observed outcome. Include unsupported capabilities, a rejected request, and an interrupted session. When an action requires all calls to succeed together, test that requirement explicitly rather than inferring it from the presence of a batch button.

Sponsorship needs its own operating plan

A smoother payment experience still has an operator behind it. If your design includes sponsored transactions, document who supplies the gas, when they may refuse, and how the user proceeds if sponsorship is unavailable. Avoid turning a successful demo into an unconditional promise that users will never need native currency.

Before rollout, our suggested acceptance test is a complete user journey: review the account change, perform the intended action, inspect the resulting account state, encounter a deliberate failure, and use the wallet's recovery or delegation-management path. Record exactly which wallet and network you exercised. That evidence makes a useful integration claim; a feature name alone cannot supply it.