ERC4337 vs. EIP-7702
ERC-4337 and EIP-7702 are two complementary attempts to bring account-abstraction UX to a chain built around EOAs. ERC-4337 (live since 2023) defines the UserOperation, EntryPoint, bundler, and paymaster architecture — smart accounts get first-class transactor behavior through a parallel mempool. EIP-7702 (Pectra, 2025) lets an existing EOA delegate execution to smart-account code via a signed authorization, without migrating to a new address. Both are real progress on Ethereum. Neither is a substitute for an account that was account-shaped from the start.
Comparison
| Feature | ERC-4337 | EIP-7702 |
|---|---|---|
| Primary object | UserOperation from a smart account | set-code transaction from an EOA |
| Infrastructure required | bundler + EntryPoint + optional paymaster | normal transaction path plus delegated code |
| Address migration | not by itself — a new smart-account address is typical | none needed — the existing EOA keeps its address |
| Gas sponsorship | paymaster via EntryPoint | any transaction sender can already cover gas for a delegated EOA; matching ERC-4337's exact paymaster UX means pairing 7702 with 4337 infrastructure |
| Validation | validateUserOp on the account | EOA authorizes delegation; delegated code handles execution |
| Residual EOA key risk | not present for native contract accounts | present, unless the wallet design adds explicit revocation |
Complementary, and both still EOA-shaped underneath
EIP-7702 solves the migration problem ERC-4337 alone couldn't: users already have EOAs holding assets, ENS names, transaction history, and airdrop eligibility, and 7702 lets them upgrade in place instead of starting over on a new smart-account address. ERC-4337 solves the ecosystem problem — bundlers, paymasters, and wallet infrastructure that already exists. Used together, a wallet can upgrade an address via 7702 and route sponsored or bundled operations through 4337 infrastructure.
What neither one solves is the underlying question of what the account is. EIP-7702 delegates execution to code, but the original ECDSA key remains authoritative unless the wallet design carefully handles the delegation lifecycle — the single-key risk that started the whole account-abstraction effort doesn't fully go away, it moves.
Where LUKSO starts from a different place
A Universal Profile isn't an EOA wearing delegated code — it's LSP0, an account contract from creation, with LSP6 as the permission layer and no residual single-key authority to reason about. There's no delegation lifecycle to manage because there was never a bare key holding the account in the first place.
Related reading: ERC-4337 vs the LSP account stack · EOA vs Universal Profile · The EOA key-risk problem