AGENTWALLETS · INDEPENDENT PERSPECTIVES
EIP-7702: Adding Smart-Account Logic Without Changing the Wallet Address
Understand persistent EOA code delegation, the authority retained by the original key, and the migration checks an agent wallet needs.
Quick answer
EIP-7702 lets an externally owned account delegate execution to contract code while retaining its address. The delegation persists until changed or cleared; the original private key retains control. Agent permissions, sponsorship and recovery depend on the selected account implementation rather than appearing automatically.
An agent-wallet team wants to add batched actions to an account its user already owns. Asking the user to move every asset to a new address complicates onboarding and breaks familiar account references. EIP-7702 offers another route: change how the existing address executes calls.
That convenience comes with a significant authorization decision. Choosing code for an account deserves more scrutiny than approving an ordinary purchase.
Research boundary: official sources reviewed November 1, 2026. EIP-7702 is Final and was included in Ethereum’s Pectra upgrade. This article contains no live delegation, audit or recovery test.
What actually changes
EIP-7702 introduces a transaction type carrying signed authorizations. An accepted authorization installs a delegation indicator pointing to contract code, which executes in the account’s context. The account address remains the same. The delegation is persistent, not a temporary capability that automatically disappears when that transaction finishes.
Conceptual account-delegation diagram, not a transaction we performed. Selecting code and authorizing each later action are separate responsibilities.
A contract can support richer account behavior, but the specific implementation determines which features exist. Do not advertise a daily spending cap, recovery method or sponsored transaction merely because the account uses 7702.
The original key still matters
Ethereum’s implementation guidance makes an important distinction: the EOA key retains control after delegation. Pointing an EOA at multisignature-style code does not erase the original single-key authority.
For an agent application, this creates two review questions. First, what powers does the delegate code expose to the agent or session signer? Second, who still controls the original key? Protecting a constrained agent key does not compensate for exposing the owner’s key to the same runtime.
A useful architecture document draws these keys separately. It should also distinguish account-level delegation from a permission granted inside that account. Removing one session permission is not necessarily the same operation as removing the account’s code delegation.
A failed setup is not necessarily a rolled-back delegation
The EIP specifies that processed delegation indicators are not rolled back when the transaction’s execution fails. This creates a product edge case worth testing explicitly: the UI reports a failed setup, but the account may already have changed execution behavior.
Our proposed response is to inspect account state before offering “try again.” Identify the current delegate and whether the intended initialization completed. Never infer the whole account state from the outer transaction’s success flag alone.
The EIP also highlights secure initialization and replay protection. For a team selecting an implementation, those are concrete review topics: which initialization parameters are signed, how action replays are prevented, and whether authorization binds the intended target and call data. A standards-compatible envelope is not evidence that the enclosed account logic was reviewed for these risks.
Plan the exit before the upgrade
A migration review should answer the following questions before a user opts in:
| Decision | Evidence to request from the implementation |
|---|---|
| Delegate selection | Exact network, code address, version and upgrade authority |
| Initialization | How owner-approved setup values are authenticated |
| Existing state | How storage from an earlier delegate is handled |
| Service outage | Whether the owner has a supported path without the normal relay |
| Exit | How to inspect, replace or clear delegation and verify the outcome |
Ethereum’s guidance warns that changing delegation does not erase existing storage. Treat a replacement as a state migration, not merely a new address in a configuration field. An implementation may interpret old storage differently, so the application needs a supported migration procedure and tests.
Where it belongs in an agent stack
7702 concerns account execution behavior. ERC-4337 can provide a submission and gas-sponsorship path; ERC-7715 addresses requests for limited permissions. They answer different integration questions and should have separate acceptance criteria.
Our editorial view is that retaining an address is a worthwhile UX benefit only when the product explains the authority change clearly. Show the selected implementation, preserve the owner’s recovery path, and make the resulting account state inspectable. See the EIP-7702 directory reference for the official starting point.
FOLLOW THE SOURCES