What is ERC-4337?

Account abstraction was on the table for years before ERC-4337. EIP-86 (Vitalik Buterin, 2017) proposed protocol-level AA via a special precompile. EIP-2938 (2020) re-attempted it with a new transaction type. EIP-3074 (2021) introduced AUTH/AUTHCALL opcodes for invoker contracts. None of them shipped — each required consensus-layer changes that the network was not ready to ratify.

Meanwhile, a parallel meta-transaction track had been running since 2018. The team at Tabookey — Yoav Weiss, Dror Tirosh, and Alex Forshtat — published ERC-1613 (Gas Station Network v1) as the first standardized "user signs off-chain, relayer pays gas" proposal. Two years later, the standardized successor ERC-2771 (Secure Protocol for Native Meta Transactions) was opened by Alex Forshtat in July 2020 and finalized in August 2020 with eleven co-authors — including the same Tabookey core team plus Ronan Sandford, Patrick McCorry, Hadrien Croubois, Nicolas Venturo, Gavin John, and (notably) Fabian Vogelsteller. ERC-2771 standardized the trusted-forwarder pattern: contracts opt in to recover the original signer via _msgSender() from the last 20 bytes of calldata. It became the substrate for OpenGSN v2, OpenZeppelin Defender Relayer, Gelato, and Biconomy — and its Security Considerations section is candid about the load-bearing trust assumption: "A malicious forwarder may forge the value of _msgSender() and effectively send transactions from any address."

The two threads — protocol-level account abstraction (86 → 2938 → 3074) and contract-level meta transactions (1613 → 2771) — converged when Vitalik proposed ERC-4337 in late 2021. The Tabookey/OpenGSN team brought their meta-transaction experience directly: Weiss, Tirosh, and Forshtat appear on all three (GSN v1, ERC-2771, ERC-4337). The bundler is GSN's relay server, generalized. The EntryPoint is GSN's RelayHub, generalized. The paymaster is what gas sponsorship looks like when you bake it into the standard instead of leaving it to integrators. ERC-4337 is the meta-transaction lineage absorbing the account-abstraction ambition.

On 29 September 2021, Vitalik Buterin opened GitHub issue #4337 with co-authors Yoav Weiss (Ethereum Foundation account-abstraction lead), Dror Tirosh, Shahaf Nacson, Alex Forshtat, Kristof Gazso, and Tjaden Hess. Vitalik also wrote a Medium post on Infinitism framing the design — and the title itself was the strongest tell about what was being chosen:

ERC-4337: Account Abstraction Without Ethereum Protocol Changes.

That's the lead author of the standard telling the audience, in plain text, that this is a workaround chosen specifically to avoid a hard fork. The EIP-4337 Abstract is just as direct:

Historically, users could interact with Ethereum only by sending transactions from special accounts controlled by private keys, with transaction validation entirely enforced by fixed protocol rules. Account abstraction is an alternative model that allows each account to supply its own validation logic executed as smart contract code, while the protocol provides only minimal constraints.

The mechanism: a separate mempool of UserOperation envelopes; a singleton EntryPoint contract that everyone agrees on; bundlers that watch the alt-mempool, validate UserOps, and pack them into a single handleOps transaction on-chain; optional paymasters that sponsor gas from their own deposits. The smart account is a contract that implements validateUserOp; the EntryPoint calls it before executing.

EntryPoint v0.6 deployed to Ethereum mainnet on 1 March 2023, after audits by OpenZeppelin and Certora. v0.7 shipped in 2024 with improved paymaster and aggregator interfaces. v0.8 deployed in May 2025 — and that timing is significant, because alongside it Ethereum's Pectra hard fork activated EIP-7702, a protocol-level primitive that lets externally-owned accounts delegate execution to contract code in a single transaction.

EIP-7702 is co-authored by Vitalik Buterin — the lead author of ERC-4337. Four years after framing AA as something to ship without protocol changes, he was co-signing the protocol-level change. The EIP-7702 Motivation section is candid about the gap it was patching: existing EOAs cannot become ERC-4337 smart accounts without losing their address history, their ENS records, their reputation, and their airdrop eligibility. Six months earlier, at Devcon SEA in November 2024, Yoav Weiss had laid out a roadmap toward what he called a "modular native AA approach for L1 and L2." The spec's own authors and maintainers, in their own words, were walking ERC-4337 toward the substrate.

The rest of this page is about what that journey reveals — the tradeoffs ERC-4337 made deliberately to avoid a fork, and how a different design choice (account abstraction as substrate, not layer) plays out on LUKSO.

// ─── EntryPoint (singleton) ──────────────────────────────────────────
function handleOps(PackedUserOperation[] calldata ops, address payable beneficiary) external;
function simulateHandleOp(PackedUserOperation calldata op, address target, bytes calldata targetCallData)
  external returns (uint256 preOpGas, uint256 paid, uint256 validationData, uint256 targetSuccess, bytes memory targetResult);
function depositTo(address account)  external payable;
function withdrawTo(address payable withdrawAddress, uint256 amount) external;

// ─── IAccount (each smart account implements) ────────────────────────
function validateUserOp(
  PackedUserOperation calldata userOp,
  bytes32 userOpHash,
  uint256 missingAccountFunds
) external returns (uint256 validationData);

// ─── IPaymaster (optional, sponsors gas) ─────────────────────────────
function validatePaymasterUserOp(
  PackedUserOperation calldata userOp,
  bytes32 userOpHash,
  uint256 maxCost
) external returns (bytes memory context, uint256 validationData);

function postOp(
  PostOpMode mode,
  bytes calldata context,
  uint256 actualGasCost,
  uint256 actualUserOpFeePerGas
) external;

// ─── PackedUserOperation (the envelope) ──────────────────────────────
struct PackedUserOperation {
  address sender;
  uint256 nonce;
  bytes   initCode;
  bytes   callData;
  bytes32 accountGasLimits;     // verificationGasLimit + callGasLimit
  uint256 preVerificationGas;
  bytes32 gasFees;              // maxPriorityFeePerGas + maxFeePerGas
  bytes   paymasterAndData;
  bytes   signature;
}

The mental model: a user signs a UserOperation; it lands in a separate alt-mempool; a bundler picks it up, validates it (by simulating validateUserOp on the account and validatePaymasterUserOp on any paymaster), packs valid UserOps into a single transaction calling EntryPoint.handleOps(), and submits on-chain. The EntryPoint runs validation again on-chain, calls into the smart account to execute the user's actual callData, and (if a paymaster was involved) calls postOp for sponsorship accounting.

The full surface is much larger than the few signatures shown above: 30+ methods across IEntryPoint, IAccount, IPaymaster, IAggregator, with several version-specific shapes (the PackedUserOperation struct above is the v0.7+ form). Audit and tooling complexity sits on the size of that surface. Canonical specification: eips.ethereum.org/EIPS/eip-4337.

The two co-authors of ERC-20 ended up answering the same account-abstraction question with two structurally different stacks. The divergence is deeper than ERC-4337 alone — it begins with ERC-2771, runs through the LSP suite as a coherent system, and now meets Ethereum's Pectra upgrade where the two approaches finally have to be compared in production.

In November 2015, Vitalik Buterin and Fabian Vogelsteller co-authored ERC-20 — the moment their paths first crossed in the historical record. Five years later, they were on the ERC-2771 author list together as well: Vogelsteller was co-author #10 of the Secure Protocol for Native Meta Transactions, alongside the Tabookey/OpenGSN team (Weiss, Tirosh, Forshtat) who would go on to co-author ERC-4337. He saw the trusted-forwarder pattern, the relayer-infrastructure burden, and the per-contract _msgSender() opt-in cost from inside the standard. He saw what GSN v1 had cost integrators, and he could see what ERC-4337 was about to repeat at a larger scale.

The lesson he took from being inside both ERC-20 and ERC-2771: ERCs ship minimum interfaces deliberately, and the cost shows up as half-baked solutions stacked on top of each other. ERC-20 left receivers and metadata to the application layer; ERC-2771 left permissions and relayer infrastructure to integrators; ERC-4337 added bundlers and paymasters; EIP-7702 (Pectra, May 2025) patched the EOA-can't-become-a-smart-account gap from the protocol side; EIP-7851 — still a draft as of mid-2026 — aims to let a 7702-delegated EOA permanently disable its residual ECDSA authority. Each one fixes a real problem the previous one left open. None of them was designed to compose with the others.

So Vogelsteller and the LUKSO team designed LSPs as a coherent system from the bottom up. The account stack is four standards working together by design, not five layered patches catching each other's gaps:

• LSP0 ERC-725 Account — the contract account itself. It owns assets, executes calls, holds typed key/value storage. There is no EntryPoint singleton; the account contract IS the entry point. msg.sender at downstream targets is the account, natively.
• LSP6 Key Manager — the standardized permission vocabulary. AllowedCalls, AllowedStandards, AllowedERC725YDataKeys, value caps, granular bitfields, instant revocation. The piece that ERC-4337 and EIP-7702 deliberately leave to each wallet implementation, here as a shared standard every controller, app, and relayer can read.
• LSP20 Call Verification — inline call verification at the account contract layer. The equivalent of validateUserOp, but on the normal call path rather than through an EntryPoint hop.
• LSP25 Execute Relay Call — sponsored execution as a function on the account itself. A controller signs, a relayer submits, LSP6 permissions still gate what the signing controller may do. No bundler, no paymaster contract, no parallel mempool, no ERC2771Context mixin to inherit.

Pectra shipped. Why is the LSP stack still the better answer?

Ethereum's Pectra hard fork (May 2025) is real progress. EIP-7702 gives existing EOAs the ability to delegate execution to contract code in a single transaction, and EntryPoint v0.8 plugs that delegation into the ERC-4337 ecosystem natively. An EOA can now batch transactions, accept passkey signatures, and use gas sponsorship without redeploying. The major Pectra advantage over LUKSO is exactly that: it upgrades an existing Ethereum address without moving its assets, approvals, history, or identity to a newly deployed contract account.

That said — and this is the substantive comparison — even with Pectra, the LSP stack covers several things 7702 + 4337 don't, or covers them less coherently:

1. Authoritative recovery and key revocation. An EIP-7702 EOA gains smart-account semantics by delegating execution to contract code, but the original secp256k1 key never goes away. An attacker who compromises the original key can sign another 7702 authorization to replace the delegation and reset recovery. EIP-7851 is a draft that aims to let a 7702 account permanently disable its residual ECDSA authority — but as of mid-2026 it's still a draft, not part of Pectra. A Universal Profile has no hidden root key above its Key Manager; recovery is authoritative because there's nothing the recovered configuration can be overridden by. LSP11 standardises social recovery with guardians and a configurable voting threshold; LSP6 governs the permission to add, remove, or replace controllers.

2. A standardised permission vocabulary across the ecosystem. ERC-4337 delegates validation policy to each wallet implementation; EIP-7702 inherits that. The modular-account ecosystem (ERC-7579, ERC-6900) is converging on similar ideas as optional wallet-vendor layers. LSP6 makes the permission model part of the primary account stack — so wallets, apps, indexers, and tooling can inspect and manage permissions without learning every account vendor's custom module design.

3. A standardised on-chain identity and data store. Neither Pectra nor ERC-4337 defines where an account should keep profile metadata, application preferences, issued or received assets, or extension configuration. LUKSO uses ERC-725Y as a generic key-value store with LSP2 schemas and LSP3 profile keys, so the account is simultaneously a wallet, identity, profile, and application-data container. A 7702/4337 account can store all of these things — there's just no shared data model for them.

4. Safer ownership transitions. LSP14 Ownable 2-Step requires the current owner to nominate a new owner and the nominated owner to explicitly accept; renunciation includes a delay and confirmation. ERC-4337 and EIP-7702 don't define an equivalent lifecycle — each wallet implementation invents one, and the failure mode is "I clicked the wrong button and transferred ownership to a typo."

5. Predictable account initialisation and upgrades. EIP-7702 doesn't run deployment initcode when delegation is installed, so wallet developers have to protect initialisation against front-running. Switching between delegate implementations can produce storage collisions because the new implementation executes on the EOA's existing storage. Universal Profiles are deployed and initialised as contracts; LSP6 permissions live in the profile's ERC-725Y storage rather than inside the Key Manager, so the Key Manager can be replaced without discarding the permission configuration. LSP17 Contract Extension standardises the extension mechanism.

6. Standardised receiving and reaction hooks. Pectra and ERC-4337 address authorisation and execution; they don't define how an account learns about incoming assets or messages. LSP1 Universal Receiver is one entry point for structured notifications, with LSP5 and LSP10 standardising the records for received assets and vaults. A Universal Profile has the equivalent of an inbox, not just a balance.

7. Predictable account semantics. A 7702 account is a hybrid: it has code, it can still originate ECDSA transactions like an EOA, its code is only a pointer to another contract, and EIP-7702 itself notes that it breaks several historical EVM invariants — including code that assumes tx.origin == msg.sender. A Universal Profile is unambiguously a contract account: ERC-1271 signature validation, LSP20 call verification, and the LSP account interfaces all apply consistently.

Honest framing — what LUKSO does NOT uniquely solve

A pure ERC-4337 smart account can implement nearly all of these features. Transaction batching is account-level execution. Sponsored gas is a paymaster. Session keys are a custom validator. Multisig is account logic. Alternative signatures live inside the validator. Modular functionality has ERC-7579 and ERC-6900. And in some respects ERC-4337 ships a richer standardised gas market — bundlers and paymasters — than LSP25's straightforward relayer pattern.

So the LUKSO advantage isn't "Ethereum can't ship these features." It's a different one, four parts:

1. No irrevocable EOA root. A Universal Profile's address is not cryptographically tied to one permanent private key.
2. Recovery and controller replacement are authoritative. When a controller is removed or rotated, it actually loses authority — there's no parallel root key that can override the new configuration.
3. Permissions, identity, receiving hooks, and extensions are standardised across the account ecosystem. Apps, indexers, and wallets read one vocabulary, not per-vendor modules.
4. Hybrid-account and storage-migration complexities don't exist. A UP is a contract, deployed as a contract, upgraded as a contract — no 7702 storage collisions, no front-runnable initcode, no broken tx.origin assumptions.

The architectural difference, summarised:

7702 + 4337: permanent EOA root → programmable delegate → optional recovery, permissions, and modules (each wallet's call).

LUKSO Universal Profile: contract account root → replaceable Key Manager → standardised controllers, permissions, recovery, data, and extensions (one shared system).

LUKSO mainnet went live in 2023 with this stack as native standards rather than layered patterns. The practical takeaway: if an ERC-4337 plus EIP-7702 design is accumulating costs around residual EOA keys, validator fragmentation, EntryPoint and bundler infrastructure, and wallet-specific modules, Universal Profiles show the alternative shape: a contract account with standardized permissions, recovery, metadata, receiver hooks, and relay execution.