This topic is reserved for the TRC-7 Non-Fungible Tokens standard.
What is the difference with TIP-31 Non Fungible Tokens and their Collections ?
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 <firstname.lastname@example.org> Status: Draft Created: 2021-07-16
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
Standard also includes a way to create generative art distributor aka
Collection is not a wallet,
Collection aims only to group similar kinds of
Tokens . Think of it as artist’s collection.
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.
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
- 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;
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.
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
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.
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.
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
TODO (additional info here GitHub - SolderingArmor/liquid-nft)
Full specification can be found here: GitHub - SolderingArmor/liquid-nft
Specification includes README, STANDARD, interfaces and contract examples.
NFT standards are now reserved under TIP-4. The current TIP-4 will be moved to another sub category.