Skip to main content
The purpose of this article is to explain common TL-B examples that you encounter when reading our standards.

​
NFT

The NFT collection and each NFT item are separate smart contracts in TON Blockchain. Each specific implementation must comply with the TEP 0062 standard. When reading this TEP, you encounter a TL-B schema that describes the serialization of a message that transfers the rights of a given NFT item to another user. 
transfer#5fcc3d14 query_id:uint64 new_owner:MsgAddress 
response_destination:MsgAddress custom_payload:(Maybe ^Cell) 
forward_amount:(VarUInteger 16) forward_payload:(Either Cell ^Cell) 
= InternalMsgBody;
Thus, a cell corresponds to this TL-B scheme if it sequentially contains:
  • 32-bits that represents the hexadecimal number 0x5fcc3d14.
  • An arbitrary request number that is an unsigned 64-bit integer in binary form.
  • An address of the new owner of the NFT item that is a sequence of bits corresponding to the MsgAddress TL-B scheme (see the address page for details).
  • An address where to send a response with confirmation of a successful transfer and the rest of the incoming message coins. It is serialized as the previous field.
  • Optional custom data. For the description how Maybe type works, see simple examples page.
  • The amount of nanotons to be sent to the new owner. For the explanation how VarUInteger n works, see simple examples page.
  • The optional custom data that should be sent to the new owner. For the description how Either type works, see simple examples page.
The knowledge gained from analyzing the TL-B schemes above is sufficient to understand all the schemes that you will encounter when analyzing the Jetton, NFT Royalty, SBT, Jetton wallet standards.

​
Jetton

It was mentioned above that an example of the TL-B scheme related to NFTs is sufficient to understand all schemes related to Jettons. However, as Jetton transactions are among the most common on the TON blockchain, we will analyze relevant schemes separately. A standard interface for Jettons (TON fungible tokens) is specified in TEP 0074. To transfer tokens from one wallet to another, it is required to send a message to the sender’s jetton-wallet corresponding to the following TL-B scheme. For the description how data types VarUInteger n, Maybe, and Either work, see simple examples page. 
transfer#0f8a7ea5 query_id:uint64 amount:(VarUInteger 16) destination:MsgAddress
                 response_destination:MsgAddress custom_payload:(Maybe ^Cell)
                 forward_ton_amount:(VarUInteger 16) forward_payload:(Either Cell ^Cell)
                 = InternalMsgBody;
Thus, a cell corresponds to this TL-B scheme if it sequentially contains:
  • 32-bits that represents the hexadecimal number 0x0f8a7ea5.
  • An arbitrary request number that is an unsigned 64-bit integer in binary form.
  • An amount of transferred jettons in elementary units.
  • An address of the new owner of jettons that is a sequence of bits corresponding to the MsgAddress TL-B scheme (see the address page for details).
  • An address where to send a response with confirmation of a successful transfer and the rest of the incoming message coins. It is serialized as the previous field.
  • Optional custom data.
  • The amount of nanotons to be sent to the new owner.
  • Optional custom data that should be sent to the destination address.
If forward_amount > 0, the receiver’s jetton-wallet should send a message to the destination address with forward_amount nanotons attached and with the following TL-B schema. 
transfer_notification#7362d09c query_id:uint64 amount:(VarUInteger 16)
                              sender:MsgAddress forward_payload:(Either Cell ^Cell)
                              = InternalMsgBody;
Thus, a cell corresponds to this TL-B scheme if it sequentially contains:
  • 32-bits that represents the hexadecimal number 0x7362d09c.
  • An arbitrary request number that is an unsigned 64-bit integer in binary form.
  • An amount of transferred jettons in elementary units.
  • An address of the previous owner of transferred jettons.
  • Optional custom data that should be sent to the destination address.
The rest of TL-B schemes corresponding to the Jettons can be examined in a similar way.

​
DNS

TON DNS is a service for translating human-readable domain names (such as test.ton or mysite.temp.ton) into TON smart contract addresses. It is specified in TEP 0081. Let’s consider TL-B schemes of DNS Records values: 
proto_http#4854 = Protocol;

proto_list_nil$0 = ProtoList;
proto_list_next$1 head:Protocol tail:ProtoList = ProtoList;


cap_is_wallet#2177 = SmcCapability;

cap_list_nil$0 = SmcCapList;
cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList;

dns_smc_address#9fd3 smc_addr:MsgAddressInt flags:(## 8) { flags <= 1 }
  cap_list:flags . 0?SmcCapList = DNSRecord;
dns_next_resolver#ba93 resolver:MsgAddressInt = DNSRecord;
dns_adnl_address#ad01 adnl_addr:bits256 flags:(## 8) { flags <= 1 }
  proto_list:flags . 0?ProtoList = DNSRecord;
dns_storage_address#7473 bag_id:bits256 = DNSRecord;

_ (HashmapE 256 ^DNSRecord) = DNS_RecordSet;
The first thing you need to pay attention to: how lists of arbitrary length are formed. For instance, ProtoList combinator consists of two constructors: proto_list_nil that indicates the end of a list and proto_list_next that indicates that there are a record of protocol followed by the next record or the end of a list. When deserializing data of the ProtoList type, the prefix 1 or 0 is read first. If the prefix is 0, then we have reached the end of the list and there is nothing more to read. Otherwise, the protocol entry is read, followed by a prefix indicating whether the next protocol entry will be followed or the end of the list. The same applies to the SmcCapList type. Next, pay attention to the DNSRecord type. The contructors dns_next_resolver and dns_storage_address are simple. Let’s deal with the dns_adnl_addressconstructor:
  • first comes the 0xad01 prefix;
  • then 256-bits representing ADNL address;
  • next, the 8-bits flag which is currently bounded by 1;
  • finally, if the first bit of the flag is 1, the serialization continued with ProtoList type;
  • if the first bit of the flag is 0, then serialization is completed.
The serialization of dns_smc_address follows the same logic.
⌘I