Tolk vs TL-B

Experienced developers coming from FunC tend to ask questions like:

• "What's the analogue of XXX in TL-B?"
• "How do I generate a TL-B schema for a Tolk structure?"
• etc.

Such questions lead in the wrong direction — because the Tolk type system is designed as a replacement for TL-B in smart contracts. There is no need to "provide a TL-B schema for a contract". Every Tolk struct is already a schema.

Why TL-B

TL-B is widely used in TON because contracts written in FunC are not declarative. They are low-level imperative programs that manually parse cells and slices.

TL-B exists to compensate for this — to provide a declarative description:

• which inputs are valid,
• what shape is expected,
• how storage is structured, etc.

TL-B is excellent for describing blockchain internals like block.tlb — but not for contract APIs or interaction models. All tooling around Tolk will not involve TL-B.

Why Tolk

In Tolk, messages and storage are described directly in structs. This description is exactly what TL-B used to provide, except that in Tolk it is serialized automatically.

Type system differences

The type systems of TL-B and Tolk are not equivalent, even if they look similar at first glance.

Similarities include:

• intN, uintN, bitsN
• Maybe (nullable), Either (a two-component union)
• multiple constructors (declared structs + prefixes + unions)
• cells and typed cells

But the differences are essential.

TL-B supports the following, which is not expressible in Tolk:

• ~tilde
• {conditions}
• dynamic ## n

Tolk supports the following, which is not expressible in TL-B:

• type aliases
• enums
• inline unions (autogenerated prefix trees)
• tensors
• custom packToBuilder and unpackFromSlice
• address? as "internal or none" (not "maybe T")
• other language improvements, such as namespaces or modules

The page Overall serialization describes how each Tolk type relates to TL-B. Notice the presence of imperative serialization rules there, which is fundamentally different from declarative TL-B schemas.