ERC-4337 vs LSP·0+6+20+25 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.
Spec diff.
| ERC-4337 | LSP·0+6+20+25 | |
|---|---|---|
| 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.