ERC-2535 vs LSP·17 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.
Spec diff.
| ERC-2535 | LSP·17 | |
|---|---|---|
| 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.