Build Token Economics on LUKSO
Token economics on LSP isn't a rebuild of ERC20 — it's the same balance-and-transfer model with everything you used to bolt on afterward baked in from the start. LSP7 Digital Asset ships transfer with LSP1 receiver hooks, operator authorization, and transfer context, paired with LSP4 for typed metadata under ERC725Y. Because token holders are Universal Profiles by default, distribution, airdrops, and holder-gated features integrate naturally with LSP3 identity, LSP5 received-assets tracking, and the LSP26 follower graph — instead of a balance sheet detached from who actually holds it.
The stack
| Standard | Role |
|---|---|
| LSP7 | Balances, transfers, operator authorization |
| LSP4 | Asset metadata under ERC725Y typed keys |
| LSP1 | Fires automatically on recipients you control (Universal Profile delegates handle this by default) |
| LSP6 | Controller-side permission scoping, when account-level authorization policy matters |
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 its metadata, an in-game currency that needs to notify vaults on deposit, or a membership asset where every transfer should fire a hook on the recipient's profile.
When the minimum-interface property is the actual design goal. ERC20 ships exactly balances, a transfer, an allowance pattern, and three metadata fields — no recipient call, no reentrancy surface on transfer, no force flag to decide on per integration. If a token's entire value proposition is that downstream code can integrate it with zero opinions about behavior beyond "moves balance, fires an event," ERC20 is the right interface, and the absence of an LSP1 hook is a feature rather than a gap.
Related reading: ERC20 vs LSP7 · The ERC20 approval problem · ERC20's missing transfer hooks · Migrate ERC20 to LSP7