LUKSO LSP7 Digital Asset Standard
Fungible and semi-fungible tokens, with native receiver hooks and operator authorization.
function balanceOf(address tokenOwner) external view returns (uint256);
function transfer(
address from,
address to,
uint256 amount,
bool force,
bytes calldata data
) external;
function authorizeOperator(
address operator,
uint256 amount,
bytes calldata operatorNotificationData
) external;
function revokeOperator(
address operator,
bytes calldata operatorNotificationData
) external;
LSP7 is what ERC-20 would look like if it had been designed with receiver awareness and
account integration from day one. Every transfer carries data, every transfer calls
universalReceiver on both sides, every operator authorization fires a typed event, and
every asset’s metadata lives in ERC-725Y under LSP4 keys.
The force parameter is the small detail with the biggest behavior shift: pass false and a
recipient that doesn’t implement LSP1 will revert (no more stranded balances); pass true
and you’ve consciously decided to bypass the check. Either way it’s a decision you made,
not a side effect of which transfer variant the caller picked.
What it solves.
What it does not solve.
Anti-overselling is a feature.
- LSP7 operators are still amount-scoped — that's honest, it's not magic. Real scope discipline comes from pairing with LSP6 on the controller side.
- Publishes distinct function selectors from ERC-20. Contracts that ABI-check for ERC-20 won't dispatch to LSP7 — by design, not as a workaround.
- Brings recipient-side code execution on transfer (LSP1). Apply standard reentrancy guards. ERC-20's no-recipient-call model gave that to you for free.
- Doesn't auto-prevent stranding for non-LSP1 recipients. The `force` flag is *your* decision per call.
Companions.
Standards this composes with.