This topic is reserved for the TRC-7 Non-Fungible Tokens standard.
Main differences will be versatile media storage (including external or on-chain) and the concept of having “one NFT = one contract” design.
I will post the details when I finish writing the draft.
Shouldn’t TIPs have sequential ids? Why we already had TIP-31 and new TIP is #9?
This is because we didn’t have an agreement on the naming convention. Now we have it: all standard extensions should be published in format TIP-<NUMBER OF THE ORIGINAL STANDARD>/<EXTENSION NUMBER>, e.g. TIP-3/1.
I already asked everyone to refactor their proposals so that the numeration follows this convention.
TIP: 7
Type: TRC
Title: TRC-7 NFT Standard
Author: Anton Platonov <[email protected]>
Status: Draft
Created: 2021-07-16
Simple Summary
A standard interface for non-fungible tokens.
Standard covers a Token , single contract with internal or external media and a Collection , a Token creator (but not owner) and a logical pattern/specification to group Tokens .
Standard also includes a way to create generative art distributor aka Distributor .
NOTE: Collection is not a wallet, Collection aims only to group similar kinds of Tokens . Think of it as artist’s collection.
Abstract
The following standard allows for the implementation of a standard API for non-fungible tokens within smart contracts. This standard provides basic functionality to transfer and manage tokens.
Motivation
A standard interface allows any tokens on Everscale blockchain to be re-used by other applications: from wallets to marketplaces. Comparing to TIP-3 NFT TRC-7:
- Includes all common core functionality for managing
Tokens; - Doesn’t require standard update to include small changes (if the changes can be applied to JSON metadata string);
- Respects asynchronous nature of Everscale blockchain (includes callbacks and callback getters);
- Covers only one type of Token instead of 4;
- Respects distributed programming paradigm, i.e.
one Token = one Contract; - Can have only internal owners (addresses);
- Doesn’t require the owner to worry about Token balances;
Features
Internal Ownership
Designed to be distributed, TIP-7 presents a very important restrictions. User doesn’t directly interacts TIP-7 Token from “nowhere”. As in Ethereum each TIP-7 Token has concrete specified owner address. This is a multisig wallet address. It means that user only interacts with his own multisig wallet and all TIP-7 token management stuff is hidden between multisig and TIP-7 contracts.
Closed Gas Chain
As all other token wallet management stuff is hidden from direct interaction with user, the same happens with Gas management. You don’t need to check Token or Collection balance, neither you need to explicitly add any balance to them. They. Just. Work. It is made possible by combination of raw reserve flags, minimal balance and a strong requirement of returning all extra gas after all operations made in TIP-7 environment.
Cheap Storage
The size of of both Root and Wallet TVCs do not exceed 5Kb. It’s an outstanding result that became possible because all optimizations that were described before not only made TIP-7 more simple and usable, but also reduced the size of contracts.
Extendable
Storing an asset is a part of JSON metadata string, it can have any arbitrary information and fields and it doesn’t require standard update. It also means that any type or format of an asset can be stored in the Token.
Creator information
TODO
Printable Tokens
TODO (additional info here GitHub - SolderingArmor/liquid-nft)
Specification
Full specification can be found here: GitHub - SolderingArmor/liquid-nft
Specification includes README, STANDARD, interfaces and contract examples.
2 Likes
NFT standards are now reserved under TIP-4. The current TIP-4 will be moved to another sub category.