TON Blockchain Architecture

TL;DR: TON stores all blockchain data as cells linked into trees or DAGs, groups accounts into independent accountchains, and aggregates them into shardchains coordinated by a single masterchain. Consistency conditions, logical time, and on‑chain configuration contracts ensure secure, deterministic operation.

Overview of the architecture#

TON’s architecture defines how data is stored, how it is sharded across the network, and how consensus is achieved. The system consists of three main layers:

Bag of Cells – the fundamental data unit, each cell holding up to 1023 bits of payload and up to four SHA‑256‑referenced links. Cells are serialized according to the TL‑B schema and arranged into trees or directed acyclic graphs (DAGs).
Infinite Sharding Paradigm (ISP) – every account lives in its own accountchain. Virtual blocks of these accountchains are batched into shardchain blocks for efficiency. A shardchain’s state aggregates the states of all its accounts.
Masterchain – a single, non‑splitting chain that stores the list of active shardchains, the latest block hashes of each shard, and configurable parameters via special smart contracts.

Bag of Cells in detail#

Each cell comprises two descriptor bytes, the payload data, and up to four links represented by SHA‑256 hashes. Cells are the only serialization format for blocks, blockchain states, and smart‑contract data, enabling compact and verifiable storage.

Shardchain structure#

A shardchain block is divided into non‑split and split parts.

Non‑split components

InMsgDescr – descriptions of all incoming messages.
OutMsgDescr – descriptions of all outgoing messages.
Block Header – hashes, timestamps, and other block parameters.
OutMsgQueue – queue of messages awaiting delivery to neighboring shardchains.

Split components

The split part stores a hashmap mapping each account identifier to its state, which includes:

Balance in Grams
Smart‑contract code
Persistent contract data
Storage usage statistics
Optional formal interface description
Public user information

Masterchain responsibilities#

The masterchain records the current set of active shards and the latest block of each shard. It also hosts configurable parameters—either simple values or smart contracts—that govern network operation, such as validator stake minimums, validator group size, and election processes. Initial values and core contract code are embedded in the genesis (block zero) of the masterchain.

Consistency (validity) conditions#

Validators must ensure that every block satisfies a set of conditions:

Global conditions – invariants that apply to the whole network (e.g., guaranteed message delivery).
Internal (local) conditions – checks applied within a single transaction (e.g., correct processing of incoming messages).
External (cross‑shard) conditions – constraints involving data from neighboring shardchains.

A block is considered valid only when all applicable conditions are met; otherwise it is rejected.

Logical time (LT)#

Logical time is a non‑negative 64‑bit integer assigned to events. An event that depends on others receives an LT greater than all its dependencies; independent events start with LT 0. Transactions inherit LT, and each block records the LT interval of its contained transactions and messages. This mechanism orders events without relying on a global clock.

Total blockchain state#

Every masterchain block lists all active shards and the latest block hash for each. Consequently, a masterchain block defines the total state of the TON network, fixing the state of every shardchain and the masterchain itself. Shardchain blocks reference the hash of the most recent masterchain block in their headers, ensuring visibility only to blocks that are “visible” through the masterchain’s list.

Configurable smart contracts#

Configuration parameters are stored in a dedicated smart contract on the masterchain. They include:

Minimum validator stake
Maximum validator group size
Maximum number of blocks a validator group may produce
Validator election and punishment processes
Current and next validator sets

These parameters can be updated through on‑chain governance mechanisms defined in the configuration contract.

Smart‑contract lifecycle#

Creation

Sending a value‑bearing message to an unused address creates an uninitialized account with a balance but no code or data.
A constructor message containing the initial code and data creates the smart contract, often supplying the initial balance required for storage fees.
Contracts can autonomously create other contracts during transaction execution.

Modification and removal

Persistent data changes when the contract’s code runs in the TON Virtual Machine (TVM).
Code can be altered only if the current code permits such changes.
A contract is destroyed when its balance drops to zero or below, typically after paying storage fees or transferring all funds.
If an account’s balance becomes negative or falls below the minimum, the account is frozen: its code and data are replaced by a 32‑byte hash, which can later be restored by transferring sufficient funds and sending a reconstruction message.