If you are coming to Tolk from FunC, your first instinct is usually to look for familiar reference points. Developers often ask where the TL-B equivalent of a construct lives, how to generate a TL-B schema from a Tolk structure, or where a block.tlb file should sit in a project.

That line of thinking makes sense in a FunC world, but it sends you in the wrong direction in Tolk. This is because Tolk's type system is designed as a replacement for TL‑B.

Tolk introduces a first-class type system that directly models messages, storage, and serialization. The type system replaces the role TL-B previously played in FunC-based contracts.

Why is TL-B so widely used in TON today?

TL‑B is deeply embedded in TON Ecosystem because of how FunC contracts are written. FunC is an imperative, low-level language. Contracts manually parse cells and slices, validate layouts at runtime, and enforce structure through code rather than declarations.

Because the contract code itself does not describe its inputs, messages, or storage declaratively, TL-B emerged as a compensating layer. It provided a formal description of what a contract requires: which inputs are valid, how data is structured, and how storage is organized.

Over time, TL-B effectively became the schema language for FunC contracts, used both by developers and by tooling to understand how a contract behaves. In a FunC world, this separation made sense. The code executed logic, while TL-B described the structure.

What changes in Tolk

Instead of describing structure outside the language, Tolk embeds it directly into the program. Messages and storage are defined as structs, and those definitions carry semantic meaning.

These structs define layout, typing, optionality, and how the data is serialized.

Serialization and deserialization follow directly from these type definitions. There is no separate schema to maintain, and no manual parsing logic to mirror the schema. The type system becomes the single source of truth.

In practical terms, a Tolk struct already does the job TL-B used to do.

Tooling built on the type system

Tolk's tooling is built around the type system, which enables workflows that TL‑B was never designed to power: ABI generation, TypeScript wrapper generation, source mapping, and debugger integration. These workflows operate directly on Tolk's type system, so TL-B does not participate in them.

Shared concepts and structural differences

At first glance, TL‑B and Tolk can feel familiar to each other. Both talk about fixed-width integers, bit fields, optional values, unions, constructors, and cells. This visual overlap is often what leads developers to assume that one can be mechanically translated into the other.

Despite these similarities, the systems diverge in important ways.

TL-B includes constructs designed for protocol-level descriptions, such as tilde modifiers, conditional expressions inside schemas, and dynamically sized bit fields. These features make sense when describing blockchain internals like blocks and messages at the protocol level.

Tolk, on the other hand, supports language-level features that TL-B was never meant to express. Type aliases, enums, inline unions with generated prefix trees, tensors, and custom serialization logic are all part of the language. Tolk also supports address? as "internal or none" (not "maybe T").

These differences reflect the fact that Tolk is a programming language with a static type system, while TL-B is a schema language for low-level data formats.

Where TL-B still fits

TL-B remains an excellent tool for describing TON's protocol internals. Files like block.tlb are a natural fit for TL-B's declarative style and expressive power at the binary format level.

Contract APIs, message formats, and interaction models are a different domain. In that space, Tolk's type system is the authoritative representation. All tooling around Tolk assumes typed contracts rather than external schemas, and future features build on that assumption.

If you are writing contract interfaces, defining message formats for dApps, or modeling storage layouts, the work happens in Tolk itself.

Connecting Tolk to serialization

If you want to connect the dots between Tolk types and TON's underlying serialization world, the TON docs page on Overall serialization walks through how each Tolk type relates to TL‑B-style representations. One thing to watch for there: you'll notice imperative serialization rules, which are fundamentally different from TL‑B's declarative schemas.

A shift in mindset

Moving from FunC to Tolk requires more than learning new syntax. It requires dropping the habit of translating schemas and instead thinking in terms of modeling data directly in the language.

In Tolk, the type system is the schema. Once that shift clicks, the rest of the ecosystem starts to make sense.