TIP-7 - Non-Fungible Tokens standard

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 <anton@platonov.us>
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.