ERC-4337 vs LSP0+LSP6+LSP20+LSP25 Ethereum/EVM standard comparison
ERC-4337 puts account abstraction on top of EOAs via a parallel mempool, EntryPoint, and bundlers. The LSP stack puts the account contract on the normal call path, with permissions and relay execution as composed standards.
ERC-4337 puts account abstraction on top of the Ethereum protocol via a parallel UserOperation mempool, an EntryPoint singleton, bundlers, and paymaster contracts — the design deliberately avoided protocol changes. The LUKSO LSP stack puts an account contract (LSP0 ERC-725 Account) on the normal L1 call path, with LSP6 as the standardized permission vocabulary, LSP20 for inline call verification, and LSP25 for relay execution. The two are structurally different bets: ERC-4337 optimizes for compatibility with existing EOAs; the LSP stack is substrate-level account-native.
Spec diff.
| ERC-4337 | LSP0+LSP6+LSP20+LSP25 | |
|---|---|---|
| transaction flow | user → UserOp pool → bundler → EntryPoint → account | user (controller) → account contract |
| permission layer | validator module (per-account) | LSP6 Key Manager (standardized) |
| gas sponsorship | paymaster (separate contract) | LSP25 executeRelayCall (on the account) |
| signature verification | validateUserOp on the account | LSP20 lsp20VerifyCall inline |
| explorer experience | shows handleOps + UserOp decode | shows the call as itself |
| trace / debug surface | appears as handleOps → EntryPoint → account (extra hops) | appears as a direct call into the account contract |
| permission vocabulary | per-account validator modules — non-standard across accounts | LSP6 permission bitfield + AllowedCalls + AllowedERC725YDataKeys — uniform |
Two answers to the same question
Both stacks deliver “smart account UX”: fine-grained permissions, sponsored execution, account-level signature verification. They differ on where that work happens.
ERC-4337 ships account abstraction over a chain whose primitive is the EOA. The cost is a parallel infrastructure (UserOperation pool, bundlers, EntryPoint, paymasters) sitting beside the normal transaction flow. The benefit is portability — the same account model works anywhere EntryPoint is deployed.
The LSP stack puts the account contract on the regular call path. There’s no UserOperation, no EntryPoint, no bundler — the controller calls the account, LSP20 inline-verifies via LSP6, the call executes. Gasless flows go through LSP25 on the account itself, not through a separate paymaster contract.
Which model fits the product
If your product needs account abstraction that’s decoupled from the underlying account contract — pluggable validator modules per account, a separate aggregation/sponsorship plane, the option to mix-and-match validators per UserOp — ERC-4337’s parallel infrastructure is the mechanism. The cost is the extra hops in every trace and the non-standard permission shape each validator defines.
If your product needs the account itself to be the call entry point — so downstream contracts
see the account as msg.sender, permissions live in a standard on-chain vocabulary, and
sponsored execution is a function on the account contract rather than a separate paymaster —
the LSP stack is the mechanism. The cost is that account behavior is fixed by the contract;
adding new authorization shapes means extending through LSP17, not swapping a validator.