Skip to main content

Tokens & NFT 2.0

Useful Tip

The guide section will walk you through creating and deploying an LSP7 token or an LSP8 NFT on the L14 test network.

Check the profile explorer to browse the deployed digital assets.

info

The @lukso/lsp-smart-contracts repository on GitHub contains implementations of LSP7 and LSP8 that are backward compatible with ERC20 and ERC721. But it is highly recommended to use the native ones.

Tokens & NFT 2.0 is a collective name for the new token and NFT standards LSP7-DigitalAsset and LSP8-IdentifiableDigitalAsset. These replace ERC20 and ERC721, which you would usually use on Ethereum.

The interfaces used to interact with these standards are inspired by EIP1155, a Multi-Token standard for multiple token types (fungible, non-fungible, or other configurations).

One of the main questions about NFT 2.0 is which characteristics make them the next generation of digital assets on the blockchain.

How different are they compared to traditional ERC20 tokens / ERC721 NFTs?

LSP7 and LSP7 diagram

How Tokens & NFT 2.0 are different?

Unlimited Metadata

info

See the LSP4 - Digital Asset Metadata standard for more information.

The existing tokens and NFTs standards do not offer a standard way to attach information to the contracts themselves. Such information (= metadata) is crucial to make each token or NFT descriptive and customized.

Consider the current ERC20 and ERC721 standards as an example. These standards only define a name, symbol, and tokenURI. But how about if we would like to attach more specific data to the asset? (e.g., icon, asset creator(s), token utility or motive, community behind it).

The Tokens and NFT 2.0 Standards solve this problem by using ERC725Y as a backbone. ERC725Y enables smart contracts to have very flexible and extensible storage. With ERC725Y, any information or metadata can be attached to the token or NFT.

Safer transfers

Tokens and NFT 2.0 introduce a new force parameter (default: FALSE). The intention behind it is to prevent transfers that can result in assets being lost forever.

Examples:

  • Accidental transfers: pasting the wrong recipient address or making a typo due to input mistakes.
  • Unsafe transfers: sending assets to unwanted or untrusted addresses.

In the LUKSO ecosystem, the force parameter restricts transfer to Externally Owned Accounts (EOA) or contracts that do not implement the LSP1 - Universal Receiver standard. The reason behind it is that contracts not implementing the universalReceiver(...) functionality might not be able to register or transfer these assets after receiving them.

Digital asset transfer force = FALSE

Digital asset transfer force = TRUE

References