Skip to content
This repository was archived by the owner on Sep 5, 2022. It is now read-only.
This repository was archived by the owner on Sep 5, 2022. It is now read-only.

Token Data Standard #64

@EmelyanenkoK

Description

@EmelyanenkoK

⚠️ WARNING: Standards are now published and discussed in the TEPs repository. This page may be out of date.

Summary

A standard interface for tokens (meta)data (in particular NFT or Jettons).

Motivation

For applications like wallets or marketplaces it is quite useful to be able automatically retrieve information for display. Token data standard allows to simplify this process and uniform the way of token display across different applications.

Specification

Content representation

Three options can be used:

  1. Off-chain content layout

    The first byte is 0x01 and the rest is the URI pointing to the JSON document containing the token metadata. The URI is encoded as ASCII.

    If the URI does not fit into one cell, then it uses the "Snake format" described in the "Data serialization" paragraph, the snake-format-prefix 0x00 is dropped.

  2. On-chain content layout

    The first byte is 0x00 and the rest is key/value dictionary.

    Key is sha256 hash of string.

    Value is data encoded as described in "Data serialization" paragraph.

  3. Semi-chain content layout

    Data encoded as described in "2. On-chain content layout".

    The dictionary must have uri key with a value containing the URI pointing to the JSON document with token metadata.

    Clients in this case should merge the keys of the on-chain dictionary and off-chain JSON doc.

Data serialization

Data that does not fit in one cell can be stored in two ways:

  1. Snake format when we store part of the data in a cell and the rest of the data in the first child cell (and so recursively).

    Must be prefixed with 0x00 byte.

    TL-B scheme:

    tail#_ {bn:#} b:(bits bn) = SnakeData ~0;
    cons#_ {bn:#} {n:#} b:(bits bn) next:^(SnakeData ~n) = SnakeData ~(n + 1);
    
  2. Chunked format when we store data in dictionary chunk_index -> chunk.

    Must be prefixed with 0x01 byte.

    TL-B scheme:

     chunked_data#_ data:(HashMapE 32 ^(SnakeData ~0)) = ChunkedData;
    

Data that fits into one cell is stored in "Snake format".

Informal TL-B scheme:

text#_ {n:#} data:(SnakeData ~n) = Text;
snake#00 data:(SnakeData ~n) = ContentData;
chunks#01 data:ChunkedData = ContentData;
onchain#00 data:(HashMapE 256 ^ContentData) = FullContent;
offchain#01 uri:Text = FullContent;

Note, that while TL-B scheme does not constrain bit size of each chunk it is expected that all chunks contain ceil number of bytes.

NFT metadata attributes

  1. uri - Optional. Used by "Semi-chain content layout". ASCII string. A URI pointing to JSON document with metadata.
  2. name - Optional. UTF8 string. Identifies the asset.
  3. description - Optional. UTF8 string. Describes the asset.
  4. image - Optional. ASCII string. A URI pointing to a resource with mime type image.
  5. image_data - Optional. Either binary representation of the image for onchain layout or base64 for offchain layout.

Jetton metadata attributes

  1. uri - Optional. Used by "Semi-chain content layout". ASCII string. A URI pointing to JSON document with metadata.
  2. name - Optional. UTF8 string. The name of the token - e.g. "Example Coin".
  3. description - Optional. UTF8 string. Describes the token - e.g. "This is an example jetton for the TON network".
  4. image - Optional. ASCII string. A URI pointing to a jetton icon with mime type image.
  5. image_data - Optional. Either binary representation of the image for onchain layout or base64 for offchain layout.
  6. symbol - Optional. UTF8 string. The symbol of the token - e.g. "XMPL". Used in the form "You received 99 XMPL".
  7. decimals - Optional. If not specified, 9 is used by default. UTF8 encoded string with number from 0 to 255. The number of decimals the token uses - e.g. 8, means to divide the token amount by 100000000 to get its user representation, while 0 means that tokens are indivisible: user representation of token number should correspond to token amount in wallet-contract storage.
    In case you specify decimals, it is highly recommended that you specify this parameter on-chain and that the smart contract code ensures that this parameter is immutable.

Changelog:

  • 14 May 2022 - the standard is now used not only for NFT, but for all tokens in the TON. Added section "Jetton metadata attributes".

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions