When I started wiring autonomous agents into on-chain wallets, the hardest question was never "which model?" It was "which account do I hand the agent?" A raw private key is a liability. A freshly deployed smart contract wallet means a new address, migrated funds, and re-approving every token. ERC-7702 changed that calculus: it lets me keep my existing address and private key while giving that account the programmable guardrails an agent needs. These are my working notes on how it works, how it differs from ERC-4337, and how I use it for agent and intent wallets in 2026.
What ERC-7702 actually does
ERC-7702 went live on Ethereum mainnet on 7 May 2025 as part of the Pectra hard fork. It introduces a new transaction type (0x04, "SetCode") that carries a signed authorization pointing an externally owned account (EOA) at an implementation contract. After that transaction, the EOA's code field holds a small delegation designator: the three bytes 0xef0100 followed by the implementation address. The EVM reads that, and every call to your address now executes the implementation's logic.
The important part for a developer: the address does not change and the private key does not change. The same account that has held your ETH for three years can suddenly batch transactions, sponsor its own gas through a paymaster, and enforce permission rules — without you deploying a new wallet or moving a single token. That is why the community calls it a "smart EOA." It is an account that is simultaneously a normal EOA (the key still signs) and a smart contract (delegated code runs on calls).
ERC-7702 vs ERC-4337: the key differences
This is the section people most want, and it is where I see the most confusion. The two standards are not competitors — they solve different layers of the same problem.
ERC-4337 is account abstraction implemented entirely outside the protocol. It never touched the EVM consensus rules. Instead it defines an alternative mempool of UserOperation objects, off-chain bundlers, and a singleton EntryPoint contract. To use it you deploy a brand-new smart contract wallet at a brand-new address. Your old EOA is left behind.
ERC-7702 is a protocol-level change shipped in a hard fork. It does not need a separate mempool or bundler infrastructure to function at the base level — a plain type-0x04 transaction upgrades the account in place. Crucially, it reuses your existing EOA address.
Here is how I summarize it to my team:
|
ERC-4337 |
ERC-7702 |
| Layer |
Off-chain infra (mempool, bundler, EntryPoint) |
In-protocol (Pectra hard fork) |
| Address |
New contract address |
Keeps existing EOA address |
| Activation |
Deploy a new wallet |
Sign one authorization |
| Private key |
Wallet owner key(s) |
Original EOA key still controls |
| Best at |
Full account abstraction from scratch |
Upgrading accounts that already have funds |
The two compose beautifully. A common 2026 pattern is to delegate a 7702 EOA to a 4337-compatible smart-account implementation. You get EntryPoint support, bundlers, and paymasters — but on the address you already fund. So the honest answer to "4337 or 7702?" is usually "both": 7702 for the account upgrade path, 4337 for the richer execution stack behind it.
The delegation mechanics
The authorization is the heart of the standard. Each entry in a transaction's authorization_list is a tuple: (chain_id, address, nonce, y_parity, r, s), signed by the EOA being delegated. In pseudocode the signing side looks like this:
authorization = {
chainId: 1, // 0 = valid on ANY chain (be careful)
address: IMPLEMENTATION, // contract whose code you adopt
nonce: currentNonce + 1
}
sig = sign(keccak256(0x05 || rlp([chainId, address, nonce])), eoaPrivKey)
// broadcast a type-0x04 tx carrying [authorization, sig]
A few things I always check. First, chain_id = 0 makes the authorization valid on every chain — convenient for multi-chain rollout, dangerous because a signature captured on one chain replays on another. I use an explicit chain ID unless I have a deliberate reason not to. Second, the EOA's own key signs the authorization, so the root key never loses control: it can re-delegate to a new implementation or clear the delegation entirely at any time. Third, re-delegating between implementations with different storage layouts can cause storage collisions — moving from implementation A to B without accounting for slot layout has drained accounts in the wild. Standardized storage layouts exist specifically to avoid this.
Why a smart EOA fits AI agents
An AI agent that can move funds is a security surface, full stop. The old options were both bad. Give the agent your raw private key and a single prompt-injection or a buggy tool call drains everything. Deploy a fresh 4337 wallet and you carry the operational overhead of a second account for every user.
A 7702 smart EOA lets me keep one account and attach policy to it. The delegated implementation can enforce per-transaction spend caps, allow-list the contracts the agent may call, restrict function selectors, and require batching so a multi-step DeFi action either fully succeeds or fully reverts. The agent never holds the root key. It holds a narrowly scoped credential that the implementation validates on every call. If the agent misbehaves, the blast radius is bounded by the policy, not by the account balance.
Session keys for autonomous DeFi
Session keys are the feature that makes autonomous DeFi tolerable to me. A session key is a scoped, time-limited signing key that the delegated contract recognizes as authorized for a subset of actions. The root EOA key grants it; the implementation enforces its limits.
A realistic scope for a yield-rebalancing agent:
- Valid for 24 hours, then auto-expires.
- May call only two contracts (a specific DEX router and one lending pool).
- May spend at most 500 USDC per transaction, 2,000 USDC per session.
- May call only
swap and deposit selectors — never approve(max) or transfer to arbitrary addresses.
The agent signs its transactions with the session key. If a prompt injection convinces it to send funds to an attacker address, the implementation rejects the call because that address is not in scope. This is a genuine, minimal-trust reduction in risk — reference implementations for EIP-7702 session keys are open source in 2026 — but note the word reduction. A session key with a 2,000 USDC budget can still lose 2,000 USDC. Scope tightly and keep balances low.
Intent wallets built on ERC-7702
Intent-based execution and 7702 fit together naturally. In an intent flow the user (or agent) signs a desired outcome — "get me the best yield on 1 ETH" — rather than a specific transaction, and a solver network competes to fill it. A 7702 account can authorize the winning solver through a session key constrained to the intent's bounds: a maximum slippage, a set of approved venues, an expiry. The solver executes, the delegated code validates against those bounds, and the batch reverts atomically if anything violates them. Through 2026 this is the pattern I see most often for agent wallets — account upgrade plus scoped authorization plus a solver doing the heavy execution — because it keeps the human's signing surface tiny while still allowing autonomous, competitive execution.
Risks I take seriously
I will not pretend this is free safety. The real risks, from the ones I have actually hit or watched others hit:
- Malicious delegation. Signing an authorization to a hostile implementation hands over full control. "Sign this to upgrade your wallet" is the new phishing lure. Verify the implementation address the way you would verify a token approval.
- The root key is still supreme. 7702 does not protect a key that is already compromised or has a sweeper bot on it. Policy lives in the delegated code, but the root key can re-delegate around it.
- Cross-chain replay.
chain_id = 0 authorizations replay everywhere. Use explicit chain IDs.
- Storage collisions on re-delegation. Switching implementations with mismatched storage layouts can corrupt state or expose funds. Stick to standardized layouts.
- Session-key scope is your only backstop. A loose scope is theatre. Enforce spend caps, allow-lists, selector restrictions, and short expiries, and keep the agent-facing balance small.
My rule of thumb: treat the 7702 delegation like a root approval and the session key like a scoped API token. Audit the first, rotate the second.
Frequently Asked Questions
Does ERC-7702 replace ERC-4337?
No. They operate at different layers and compose. Many 2026 setups delegate a 7702 EOA to a 4337-compatible implementation, gaining EntryPoint, bundlers, and paymasters on the existing address. Think of 7702 as the upgrade path and 4337 as the execution stack.
Can I undo a delegation?
Yes. The root EOA key retains full control. You can sign a new authorization pointing at a different implementation, or clear the delegation entirely. The account reverts to a plain EOA.
Is it safe to give an AI agent a session key?
Safer than the root key, not risk-free. The delegated contract enforces the session key's scope — spend caps, allow-listed contracts, restricted selectors, expiry. A tightly scoped key bounds the damage, but anything within that budget can still be lost. Scope hard and fund lightly.
Which chains support ERC-7702?
It shipped on Ethereum mainnet with Pectra in May 2025, and EVM-compatible L2s have rolled it out through 2025 and into 2026. Always confirm support and the correct chain ID on your target network before delegating.
Conclusion
ERC-7702 is the piece that made agent wallets practical for me: I keep my funded address and private key, and I attach programmable policy to it instead of trading the account for a smart wallet. The mental model that keeps me out of trouble is layered — 7702 upgrades the account, session keys scope what the agent may do, and (often) a 4337 implementation handles execution behind it. None of it removes the fundamentals: verify what you delegate to, use explicit chain IDs, enforce real session-key limits, and keep agent balances small. Do that, and a smart EOA gives an autonomous agent exactly as much rope as you decide to hand it — and not an inch more.
