Guide for Wallet Devs for Getting Started with EIP-7702 + ERC-4337
EIP-7702 allows an Externally Owned Account (EOA) to designate a smart contract as its execution logic. This lets an EOA act as a smart contract account.
Combined with ERC-4337, EIP-7702 allows EOAs to behave like smart accounts by enabling gas abstraction, batched transactions, and support for additional validation methods like passkeys, session keys without deploying a permanent contract upfront.
This post explains what wallet developers need to know to integrate EIP-7702 with ERC-4337.
How EIP-7702 Works
EIP-7702 introduces a new way for EOAs to opt into smart contract logic. To do this, the EOA signs an authorization tuple that designates a specific delegate contract as the temporary validator and executor. This new transaction type introduces an authorization list. Each authorization tuple in the list is defined as:
[ chain_id, address, nonce, y_parity, r, s ]Why Use EIP-7702 With ERC-4337?
Delegation via EIP-7702 works directly for executing batched transactions in the delegate contract without any additional infrastructure.
However if you want to support:
Gas abstraction (via paymasters like Circle’s USDC paymaster)
Alternative authentication methods (i.e. passkeys, session keys, or non-ECDSA signature schemes)
Privacy-preserving withdrawals
Then you’ll need a relayer or a decentralized network like the ERC-4337 mempool to submit transactions on behalf of the EOA. This is where ERC-4337 comes in.
The recommended approach is to use ERC-4337 (EntryPoint v0.8 or higher) because it provides:
A standardized interface for relaying UserOperations
Built-in support for paymasters (apps covering gas fees or accepting token-denominated gas)
Support for alternative validation methods via delegate contracts (i.e. passkeys, session keys)
Support for censorship resistance via a public mempool so anyone can see and is incentivized to include your transaction
Enforces init functions being called through EntryPoint for safe initialization when using paymasters
In short: 7702 gives your account programmable execution; 4337 adds gas abstraction via paymasters and additional validation methods without compromising censorship resistance.
How to Use EIP-7702 With ERC-4337
When submitting a 7702-enabled UserOperation in ERC-4337, you include just one of the tuples (not the entire authorization list). In the context of a UserOperation, this single tuple is called eip7702Auth.
Here’s how it looks inside the RPC call:
{
jsonrpc: "2.0",
id: 1,
method: "eth_sendUserOperation",
"params": [
{
eip7702Auth: {
chainId,
nonce,
address,
r,s,yParity
},
sender, // address
... // all other userop params
},
entryPoint // address
]
}The EOA signs the authorization tuple and includes it in the UserOperation along with their EOA address (as the sender). In ERC-4337, the sender field must always be the EOA address. The eip7702Auth field tells the bundler which delegate contract to simulate for that transaction.
The EntryPoint contract does not verify the eip7702Auth signature or handle delegation logic; it just calls validateUserOp() at the sender’s address.
Security Considerations
Warn users if an existing delegation is already present on the account.
Wallets should never silently overwrite another delegation without the user's consent. If the same private key is used in multiple wallets, each one might try to assign its own delegate contract. For example, one wallet might add passkey support, while another wants to batch calls. Overwriting the delegation could unintentionally break the original functionality. Before applying a new delegation, the wallet should check for an existing one and prompt the user to confirm the change.
Only use a proxy contract as a delegate if you trust the upgrade manager.
If you do need a proxy (to allow upgrades), make sure the person or team controlling upgrades is trustworthy. Otherwise, they could withdraw all your assets and take control of the account. For instance just as an example, the SafeEIP7702Proxy shows how a proxy can be used to securely initialize and manage delegations in EIP-7702-compatible accounts. Note: the SafeEIP7702Proxy is not audited and with a proxy pattern you have to rely on an external team to not upgrade to an unsafe contract.
For wallets that allow third-party delegations (typically hardware wallets used with different software wallets for signing):
Only whitelist trusted contracts
Never whitelist a 3rd party proxy
Never whitelist a contract not created by CREATE2
Be especially cautious with delegations where chain_id = 0 (meaning the delegation works across all chains), as this broadens the attack surface