Jettons mini-metadata standart

[cryshado]

Summary

I would like to propose a jettons metadata standard that describes the content structure(in TL-B) and get methods of the root token contract (minter). This standard describes how you can save the necessary data, occupying the smallest possible bit size.

Motivation

The current Fungible tokens (Jettons) standard offers the use NFT Data Standard for jetton_content cell. Unfortunately, different variations of on-chain in this standard take up a lot of space, and completely off-chain storage can't ensure proper preservation of data. In the TON blockchain, we pay storage fee for every bit, so we have to take the data size seriously.

Specification

field	description
*symbol_size	uint byte size of future ASCII string (max value is 2^3-1, i.e. 7)
*symbol	ASCII string, token symbol, max value:56 bit (i.e. 7 bytes ---> ↑)
*name_size	uint byte size of future ASCII string (max value is 2^4-1, i.e. 15)
*name	ASCII string, token name, max value:120 bit (i.e. 15 bytes ---> ↑)
icon_uri	an ASCII string link to the token icon, for example an ipfs url max recommended value: 1023 (3+4+56+120) (i.e. 840 bit, 105 bytes); may take more space if symbol and name < (56+120) bit (i.e. < 176 bit)

Note: fields marked with * are required.

TL-B scheme:

mini_data$11 symbol_size:uint3 symbol:bits
    name_size:uint4 name:bits icon_uri:bits = Content;

The constructor does not use values with a size of 1 byte. It makes absolutely no sense. In this case, the constructor is $11. The constructor is necessary so that when deserializing data, it can be understood by what standard we have recorded the Jetton data.

Minter token_info get method must to return symbol and name in integer representation, as well icon_uri as slice:

(int {- symbol -}, int {- name -}, slice {- icon_uri -}) token_metadata() method_id {
    ...
}

[EmelyanenkoK]

1. While indeed we pay storage fee for every bit and gas for every computational step on-chain, get_methods run off-chain. There is no reason to not store metadata in any compact predefined form in contract and then just render it to NFT Data standard On-chain content layout in get_method (note that rules of rendering can be stored in collection only).
2. If, for some reason, we strongly oppose excessive computation in get_methods, extension of NFT Data standard with mini on-chain form (with tag 0x03) seems more suitable than creation of new standard.

So from first glance separate standard for mini-metadata looks excessive itself, but probably i missed some nuance?

[cryshado]

@EmelyanenkoK Thanks for the quick response. For example, NFT Data Standard does not provide the ability to set symbol, only the name field is allowed. Usually symbol and name are split when creating fungible tokens. I think a good solution would be to make a get method that unpacks the data from the cell itself.

We have several ways in creating, a new standard/sub-standard that I can see:

• use tag 0x03, don't add a new get method(use get_jetton_data from TIPs 74)
• adding a new get method, constructor $11, new branch of standards
• amending TIPs 74: 2 bits tag, get method parsing data(or a set of get methods, such as owner, name, symbol, total_supply e.t.c , as in EIP-20 (ERC-20))

The first option is the easiest, the others require more complex compatibility changes. I ask for the community's opinion on this, so that we can decide as early as possible which way we should go. After that I can prepare a new description of the future standard(or sub-standard).

[purp1le]

I think 1 way is better:
use tag 0x03, don't add a new get method(use get_jetton_data from TIPs 74)
This will introduce compatibility for contracts that have been deployed before. And contracts will not need to add extra code for compatibility for both standards

[tolya-yanot]

#64 updated