ERC-1155 vs LSP·7+8 Ethereum/EVM standard comparison
ERC-1155 packs many token types into one contract; LSP7 + LSP8 split the same surface by asset semantics. The boundary shows up in code — batch primitives, receiver dispatch, and per-id branching.
Spec diff.
| ERC-1155 | LSP·7+8 | |
|---|---|---|
| contracts per product | one | one per asset shape (often two) |
| fungibility signal | convention in token-id bits | in the standard (LSP7 vs LSP8) |
| transfer hook | IERC1155Receiver (single + batch) | LSP1 universalReceiver (one shape for both) |
| metadata | uri(id) → string | ERC-725Y + LSP4 keys, per-token via LSP8 |
| batch transfer | safeBatchTransferFrom | transferBatch on each standard |
| indexing cost | high — per-collection conventions | low — shape is in the standard |
The semantic boundary moves
ERC-1155 makes the boundary between fungible and identifiable a contract-internal convention. The high bits of a token id might encode “this id is fungible” or “this id is unique” — and that convention is per-collection. Wallets and indexers learn it the hard way.
LSP7 + LSP8 put the same boundary in the standard. If something is fungible, it lives on an LSP7 contract. If something is identifiable, it lives on an LSP8 contract. Marketplace UI branches on the interface ID, not on a token-id bit pattern.
Cost: more contracts to deploy
The honest tradeoff: where ERC-1155 ships one contract for a multi-asset product, LSP7 + LSP8 usually ships two. The deployment is a one-time gas cost; the integration savings are ongoing. For a game with stable item categories, the split usually pays off. For a stamp collection of 10,000 highly varied items, ERC-1155 may still be the right call.