Messages
This section provides a detailed explanation of the TL-B schemes used for messages.
TL-B
The main TL-B scheme for messages is defined as a combination of several nested structures.
message$_ {X:Type} info:CommonMsgInfo
init:(Maybe (Either StateInit ^StateInit))
body:(Either X ^X) = Message X;
message$_ {X:Type} info:CommonMsgInfoRelaxed
init:(Maybe (Either StateInit ^StateInit))
body:(Either X ^X) = MessageRelaxed X;
_ (Message Any) = MessageAny;
Message X
refers to the standard message structure.MessageRelaxed X
is a variant that uses aCommonMsgInfoRelaxed
body.Message Any
is a union of both structures.
The message structure is unified using X:Type, which in this context represents a cell.
According to TL-B rules, all data can be stored within a single cell—if it fits within 1023 bits—or distributed across references using the caret symbol ^
.
A serialized Message X
is placed into the action list using the FunC method send_raw_message()
. The smart contract then executes this action, and the message is sent.
Definition of explicit serialization
To construct valid binary data according to a TL-B structure, serialization must be performed as defined recursively for each type. To serialize a Message X
, you must also know how to serialize nested structures like StateInit
, CommonMsgInfo
, etc.
Each nested structure is defined in a separate TL-B scheme, which must be referenced and resolved recursively. This continues until the serialization of the top-level structure becomes explicit—that is, every bit is defined by a boolean or a bit-representable type, e.g., bits
, uint
, varuint
.
Structures not commonly used in regular development are marked with an asterisk *
in the Type column. For example, *Anycast
is typically omitted during serialization.
message$_
This is the top-level TL-B scheme for messages, referred to as Message X
:
message$_ {X:Type} info:CommonMsgInfo
init:(Maybe (Either StateInit ^StateInit))
body:(Either X ^X) = Message X;
Structure | Type | Required | Description |
---|---|---|---|
message$_ | Constructor | Defined according to the constructor rule. The empty tag $_ indicates that no bits are added initially. | |
info | CommonMsgInfo | Required | Contains detailed message properties such as destination and value. It is always stored in the message's root cell. |
init | StateInit | Optional | The general structure is used in TON to initialize new contracts. It can be placed in either a cell reference or the root cell. |
body | X | Required | Message payload. It can be placed in either a cell reference or the root cell. |
nothing$0 {X:Type} = Maybe X;
just$1 {X:Type} value:X = Maybe X;
left$0 {X:Type} {Y:Type} value:X = Either X Y;
right$1 {X:Type} {Y:Type} value:Y = Either X Y;
Recall how Maybe
and Either
work—we can serialize different cases:
[CommonMsgInfo][10][StateInit][0][X]
- aMessage X
fully serialized into a single cell.


[CommonMsgInfo][11][^StateInit][1][^X]
- aMessage X
with references.


CommonMsgInfo TL-B
CommonMsgInfo
CommonMsgInfo
is a set of parameters that define how the message will be delivered on the TON blockchain.
//internal message
int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool
src:MsgAddressInt dest:MsgAddressInt
value:CurrencyCollection ihr_fee:Grams fwd_fee:Grams
created_lt:uint64 created_at:uint32 = CommonMsgInfo;
//external incoming message
ext_in_msg_info$10 src:MsgAddressExt dest:MsgAddressInt
import_fee:Grams = CommonMsgInfo;
//external outgoing message
ext_out_msg_info$11 src:MsgAddressInt dest:MsgAddressExt
created_lt:uint64 created_at:uint32 = CommonMsgInfo;
int_msg_info$0
int_msg_info
represents an internal message, meaning it can only be sent between smart contracts.
Use case: regular cross-contract communication within the TON blockchain.
nanograms$_ amount:(VarUInteger 16) = Grams;
//internal message
int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool
src:MsgAddressInt dest:MsgAddressInt
value:CurrencyCollection ihr_fee:Grams fwd_fee:Grams
created_lt:uint64 created_at:uint32 = CommonMsgInfo;
Structure | Type | Required | Description |
---|---|---|---|
int_msg_info$0 | Constructor | Required | The $0 tag indicates that the CommonMsgInfo begins with a 0 bit in serialization, denoting an internal message. |
ihr_disabled | Bool | Required | Flag indicating whether hypercube routing (IHR) is disabled. |
bounce | Bool | Required | Specifies whether the message should be bounced if an error occurs during processing. If set to 1 , the message is bounceable. |
bounced | Bool | Required | Indicates that the message is a result of a bounce. |
src | MsgAddressInt | Required | The sender's smart contract address. |
dest | MsgAddressInt | Required | The recipient's smart contract address. |
value | CurrencyCollection | Required | Describes the currency details, including the total funds transferred with the message. |
ihr_fee | VarUInteger 16 | Required | Fee for delivering the message using hypercube routing. |
fwd_fee | VarUInteger 16 | Required | Validators set the fee for forwarding the message. |
created_lt | uint64 | Required | Logic time of the message, used by validators to order actions in smart contracts. |
created_at | uint32 | Required | UNIX timestamp indicating when the message was created. |
ext_in_msg_info$10
ext_in_msg_info$10
– represents an external incoming message. This message is sent from the off-chain world to a smart contract.
Use case: a wallet application sending a request to a wallet contract.
nanograms$_ amount:(VarUInteger 16) = Grams;
//external incoming message
ext_in_msg_info$10 src:MsgAddressExt dest:MsgAddressInt
import_fee:Grams = CommonMsgInfo;
Structure | Type | Required | Description |
---|---|---|---|
ext_in_msg_info$10 | Constructor | Required | The $10 tag indicates that the CommonMsgInfo begins with 10 bits in serialization, denoting an external incoming message. |
src | MsgAddressExt | Required | The external sender’s address. |
dest | MsgAddressInt | Required | The destination smart contract address. |
import_fee | VarUInteger 16 | Required | The fee for executing and delivering the message. |
ext_out_msg_info$11
ext_out_msg_info$11
– represents an external outgoing message. This message is sent from a smart contract to the off-chain world.
Use case: logs.
//external outgoing message
ext_out_msg_info$11 src:MsgAddressInt dest:MsgAddressExt
created_lt:uint64 created_at:uint32 = CommonMsgInfo;
Structure | Type | Required | Description |
---|---|---|---|
ext_out_msg_info$11 | Constructor | Required | The $11 tag indicates that the CommonMsgInfo begins with 11 bits in serialization, denoting an external outgoing message. |
src | MsgAddressInt | Required | The sender’s smart contract address. |
dest | MsgAddressExt | Required | The external destination address for the message. |
created_lt | uint64 | Required | Logic times of the message, assigned by the validator. Used for ordering actions in the smart contract. |
created_at | uint32 | Required | UNIX timestamp representing when the message was created. |
StateInit TL-B
StateInit
– delivers initial data to a contract during its deployment.
_ split_depth:(Maybe (## 5)) special:(Maybe TickTock)
code:(Maybe ^Cell) data:(Maybe ^Cell)
library:(HashmapE 256 SimpleLib) = StateInit;
Structure | Type | Required | Description |
---|---|---|---|
split_depth | (## 5) | Optional | A parameter for high-load contracts that defines the behavior of splitting into multiple instances across different shards. Currently, StateInit is used without it. |
special | TickTock* | Optional | A structure used for invoking smart contracts in every new blockchain block. Available only in the MasterChain and not typically used in regular user contracts. |
code | Cell | Optional | The contract's serialized code. |
data | Cell | Optional | The initial data for the contract. |
library | HashmapE 256 SimpleLib* | Optional | Currently, StateInit is used without libraries. |
General detailed explanations for Hashmaps.
MsgAddressExt TL-B
addr_none$00 = MsgAddressExt;
addr_extern$01 len:(## 9) external_address:(bits len)
= MsgAddressExt;
MsgAddress
is a scheme for various serializations of addresses. The structure depends on the participant, either off-chain or a smart contract, sending the message. Different structures are employed based on whether the message comes from an off-chain participant or a smart contract.