ERC-2535 vs LSP17 Ethereum/EVM standard comparison
Both let a contract grow new functions after deployment. Diamonds use a delegatecall router with shared storage; LSP17 uses a fallback router with per-selector extension contracts and ERC-725Y registration.
Both standards let a contract grow new functions after deployment. ERC-2535 Diamonds route via delegatecall to per-function facet contracts registered under a shared storage layout; upgrade authority is admin-controlled and the storage-layout discipline is famously error-prone. LSP17 on LUKSO routes via a fallback function to per-selector extension contracts, with the extension registration stored under ERC-725Y keys. Each extension has its own storage; upgrades happen by re-registering the key, gated by LSP6 permissions instead of a diamond-cut owner role.
Spec diff.
| ERC-2535 | LSP17 | |
|---|---|---|
| extension mechanism | delegatecall to facet by selector | CALL (or DELEGATECALL) to extension by selector |
| storage | shared with facets (layout discipline required) | extension keeps its own (CALL flavor) |
| registration | diamondCut by owner | ERC-725Y setData (permissioned by LSP6) |
| upgrade authority over base bytecode | diamond owner can replace facets | none — base is immutable, extensions are additive |
| permissioning | single diamondCut function — gated by an owner / role | per-selector setData on ERC-725Y — granular grants per extension |
Same problem, different metaphors
Diamonds make the base contract a router. Every call goes through delegatecall to a
facet that shares the diamond’s storage. Adding behavior is diamondCut. Upgrading is
diamondCut. The upgrade authority is permanent and routine.
LSP17 makes unknown function calls the router. Known functions execute as base bytecode.
Unknown function selectors hit the fallback, which looks up an extension contract registered
in ERC-725Y. Adding behavior is setData (gated by LSP6 in a Universal Profile). The base
bytecode is never replaced.
When the difference matters
For a token protocol that needs to fix bugs in the base contract, diamonds give you the upgrade lever — and your users live with the upgrade authority. LSP17 doesn’t give you that lever, which is the point: if the base is wrong, the base is wrong forever, and the extension surface compensates by being additive.
For account contracts, LSP17 is the better fit. A Universal Profile that adds a new signature verifier or a new asset receiver does it by registering an LSP17 extension. No upgrade key over the account itself. No diamond storage layout to manage.