Build token economics with LUKSO LSPs on EVM
Token economics on LSP isn’t a rebuild of ERC-20 — it’s the same balance/transfer model with the things you used to bolt on (receiver hooks, transfer context, structured metadata, scoped operators) baked in.
When this vertical fits
You’re shipping a fungible asset that participates in app or profile UX: a creator coin, a governance token with proposal links in metadata, an in-game currency that needs to notify vaults on deposit, a membership asset where every transfer should fire a hook on the recipient profile.
When ERC-20 is still the right call
When the minimum-interface property is the design goal. ERC-20 ships exactly: balances, a transfer, an allowance pattern, three metadata fields. No recipient call, no reentrancy surface on transfer, no force flag to decide on per integration. If your token’s value is that downstream code can integrate it with zero opinions about behavior beyond “moves balance, fires an event,” ERC-20 is the right interface — and the absence of an LSP1 hook is a feature, not a gap.
The minimum stack
- LSP7 for balances, transfers, operators
- LSP4 for asset metadata under ERC-725Y keys
- ERC-725Y as the substrate (already part of LSP7)
- LSP1 on recipients you control (Universal Profile delegates handle this by default)
- LSP6 on the controller side when an account permission story matters
Reading list.
A curated path — problem → standard → migration.
- [ 01 ] problem The approval problem
- [ 02 ] problem The transfer-hook problem
- [ 03 ] LSP·7 Digital Asset — the spec
- [ 04 ] compare ERC-20 vs LSP7
- [ 05 ] migrate Migrate ERC-20 → LSP7