ERC-4337 and EIP-7702 Smart Wallet Security Guide

Smart wallets replace a single private key with programmable rules, and every rule is a new place where an attacker can win. ERC-4337 account abstraction and EIP-7702 delegation let Ethereum accounts batch transactions, have gas paid by a sponsor, use limited session keys and recover through guardians. Those features remove some classic failure modes, such as one lost seed phrase, but add bundlers, paymasters, modules and delegation signatures that users and builders must understand. This guide explains how the two standards work, what each component must enforce, how 7702 delegation phishing works and how to detect it, and what wallet teams, treasury operators and security reviewers should check. It assumes the basics in the Crypto Wallet Security Guide and does not repeat them. It is a technical security guide, not investment advice.

Key takeaways

Both standards are Final: ERC-4337 (account abstraction through an alternative mempool) and EIP-7702 (set code for EOAs, live on mainnet since the Pectra upgrade on 7 May 2025) are Final on eips.ethereum.org, while supporting specs such as ERC-7562 and ERC-7579 are still in Review or Draft.
The account's validation code is the security boundary: whatever validateUserOp accepts, the account will execute, so signature checks, session key scopes and recovery rules must be correct and audited.
A 7702 authorisation hands over the whole account: signing one delegates your EOA's code to a contract, so a malicious delegate can move every asset; the specification says applications should not ask users to sign authorisations at all.
Delegation is reversible but persistent: it stays until replaced or cleared by authorising the zero address, so monitoring the account's code is part of incident response.
Session keys and guardians are non-human identities: scope them by contract, function, amount and expiry, and inventory them like any other credential.

What it is and who it applies to

An externally owned account (EOA) is controlled by one secp256k1 key: whoever has the key can do anything. A smart contract account defines its own rules for what counts as a valid instruction. Account abstraction means letting those contract rules, rather than one fixed signature scheme, decide validity.

ERC-4337: Account Abstraction Using Alt Mempool (Status Final, created 2021-09-29) achieves this without changing consensus. Users sign a UserOperation that goes to a separate mempool; bundlers package UserOperations into a single transaction to a singleton EntryPoint contract.
EIP-7702: Set Code for EOAs (Status Final, Core) adds transaction type 0x04, which lets an existing EOA point its code at a delegate contract. The address and assets stay the same, but the account can now run smart-account logic. ERC-4337 now lists EIP-7702 as a requirement, so a delegated EOA can act as a 4337 account.

This matters to wallet developers, dapp teams that request signatures, organisations running treasuries or payment flows on smart accounts, operators of bundler and paymaster infrastructure, and security teams reviewing any of these. It also matters to end users, because 7702 delegation is now a phishing target. For contract-level access control see the Smart Contract Access Control Guide.

Structure and key requirements

ERC-4337 components

Component	Role	Security requirement from the specification
UserOperation	Pseudo-transaction with sender, nonce, factory data, callData, gas limits, paymaster fields and signature	The account defines signature semantics, but the signature must bind to the chain ID and the EntryPoint address to prevent replay
EntryPoint	Singleton contract; handleOps runs a verification loop, then an execution loop	Central trust point for every 4337 account, so it needs audit and formal verification; it must call the sender only with the validated calldata
Smart account	Implements validateUserOp, returning validation data with validUntil and validAfter	Gate sensitive functions so only the EntryPoint (or the account itself) can call them
Nonce	256 bits: 192-bit key and 64-bit sequence, managed by EntryPoint getNonce	Parallel nonce channels are allowed; replay protection depends on correct use
Bundler	Simulates and packages UserOperations into handleOps transactions	Enforces off-chain validation rules (ERC-7562) to avoid denial of service
Paymaster	Sponsors gas through validatePaymasterUserOp and optional postOp	Staking and bundler reputation limit paymaster-driven denial of service
Factory	Deploys accounts, ideally with CREATE2 so addresses are known in advance (getSenderAddress)	Must be staked if it touches global state

The specification names two core safety properties: safety against arbitrary hijacking (the EntryPoint only calls a sender after that sender's validateUserOp passed) and safety against fee draining (execution uses the same calldata that was validated). It also warns that unrelated senders can share one transaction, so sensitive transient storage must be cleared manually, and that upgradeable accounts should use namespaced storage (ERC-7201) to avoid layout collisions.

ERC-7562, Account Abstraction Validation Scope Rules (status Review as of November 2026), defines what validation code may do: it bans environment-dependent opcodes such as TIMESTAMP and BLOCKHASH during validation, restricts storage access, and tracks paymasters and factories as OK, THROTTLED or BANNED by reputation. It recommends a minimum stake of roughly 1,000 US dollars equivalent per chain and a one-day (86,400 second) minimum unstake delay.

EIP-7702 mechanics

Authorisation tuple: [chain_id, address, nonce, y_parity, r, s], signed by the EOA key over keccak(0x05 || rlp([chain_id, address, nonce])).
Delegation indicator: the account's code becomes 0xef0100 followed by the delegate address. Calls to the account run the delegate's code in the account's context, with the account's storage and balance.
chain_id 0: the authorisation is valid on every chain. A specific chain ID limits it to one chain.
Nonce: must equal the account's current nonce, so an authorisation can be invalidated by sending any transaction that increments the nonce before it is used.
Revocation: authorising the zero address resets the code to empty and restores plain EOA behaviour. The private key keeps full control throughout: delegation adds a code path, it does not remove the key.

Modular accounts

ERC-7579, Minimal Modular Smart Accounts (Draft), standardises plug-in modules: validators (type 1), executors (type 2), fallback handlers (type 3) and hooks (type 4). Its own security notes flag delegatecall targets, modules that revert on uninstall to block their removal, weak fallback handler authorisation, hooks that revert to freeze an account, and self-calls that bypass stricter checks on configuration functions.

Identity and NHI requirements

Smart wallets turn one key into a set of credentials, several of which are held by software, not people. Treat each as a non-human identity with an owner, scope and expiry. See the AI Agents with Crypto Wallets Security Guide for agent-held keys.

Credential	Typical holder	Controls
Owner key or passkey	User or treasury signer	Hardware-backed storage, never used for routine actions once session keys exist
Session key	Browser, game client, bot or AI agent	Limit by target contract, function selector, token, amount per period and validUntil; revoke on logout or device loss
Guardian (social recovery)	Friends, a second device, an institution	Threshold of several guardians, a time delay before recovery executes, notification to the owner, ability to cancel
Paymaster signer	Sponsor's backend service	Server-side secret in a key manager, per-user and per-period spending caps, rotation and monitoring
Bundler and relayer keys	Infrastructure operator	Hot wallet limits, alerting on balance drain, separation from treasury keys
Module installer rights	Owner or admin role	Require the strongest validator for installing validators, executors and hooks

Paymaster signing keys deserve particular care: EIP-7702 notes that sponsors can lose funds when an authority invalidates an authorisation or sweeps assets, so relayers may need bonds or reputation. Multisig treasuries are covered in the Multisig Treasury Operations Guide.

How 7702 delegation phishing works, and how to stop it

Because one signed tuple delegates the whole account, phishing has shifted from token approvals to authorisations. A fake site, airdrop page or "upgrade your wallet" prompt asks the user to sign a 7702 authorisation pointing at an attacker's contract, often with chain_id 0 so it works on every chain. Once included, the attacker can call the account and move native coins and tokens. Ethereum.org's Pectra page warns that anyone telling you to "upgrade" your ETH is running a scam.

For users: only accept delegation changes inside your wallet's own settings, never from a website pop-up. Treat any signature request that mentions delegation, authorisation, smart account upgrade or EIP-7702 from a dapp as hostile.
For wallet teams: the specification states applications must not ask users to sign authorisations and that wallets should not offer such an interface. Limit delegation to a short allowlist of audited delegate contracts, show the delegate address and its verified name, warn hard on chain_id 0, and require setup calldata to be signed by the EOA key to block front-running of initialisation.
For dapp and protocol teams: stop relying on msg.sender == tx.origin to mean "not a contract"; under 7702 that check no longer holds, which affects some reentrancy guards and sandwich protection.
If compromised: clear the delegation by authorising the zero address from a safe device, move remaining assets to a fresh account with a new key, and revoke token approvals. The drainer pattern is covered in the Crypto Scam and Drainer Guide.

Choosing between ERC-4337 accounts and EIP-7702 delegation

Factor	New ERC-4337 smart account	EIP-7702 delegated EOA
Address	New counterfactual address from the factory	Keeps the existing address, balances and history
Root of control	Whatever validation logic the account defines	The original EOA key always retains full control alongside the delegate
Key loss recovery	Guardians or other validators can rotate the owner	Delegate logic can add recovery paths, but the EOA key cannot be rotated away
Reversal	Upgrade or module change under the account's own rules	Re-delegate or authorise the zero address with the EOA key
Typical use	New users, organisations wanting policy-based control from the start	Existing users adding batching, sponsorship or session keys

Implementation steps

Choose the model: new ERC-4337 smart accounts give counterfactual addresses and full flexibility; EIP-7702 keeps an existing address and history. For organisations, decide whether the EOA key will be retired to cold storage after delegation, because it still overrides everything.
Select audited code: use account, delegate and module implementations with published audits, and pin the EntryPoint version the account trusts.
Design validation: define owner, session key and guardian rules on paper first: who can do what, up to what value, until when, and how each is revoked.
Use namespaced storage: follow ERC-7201 layouts so later upgrades or changes of delegate do not corrupt state; if in doubt, clear storage before migrating, as EIP-7702 advises.
Test on a testnet: include replay across chains, expired session keys, guardian recovery with a cancellation, module uninstall, paymaster refusal and a forced delegation reset.
Roll out in stages: start with low-value accounts and capped session keys, then raise limits once monitoring is in place.
Plan rollback: document the zero-address revocation path for 7702 and the owner-only recovery path for 4337 accounts, and rehearse both.

Evidence and assessment

Reviewers and auditors should ask for evidence that the rules are both correct and monitored.

Code assurance: audit reports covering validateUserOp, paymaster logic, modules and delegate contracts, plus test coverage for the safety properties above. See the OWASP Smart Contract Top 10 Guide.
Credential inventory: a current list of session keys, guardians and paymaster signers with scope, expiry and owner.
On-chain monitoring: alerts when an account's code changes (a new 0xef0100 indicator), when modules are installed or removed, when guardians start recovery, and when session keys approach limits.
Paymaster controls: spend per user and per day against caps, deposit balance alerts on the EntryPoint, and rejected sponsorship rates.
Metrics: percentage of session keys with expiry under 30 days, median time to revoke a lost device's key, number of unexpected delegation changes detected, recovery drills completed per year, and paymaster loss per month.

Mapping to other frameworks

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Session keys, guardian keys and paymaster signers need issuance, scope, expiry and revocation
NIST SP 800-53 Rev. 5	SC-12 Cryptographic Key Establishment and Management	Owner key storage and retirement after delegation
NIST SP 800-53 Rev. 5	SI-4 System Monitoring	Monitoring account code changes, module events and recovery attempts
NIST CSF 2.0	PR.AA-01	Identities and credentials, including software-held keys, are managed
MITRE ATT&CK	T1566 Phishing	Delivery route for malicious authorisation requests
CCSS	Key generation, storage and usage aspects	See the CryptoCurrency Security Standard Guide for custody controls

Common pitfalls

Unscoped session keys: a key meant for one game or agent can call any contract or move any token, so its theft equals owner key theft.
Treating 7702 as a one-off: delegation persists, and a later change of delegate with an incompatible storage layout can corrupt state.
Front-runnable initialisation: setup that anyone can call after delegation lets an observer initialise the account with their own owner.
Cross-chain authorisations: chain_id 0 signatures used for convenience become valid on every chain, including ones the user never uses.
Single guardian or instant recovery: recovery without a threshold and delay becomes the easiest takeover path.
Unlimited paymaster sponsorship: a sponsor without per-user caps funds an attacker's gas until its deposit is empty.

Practitioner checklist

Confirm the status of every standard you rely on (4337 and 7702 Final; 7562 Review; 7579 Draft as of November 2026).
Allow delegation only from wallet settings to an allowlist of audited delegate contracts.
Block or loudly warn on chain_id 0 authorisations.
Scope every session key by contract, function, amount and expiry.
Require a guardian threshold, a time delay and owner notification for recovery.
Cap paymaster spend per user and per period and alert on deposit drops.
Monitor accounts for code changes, module installs and recovery events.
Rehearse 7702 revocation and 4337 recovery at least once a year.
Remove msg.sender == tx.origin assumptions from your contracts.

Account Abstraction and Smart Wallet Security Guide: ERC-4337 and EIP-7702 Risks