Foundations of blockchain

This section covers the core concepts that underlie how transactions work in TON. You'll learn how accounts and smart contracts interact, how messages trigger asynchronous transactions, and how TON’s multi-chain layout records those transactions.

Execution model

Actor

An actor is an abstract behavioral model, formalized as a computational object that reacts to incoming messages, changes its internal state, creates new actors, and sends messages to others. Actors are isolated: they do not have access to each other’s state and interact only through message passing.

In other words:

An actor is an independent entity with its state and behavior. Actors interact by exchanging messages. Each actor can:

• change its state
• send messages to other actors
• spawn new actors

Actor model

The actor model is a model of concurrent computation in which a system is described as a collection of actors that interact through message passing.

Key properties of the model:

• actor isolation
• asynchronous communication
• any computational abstraction can be implemented as an actor

The model is used to precisely describe and analyze distributed systems. For example:

• Email can be modelled as an actor system: users are represented as actors and email addresses serve as actor addresses.
• Web services with endpoints (e.g., SOAP) can be interpreted as actors that handle messages sent to their addresses.

Account

An account in TON is an actor characterized by the following components:

• Account properties — common properties of any account: ID, balance, status, and last transaction (last_tx)
• Data — user defined data
• Code — custom logic defining the account's behavior

The general state fully defines all account types in TON. Examples:

• (ID1, 0 TON, unexist)
• (ID2, 10 TON, uninit, last_tx)
• (ID3, -0.5 TON, frozen)

Smart contract

A smart contract is an account whose code and data are already deployed to the blockchain in addition to its general state.

Difference between an account and a smart contract

• An account is an actor that has a general state — such as balance, address, and status — and may optionally include code and data.

Example: (ID1, 0 TON, unexist) or (ID2, 2 TON, inited, last_tx, data, code)

• A smart contract is an actor with deployed code and data that define its specific behavior.

Example: (ID2, 2 TON, inited, data, code)

Entity structure in TON Blockchain

Asynchrony

In TON, contracts or actors do not call each other directly. Instead, they communicate by sending messages, each of which is processed independently of the others. All interaction happens through asynchronous message passing.

Asynchrony is a property of communication, meaning that a message does not need to be processed immediately. This implies the following:

1. Immediate responses are not guaranteed. The receiver may delay responding or may not respond at all.
2. Senders remain non-blocking. After sending a message, an actor continues handling other messages or tasks without blocking or waiting for a response to the previous one—even if that response never arrives.
3. Message ordering is preserved per destination account. Each account processes incoming messages in the order they are received. If a message is malformed or incomplete, it is skipped, and the following message is processed without delay.

This is different from synchronous models, where the flow is: call → wait for a response → continue. In TON, a result can only be received as a separate message — and only if it is explicitly sent.

Message feature

A message is a set of instructions intended for a single actor. In TON Blockchain, it serves as the fundamental unit of interaction between accounts. All logic execution, state changes, and contract-to-contract communication are initiated by messages.

Transaction feature

In TON, a transaction is a record of an account's state update caused by processing an incoming message. If the message does not result in an update — for example, due to an error in the compute phase — no transaction is created.

Depending on the contract logic, a transaction may also produce one or more outgoing messages.

Asynchronous transactions

In TON, accounts interact exclusively through messages — this is the core of actor-based communication. Each successfully processed message results in a transaction, which records the entire context: the triggering message, state updates, and any generated outbound messages.

Transactions are processed asynchronously, meaning that each account’s updates and message handling occur independently over time.

Data layout

Account structure

Earlier, we mentioned that an account is an actor defined by the following components:

• Account properties (ID, balance, status, last_tx)
• Data
• Code

In practice, the actual data layout is more complex, but the logical distinction between an account and a smart contract remains the same. To describe data structures, in TON, TL-B schemas are used. These define how data is laid out at the bit level.

Let’s take a look at how an account is defined. The account structure consists of several nested objects:

account_none$0 = Account;
account$1 addr:MsgAddressInt storage_stat:StorageInfo
          storage:AccountStorage = Account;

• Address — MsgAddressInt
• Balance — CurrencyCollection
• State — AccountState, which defines the account’s behavior
• Logical time of the account's last applied transaction — last_trans_lt
• Storage statistics — StorageInfo

Details

account_none$0 = Account;
account$1 addr:MsgAddressInt storage_stat:StorageInfo
storage:AccountStorage = Account;

account_storage$_ last_trans_lt:uint64
balance:CurrencyCollection state:AccountState
= AccountStorage;

account_uninit$00 = AccountState;
account_active$1 _:StateInit = AccountState;
account_frozen$01 state_hash:bits256 = AccountState;

acc_state_uninit$00 = AccountStatus;
acc_state_frozen$01 = AccountStatus;
acc_state_active$10 = AccountStatus;
acc_state_nonexist$11 = AccountStatus;


_ fixed_prefix_length:(Maybe (## 5)) special:(Maybe TickTock)
code:(Maybe ^Cell) data:(Maybe ^Cell)
library:(Maybe ^Cell) = StateInit;

Let’s clarify which properties are part of the account properties, according to the TL-B schema:

• ID → MsgAddressInt
• Balance → CurrencyCollection
• Status → AccountState
• Last transaction logical time (last_trans_lt) — also part of the general state

Meanwhile, the data and code are defined within the state: AccountState field.

Now, let’s take a closer look at the account properties and how it’s represented in the data layout.

Account status

TON defines account states AccountState as follows:

Status	TL-B code	Description
uninit	00	The account exists but contains no code or data. It may hold a non-zero balance but is not initialized yet.
frozen	01	The account is frozen: its code and data are deleted, but a hash of the previous state is retained. It can't be used, but it can be restored. The account has zero or negative balance, or doesn't meet the workchain’s minimum requirement.
active	10	The account includes a StateInit, which stands for State Initialized, with deployed code and data. It means that it's already initialized. It is an active smart contract, ready to process incoming messages.

account_uninit$00 = AccountState;
account_active$1 _:StateInit = AccountState;
account_frozen$01 state_hash:bits256 = AccountState;

The diagram below illustrates the lifecycle of an account in the TON blockchain, showing how its state changes under different conditions.

Smart contract structure

Smart contracts are a set of promises in digital form, including protocols that govern how the parties fulfil these promises.

In TON, typically by smart contract recognize:

• The program code executed, as described in FunC, Tact, or Tolk, in the blockchain.
• The account that implements business logic and content code.

In technical terms, a smart contract in TON is an Account in the active state (AccountState = active) with:

• an initialized code field in StateInit — containing the executable logic
• an initialized data field in StateInit — storing the persistent contract state

note

An account may be in the active state with state_init.code = None. For example, immediately after a SetCode action in the VM. This is an edge case: such a state is not valid for execution but is technically possible.

Address

An address in TON is a unique identifier for a smart contract required for interaction between network participants. The account itself has an address, but we define the address entirely for arbitrary use only through a smart contract. It consists of the following components:

• WorkChain ID — a 32-bit signed integer indicating the WorkChain to which the account belongs (e.g., -1 for the MasterChain, 0 for the BaseChain).
• Account ID — a 256-bit hash of the StateInit structure, which includes the contract’s initialized code, data, and, optionally, a library. It is stored as an arbitrary SliceData and may not exactly match the hash of StateInit.

important

StateInit (short for state initialized) can change as the contract evolves. The account_id never changes, as it’s based on the very first StateInit recorded at deployment.

The address is defined as:

$$\text{Address} := (\text{workchain\_id}, \text{account\_id})$$

, where

$$\text{account\_id}:= \text{HASH(StateInit)}$$

An address corresponds to the first initialized state of a contract and can be calculated even before the contract is deployed. This allows you to use the address ahead of time — for example, to receive tokens or set up interactions.

An address depends only on the StateInit used at the moment of the contract's first deployment. Even a small change to the code, data, or library in this initialized state results in a completely different account_id — and, therefore, a different address.

In fact, during message processing, validators verify the sender’s address — if it’s incorrect, they silently replace it with the correct one.

Blockchain structure

Blockchain

Blockchain is a distributed ledger consisting of blocks, each containing a set of data. These blocks are cryptographically linked to one another via hashes, forming an immutable chain. This entire chain is replicated and consistently maintained across all participants in the network.

AccountChain

AccountChain is a chain of transactions executed on a single account in the TON blockchain. It forms a linear sequence: Tx1 → Tx2 → Tx3 → …, where each transaction references the previous one.

For efficient processing and consensus, transactions are grouped into blocks — for example: [Tx1 → Tx2] → [Tx3 → Tx4 → Tx5] → [] → [Tx6]. These blocks also include incoming and outgoing message queues, recording all events and state changes for the account during that block period.

In other words, an AccountChain is a micro-blockchain scoped to a single account. Like a regular blockchain, it is a linear, append-only sequence of transactions — but dedicated to just one account. It stores and orders the entire history of that account’s operations and interactions, ensuring transparency and traceability.

At the network level, many such chains are grouped into a ShardChain or simply shard, which manages a collection of accounts. This abstraction supports logical grouping AccountChains across physical infrastructure ShardChain ↔ Validator.

The diagram below provides a graphical representation of an AccountChain and its structure.

ShardChain

A ShardChain is a blockchain that groups multiple AccountChains.

While an AccountChain represents the transaction history of a single account, a ShardChain processes and stores data for a group of accounts that share a common binary address prefix (e.g., all addresses starting with 0b00101). ShardChains also facilitate message routing between accounts, ensuring both delivery and order: if one message is sent before another, it will arrive first.

Each validator is responsible for a specific ShardChain or a group of them, allowing the network to process transactions concurrently across different shards.

WorkChain and BaseChain

A WorkChain is a higher‑level blockchain layer that groups multiple ShardChains into a single working group.

While each ShardChain manages a set of accounts sharing a binary address prefix, a WorkChain defines the shared rules—such as gas pricing and sharding configuration—that every shard under it must follow. In other words, it serves as a policy domain governing its shards under the same protocol.

TON supports up to 2³² WorkChains, each of which can be divided into up to 2⁶⁰ ShardChains.

Currently, TON operates with only one WorkChain, known as the BaseChain. It's the primary execution chain used for everyday transactions and smart contracts. The BaseChain is the WorkChain with an ID of 0. It is optimized for low fees, making it suitable for regular users and developers.

MasterChain

MasterChain is the main coordinating blockchain, including one ShardChain. It contains:

• protocol parameters
• the current validator set and their stakes
• validator account chains
• metadata about all active WorkChains and ShardChains
• hashes of the latest blocks from all other chains

Gas costs are intentionally high in the MasterChain to ensure stability, prioritize critical operations, and prevent spam.

Thanks to the hierarchical structure of WorkChains and ShardChains, TON forms a blockchain of blockchains — a scalable architecture where each chain operates independently, and all blocks reference their predecessors via cryptographic hashes.

Testnet and Mainnet

Mainnet (the main network)

The Mainnet is the live production network where:

• all transactions are real
• real tokens are used (e.g., actual Toncoin)

All users and projects operating in production use the Mainnet.

Testnet (the test network)

The Testnet is an independent blockchain network that replicates the functionality of the main network but uses valueless coins. In Testnet:

• test coins are used, which have no real value
• contracts, transactions, DApps, and errors can be safely tested
• the blockchain can be reset or altered at any time

Testnet is essential for safe development and debugging before launching to the main network.

Next step

You’ve covered the foundations of transactions — now let’s see what makes them happen.

Explore how messages drive transactions

Was this article useful?