EIP-7702 vs ERC-4337: How Ethereum Smart Accounts Differ

EIP-7702 and ERC-4337 both support programmable Ethereum accounts, but they work at different layers. EIP-7702 adds a type-0x04 set-code transaction so an externally owned account (EOA)—an address controlled by a private key—can authorize contract code to execute in its account context. ERC-4337 defines a higher-layer flow in which a smart account submits a UserOperation through a bundler to an EntryPoint contract. They are not mutually exclusive: ERC-4337 explicitly supports EIP-7702 delegated accounts. The practical choice is whether you need to extend an existing EOA, standardize the operation pipeline, or combine both.

The core difference

EIP-7702 lets an EOA authorize a delegation indicator that points to contract code. The EOA keeps its address, while calls can execute the delegated code in the EOA’s context. The delegation persists until a later valid authorization changes or clears it. Ethereum activated EIP-7702 as part of the Pectra upgrade on 7 May 2025.

That changes account behavior, but EIP-7702 does not itself define an ERC-4337-style UserOperation mempool, bundler service or paymaster. The delegate contract and surrounding wallet infrastructure determine which programmable features are available.

ERC-4337 takes a different route. A UserOperation is an account action submitted to a dedicated mempool, not a protocol transaction. A bundler collects and validates eligible operations, then submits a normal Ethereum transaction that calls the EntryPoint contract to execute a bundle. A paymaster can agree to cover gas for an account, but sponsorship is optional and does not automatically make every transaction free.

	EIP-7702	ERC-4337
Main job	Authorize delegated code for an existing EOA	Define a smart-account operation and relay pipeline
Core mechanism	Type-0x04 set-code transaction and authorization list	`UserOperation`, alternate mempool, bundler and `EntryPoint`
Account identity	Keeps the EOA address and its key-based control	Uses a smart-contract account, which can supply its own validation logic
Gas sponsorship	Possible through implementation and a relayer; not a built-in paymaster service	Optional paymaster extension or account-funded gas deposit

They can work together

The ERC-4337 specification includes a path for EIP-7702 delegated accounts. An EIP-7702 authorization tuple may accompany a UserOperation, but it is not part of the UserOperation structure itself. In a combined design, EIP-7702 can give an existing EOA programmable account code, while ERC-4337 supplies the standardized operation, bundler and EntryPoint flow, with a paymaster if the implementation supports one.

This is a design option, not a guarantee of universal compatibility. Check the target chain, wallet, delegated contract, EntryPoint version, bundler and paymaster together before shipping. A bundler is also not the same role as an Ethereum block builder or relay; the ERC-4337 specification allows a bundler to work with block-building infrastructure such as MEV-Boost. Our MEV-Boost explainer covers that separate proposer-builder layer.

Which should a team use?

Start with EIP-7702 when keeping an existing EOA address is central and you have a reviewed delegate contract that implements the needed permissions and execution rules.
Start with ERC-4337 when you need a contract account with custom validation and a standard pipeline for submitting, bundling and executing account actions without a consensus-layer transaction-type change.
Combine them when an existing EOA needs programmable behavior and the product also benefits from ERC-4337 bundlers, EntryPoint execution or optional paymaster support.

The choice is not “EOA versus smart wallet” in every case. EIP-7702 makes an EOA capable of using delegated code; ERC-4337 describes how smart-account operations are packaged and relayed. The exact account policy still lives in the account or delegate implementation.

Security checks before enabling a delegate

Review the exact delegate address and code. An authorization gives the delegated implementation meaningful control in the account’s context. Do not treat a signature request as harmless setup.
Check chain scope. EIP-7702 accepts an authorization with the current chain ID or chain_id = 0; zero is not a chain-specific restriction. Confirm the intended network and the code available at the destination address.
Protect initialization and storage. The EIP warns about front-running an unprotected initializer and storage collisions when account logic changes. Test initialization, upgrades and recovery paths explicitly.
Keep the key threat model honest. The EOA’s private key retains the ability to sign and change its delegation. EIP-7702 alone does not turn an EOA into a multisig or guarantee recovery if a key is lost or compromised.
Test failure behavior. The authorization list is processed before transaction execution; a later execution failure does not roll back delegation indicators already processed. A reverted call is not proof that the delegation was never set.

Wallet presentation is a separate layer of protection: a user should be able to understand what an authorization requests. For the complementary problem of rendering transaction data in a human-readable way, see our ERC-7730 clear-signing guide.

Frequently asked questions

Are EIP-7702 and ERC-4337 competing standards?

No. EIP-7702 authorizes code for an existing EOA; ERC-4337 defines a smart-account operation and relay flow. The ERC-4337 specification includes support for EIP-7702 delegated accounts, so an implementation can use both.

Does EIP-7702 make an EOA a multisig?

Not by itself. The delegated code can implement multi-signature rules, but the EOA’s private key remains able to sign and change the delegation. The security properties depend on the implementation and its authority model.

Does ERC-4337 make gas free?

No. A paymaster may sponsor gas under its own rules, or the account can fund gas through its EntryPoint deposit. Sponsorship is an implementation choice with its own limits and costs.

Sources

EIP-7702: Set Code for EOAs — transaction type, authorization list, delegation behavior and security considerations.
ERC-4337: Account Abstraction Using Alt Mempool — UserOperation, bundlers, EntryPoint, paymasters and EIP-7702 account support.
Ethereum.org: Pectra upgrade — mainnet activation date and included EIP-7702 change.
Ethereum.org: EIP-7702 — account behavior, key authority and implementation guidance.

If your team is integrating delegated accounts or an ERC-4337 flow, contact SignorCrypto for a scoped review of the account architecture, initialization and wallet integration.