# TEP TL-B examples (https://docs-i0yym09dy-ton-core-docs.vercel.app/llms/foundations/tlb/tep-examples/content.md)



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

## NFT [#nft]

The [NFT collection and each NFT item](/llms/standard/tokens/nft/overview/content.md) are separate smart contracts in TON Blockchain. Each specific implementation must
comply with the [TEP 0062](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md) 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.

```tlb
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](/llms/foundations/addresses/overview/content.md) 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 of how the `Maybe` type works,
  see [simple examples page](/llms/languages/tl-b/simple-examples/content.md).
* The amount of nanotons to be sent to the new owner. For the explanation of how `VarUInteger n` works, see
  [simple examples page](/llms/languages/tl-b/simple-examples/content.md).
* The optional custom data that should be sent to the new owner. For the description of how the `Either` type works,
  see [simple examples page](/llms/languages/tl-b/simple-examples/content.md).

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](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md#summary),
[NFT Royalty](https://github.com/ton-blockchain/TEPs/blob/master/text/0066-nft-royalty-standard.md),
[SBT](https://github.com/ton-blockchain/TEPs/blob/master/text/0085-sbt-standard.md),
[Jetton wallet](https://github.com/ton-blockchain/TEPs/blob/master/text/0089-jetton-wallet-discovery.md) standards.

## Jetton [#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](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md).

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 of how data types `VarUInteger n`, `Maybe`, and `Either` work, see
[simple examples page](/llms/languages/tl-b/simple-examples/content.md).

```tlb
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, which is a sequence of bits corresponding to the
  `MsgAddress` TL-B scheme (see the [address](/llms/foundations/addresses/overview/content.md) page for details).
* An address to which 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.

```tlb
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 represent 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 the TL-B schemes corresponding to the Jettons can be examined in a similar way.

## DNS [#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](https://github.com/ton-blockchain/TEPs/blob/master/text/0081-dns-standard.md).

Let's consider TL-B schemes of *DNS Records* values:

```tlb
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 is 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 constructors `dns_next_resolver` and `dns_storage_address` are simple.
Let's deal with the `dns_adnl_address`constructor:

* first comes the `0xad01` prefix;
* then 256 bits representing ADNL address;
* next, the 8-bit 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.