From EOAs to “Code‑Enabled” Accounts: Safer Patterns for EIP‑7702

Short description: EIP‑7702, live since Ethereum’s Pectra upgrade on May 7, 2025, lets legacy EOAs opt into programmable wallet logic by writing a delegation pointer to audited code. This post distills what actually shipped, what changed in the EVM, and pragmatic, safer patterns enterprises can adopt right now. (blog.ethereum.org)

Executive briefing

If your roadmap depends on smoother onboarding, sponsored gas, or enterprise‑grade controls without forcing users to migrate addresses, EIP‑7702 matters. It adds a new Type‑4 transaction that lets an EOA set a “delegation indicator” pointing at trusted smart‑wallet code. From that point, the account behaves like a programmable wallet until you reset the pointer—enabling batching, policy enforcement, paymasters, and session keys with a single on‑chain step. (eips.ethereum.org)

---

What actually shipped (and what didn’t)

• Pectra activated on mainnet on May 7, 2025 (epoch 364032). It included EIP‑7702. (blog.ethereum.org)
• EIP‑7702 defines:
  • A new EIP‑2718 transaction type: SET_CODE_TX_TYPE = 0x04. (eips.ethereum.org)
  • An authorization list of tuples [chain_id, address, nonce, y_parity, r, s], each signed by the EOA over keccak(0x05 || rlp([chain_id, address, nonce])). (eips.ethereum.org)
  • For each valid tuple, clients write a delegation indicator to the EOA’s code: 0xef0100 || address. Calls to the EOA then execute code at “address” in the EOA’s context. (eips.ethereum.org)
  • Setting the delegation is persistent until changed; delegating to the zero address clears code and restores a plain EOA. Earlier “temporary” drafts did not ship. (eips.ethereum.org)
• Gas/accounting highlights you’ll feel in production:
  • PER_AUTH_BASE_COST = 12,500 gas; PER_EMPTY_ACCOUNT_COST = 25,000 gas. Worst‑case cost is charged up‑front with refunds in some cases. (eips.ethereum.org)
  • The 7702 authorization consumes the signer’s “authority” nonce (must match and is then incremented). Nonce is bounded to < 2^64. (eips.ethereum.org)
  • During delegated execution, CODESIZE/CODECOPY reflect the target code, but EXTCODESIZE/EXTCODECOPY on the authority read the 23‑byte indicator—this can surprise tooling. (eips.ethereum.org)
• EIP‑3074 (AUTH/AUTHCALL) was withdrawn and is not in Pectra. If your decks still mention it, update them. (eips.ethereum.org)

---

Why this is a big deal for product and platform leaders

• Zero‑migration UX: users keep addresses and balances; you “upgrade” capabilities by pointing to audited wallet code. That removes the biggest adoption drag of smart accounts. (eips.ethereum.org)
• Immediate synergy with ERC‑4337: an EOA can delegate to an ERC‑4337‑compatible wallet implementation and be bundled, paymaster‑sponsored, etc., with today’s infra. (eips.ethereum.org)
• Multi‑chain reality: Ethereum mainnet supports it; Gnosis Chain lists 7702 as live since May 7, and BNB Chain added an equivalent via its Pascal fork (BEP‑441). Enterprises can standardize flows across EVMs. (docs.gnosischain.com)

---

The new execution model in one picture (well, text)

• Before the call:
  • The user broadcasts a Type‑4 tx with an authorization_list.
  • Client verifies signatures, authority nonces, and writes “0xef0100 || target” to each authority’s code, incrementing the nonce. (eips.ethereum.org)
• During calls to the delegated EOA:
  • CALL/CALLCODE/DELEGATECALL/STATICCALL load the target code and execute in the EOA’s context; code‑reading opcodes mostly don’t follow the pointer. (eips.ethereum.org)
• After:
  • Delegation persists until explicitly reset to 0x00…00 via another Type‑4 tx. Tooling must treat the EOA as “code‑enabled” going forward. (eips.ethereum.org)

Practical implication: “msg.sender == tx.origin only in the top frame” is no longer a safe invariant under self‑sponsoring flows; contracts relying on tx.origin for flash‑loan protection must be refactored. (eips.ethereum.org)

---

Security model changes you should plan for

• The private key still rules. Even after delegating, the EOA key can change the delegation at any time. Your risk model must protect both the key and the delegated code. (docs.safe.global)
• Mempool behavior: once an EOA is delegated, any call to it can move ETH or bump nonces. Client teams recommend limiting pending txs per delegated EOA to reduce invalidation. Wallets and relayers should avoid mempool assumptions from the EOA era. (eips.ethereum.org)
• Phishing surface has shifted: post‑Pectra, “upgrade to 7702” lures and mass‑delegation sweepers appeared. Treat any off‑wallet 7702 authorization prompt as malicious, and verify target code hashes. (cryptopolitan.com)

---

Safer adoption patterns we recommend (field‑tested)

1) Delegate only to audited, registry‑pinned implementations

• Use a “code registry” (on‑chain allowlist of codehash => implementation metadata) and refuse to sign 7702 tuples not on the registry. Require:
  • Source verified bytecode, immutable init, and no hidden upgrade paths.
  • Formalized signature domain and replay protection baked into the wallet code.
• Good starting points:
  • eth‑infinitism’s Simple7702Account (4337‑compatible, audited in the AA v0.8 line). (github.com)
  • Base’s EIP‑7702 Proxy (ERC‑1967 pattern with explicit nonce tracking and state validation). (github.com)
  • Safe’s experimental 7702 integrations (SafeLite, modified singleton). Treat as experimental unless audits are complete. (docs.safe.global)

What to codify in policy:

• Sign only to codehashes on the registry, not just addresses.
• Rotate the delegation to 0x0 (clear code) as part of incident response. (eips.ethereum.org)

2) Enforce spending policy in the wallet code, not in the dApp

Define a minimal policy surface that the delegated code must enforce before executing any call:

• Replay protection: monotonic nonces or EIP‑712 domain‑separated counters. (eips.ethereum.org)
• Quotas: per‑token/day spending caps, per‑tx value ceilings, cumulative budget windows.
• Scoping: allowlist target contracts and function selectors; optionally deny ERC‑20 approve() to non‑zero unlimited approvals.
• Time‑boxing: validUntil/validAfter windows for sub‑keys or sessions.
• Gas pinning: the signed intent should bind gas limits to avoid griefing via forced OOG. (eips.ethereum.org)

A minimal Solidity sketch for a 7702‑safe executor:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

// Minimal executor meant to be the EIP-7702 delegation target.
// Enforces: nonces, budgets, target/function allowlist, time windows.
contract PolicyExecutor {
    struct Intent {
        address target;
        uint256 value;
        bytes data;
        uint256 nonce;
        uint256 maxGas;
        uint48 validAfter;
        uint48 validUntil;
        uint256 dailyLimit; // per-token or ETH, simplified here
    }

    mapping(address => uint256) public nonces;              // per-authority
    mapping(address => uint256) public spentToday;          // reset logic omitted
    mapping(address => mapping(bytes4 => bool)) public ok;  // target+selector allowlist

    error NotAuthorized();
    error Expired();
    error LimitExceeded();
    error BadNonce();

    // EIP-1271-style validation for sub-keys or guardians can be added here.

    function execute(Intent calldata i) external {
        address authority = msg.sender; // executing in EOA context under 7702
        if (i.validAfter > block.timestamp || i.validUntil < block.timestamp) revert Expired();
        if (i.nonce != ++nonces[authority]) revert BadNonce();
        if (!ok[i.target][bytes4(i.data)]) revert NotAuthorized();
        if (i.value + spentToday[authority] > i.dailyLimit) revert LimitExceeded();

        (bool s, bytes memory r) = i.target.call{value: i.value, gas: i.maxGas}(i.data);
        if (!s) assembly { revert(add(r, 32), mload(r)) }
        spentToday[authority] += i.value;
    }
}

This shifts responsibility to the delegated code—where it belongs—rather than ad‑hoc dApp prompts.

3) Ship with “session keys” for teams and devices

For operations teams (treasury payouts, vendor settlements), add secondary signing keys with constrained permissions (“session keys”). Bind each session to:

• Specific contracts (e.g., USDC, a payroll contract),
• Value ceilings per period,
• Expiry timestamps,
• Optional rate limits.

Most 4337 wallets already implement session keys or plugins; pointing your EOA to that code via 7702 gets you the same UX with no address migration. (docs.erc4337.io)

4) Integrate paymasters deliberately

With 7702 -> 4337, you can sponsor gas or accept ERC‑20 fees. Best practice:

• Split paymaster policies: free‑tier (allowlist flows, small quotas) vs. enterprise tier (KYC’d accounts, higher limits).
• Make the user intent bind the token, maximum fee, and paymaster address to avoid fee‑bait‑and‑switch.
• For L2s and sidechains, confirm 7702 parity and paymaster API support (several EVMs now advertise 7702 support). (docs.gnosischain.com)

5) Wallet UX guardrails (must‑haves)

• Only the wallet UI may surface 7702 authorization signing. The EIP authors explicitly caution against letting dApps initiate these flows. (eips.ethereum.org)
• Prominent codehash and publisher badges; link to audits and source verification.
• “One‑click emergency restore” to clear delegation (set to 0x0) with hardware‑wallet confirmation. (eips.ethereum.org)
• Simulate post‑delegation behavior (note EXTCODESIZE vs CODESIZE differences) and display exact downstream calls/balances. (eips.ethereum.org)

---

Emerging risks, with data

• Mass‑delegation “sweepers”: Market‑maker Wintermute observed a cluster dubbed “CrimeEnjoyors”—tens of thousands of delegations to identical sweeper bytecode attempting to auto‑drain future ETH deposits from compromised EOAs. Losses were limited and many attempts unprofitable, but the pattern is live. Your SOC should monitor for known sweeper codehashes. (coindesk.com)
• Phishing “upgrade” campaigns: Security firms flagged lures pushing users to authorize delegation to malicious addresses. Policy: never sign 7702 authorizations from links or pop‑ups; only from your wallet’s native 7702 flow. Train support teams accordingly. (cryptopolitan.com)

---

Concrete implementation paths (with real stacks)

Path A: “4337 Inside” for zero‑migration smart accounts

• Point the EOA to a 4337‑compatible wallet implementation (e.g., Simple7702Account).
• Immediately gain: batching, ERC‑20 gas, paymasters, session keys, on all networks where 4337 infra exists. (github.com)
• Who’s doing this: multiple wallets shipped mainnet‑day support; some even gate hardware signing to audited delegates initially. (blog.ambire.com)

KPIs to track:

• Drop in failed “approve then swap” flows (should be near zero with atomic batching).
• Share of first‑session users with no native ETH who complete a transaction (via sponsorship).

Path B: Proxy façade for enterprise policy sprawl

• Delegate to a thin ERC‑1967 proxy that:
  • Validates authority signatures on upgrades,
  • Tracks nonces externally to prevent replay across delegates,
  • Enforces implementation state invariants (e.g., correct guardian set). (github.com)
• Swap implementations behind a stable proxy address as your program evolves (new limits, new modules).

Path C: Safe‑style custody with a 7702‑compatible core

• Use a slimmed‑down Safe variant (SafeLite) for teams that need multisig and policy, but not the full Safe storage layout. Treat as experimental until audits finalize. (docs.safe.global)

---

Example: CFO‑friendly batched payouts with guardrails

Goal: authorize your finance ops to run monthly vendor payouts from the corporate EOA without unlimited risk.

• Delegate to audited 4337 wallet code via a Type‑4 tx signed by the EOA’s hardware key. (eips.ethereum.org)
• Create a session key with:
  • Targets: USDC token + your payouts contract only.
  • Caps: ≤ $100k/day, ≤ $1M/month; max per recipient.
  • Expiry: 30 days; revocable by any executive key.
• Run via a paymaster to allow fees in USDC on L2.
• Observability:
  • Alert if delegation changes (codehash mismatch).
  • Alert on near‑limit spend or target violations.

Outcomes to expect: one‑click batched payouts, no open token approvals, and a clear blast‑radius if a session key leaks.

---

Operational gotchas to address before go‑live

• Tooling: update explorers/indexers that infer “contract vs EOA” via EXTCODESIZE. Delegated EOAs report a 23‑byte indicator; code‑following requires special handling. (eips.ethereum.org)
• Mempool policies: relayers and wallet backends should assume only one pending tx per delegated EOA to reduce invalidations. (eips.ethereum.org)
• Signing: 7702’s authorization digest uses a 0x05 “magic” prefix and is not EIP‑712/191; ensure your signers and HSMs support it. (eips.ethereum.org)
• Cross‑chain: confirm 7702 parity on target EVMs (e.g., Gnosis, BNB Chain BEP‑441). Differences in fee markets and calldata costs may affect batching economics. (docs.gnosischain.com)
• Wallet posture: initially allow delegation only to a curated list (Ledger’s approach of whitelisting targets is a useful model when rolling out to hardware signers). (ledger.com)

---

FAQ for decision‑makers

• Is this “temporary smart code per tx”? No. The shipped EIP writes a persistent delegation pointer; you can reset it to zero when desired. Early drafts proposing temporary code were replaced. (eips.ethereum.org)
• Can we still use 4337? Yes—and that’s the point. 7702 is a bridge: EOAs can adopt 4337 wallets with one transaction, then use today’s bundlers/paymasters. (eips.ethereum.org)
• Is this safe for retail? With the right wallet UX and curated delegates, yes. Do not allow sites to request 7702 signatures. Monitor for sweeper codehashes and train support teams on revocation flows. (cryptopolitan.com)

---

A 30‑day rollout plan (7Block Labs template)

Week 1

• Pick your delegate implementation(s); record codehashes in an internal registry with audit links. Wire up simulation that follows 7702 indicators. (github.com)
• Draft wallet UX copy for 7702 signing, codehash badges, and emergency reset.

Week 2

• Ship a small pilot on an L2 with paymaster‑backed flows. Gate hardware signing to whitelisted code only. (ledger.com)
• Instrument alerts: delegation‑changed, policy‑breach attempts, codehash drift.

Week 3

• Expand to mainnet with constrained session keys for ops. Migrate “approve+swap” flows to atomic batches.

Week 4

• Train support; publish revocation runbook (“set delegation to 0x0”), and run a red‑team exercise simulating a phishing attempt. (eips.ethereum.org)

---

Closing thought

EIP‑7702 doesn’t replace smart accounts—it accelerates them by making every EOA upgradeable to audited, policy‑aware code with one transaction. Teams that pair 7702 with disciplined code registries, session‑key policies, and curated wallet UX will see measurable improvements in conversion and incident containment—without forcing users to change addresses. That’s the pragmatic path to safer, smarter accounts in 2026.

---

Sources and further reading

• EIP‑7702 spec and rationale (transaction type 0x04; delegation indicator; gas and security considerations). (eips.ethereum.org)
• Ethereum Foundation: Pectra mainnet announcement (May 7, 2025 activation). (blog.ethereum.org)
• Ethereum.org: 7702 overview and authorization tuple. (ethereum.org)
• ERC‑4337 + 7702 changes (Simple7702Account; API updates). (github.com)
• Safe docs: 7702 integrations and caveats (experimental). (docs.safe.global)
• Base’s 7702 proxy pattern (secure upgrades). (github.com)
• Gnosis Chain 7702 status; BNB Chain BEP‑441 (Pascal) for 7702 parity. (docs.gnosischain.com)
• Risk intel: “CrimeEnjoyors” mass‑delegation sweepers; 7702 phishing warnings. (coindesk.com)

7Block Labs helps enterprises design, audit, and roll out 7702‑ready programmable accounts. If you want a code registry, wallet UX, and paymaster strategy tailored to your stack, we’re happy to share reference implementations and run a pilot.