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 essence, an actor is an independent entity that maintains its own state, defines its behavior, and interacts only through message passing. 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 modeled 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 logical time (last_trans_lt)
• Data — user-defined data
• Code — custom logic defining the account's behavior

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

[
  {
    "ID": "ID1",
    "balance": "0 TON",
    "status": "nonexist",
    "last_trans_lt": null
  },
  {
    "ID": "ID2",
    "balance": "10 TON",
    "status": "uninit",
    "last_trans_lt": "tx_id_example"
  },
  {
    "ID": "ID3",
    "balance": "-0.5 TON",
    "status": "frozen",
    "last_trans_lt": null
  }
]

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, nonexist) or (ID2, 2 TON, active, last_trans_lt, data, code)

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

Example: (ID2, 2 TON, active, 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. No immediate response is guaranteed. The receiver may delay responding or may not respond at all.
2. The sender does not wait for a reply. 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. Messages are processed sequentially per destination account. Each account processes incoming messages one at a time. If a message is malformed or incomplete, it may be skipped.

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

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

In TON, a transaction is a record of an account's state update caused by processing an incoming message.

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 delivered 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, and last transaction)
• Data
• Code

In practice, the actual data layout is more complex. However, the logical distinction between an account and a smart contract remains the same. To describe data structures, 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
• Storage statistics — StorageInfo
• Storage — AccountStorage, which contains:
  • Logical time of the account's last applied transaction — last_trans_lt
  • Balance — CurrencyCollection
  • State — AccountState, which defines the account’s behavior

Full TL‑B account schema

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
• State → AccountState
• Last transaction logical time → last_trans_lt

Account state

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. TON defines account states AccountState as follows:

State	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 a zero balance and accumulated debt. Therefore, does not 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;

Account status

The account status AccountStatus provides a high-level view of an account’s lifecycle stage.

While account's state captures the account’s underlying content— its code and data — account's status abstracts these details to indicate whether an account is uninitialized, frozen, active, or nonexistent.

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

The diagram below illustrates the lifecycle of an account in the TON blockchain, showing how its status 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, a smart contract is typically recognized by:

• the program code executed within 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 and implementation‑specific.

Address

An address in TON is a unique identifier for a smart contract required for interaction between network participants. Every account has an address, which can be determined even before deployment from the smart contract’s StateInit. 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 derived from the contract’s initial code and data.

The address is defined as:

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

where:

$$\text{account\_id}:= \text{HASH(initial\_code, initial\_data)}$$

important

StateInit (State Initialized) defines the contract’s initialization parameters: code, data, and optionally a library. These fields may change during the contract’s lifecycle, but the account_id is calculated only once, from the very first StateInit recorded at deployment.

Because the address depends only on the initial StateInit, it can be deterministically computed before deployment. This allows third parties to reference the contract address in advance, such as for token transfers or integration setup.

Even a minimal change in the initial code or data leads to a completely different account_id, and therefore a different address. During message processing, validators verify the sender’s address. If the provided address does not match, it is automatically replaced 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 of AccountChains across the 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 handle message routing between accounts. The ordering of messages is preserved per account.

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.

Mainnet and Testnet

Although TON maintains one architecture, it operates in separate environments: the Mainnet for live execution and the Testnet for development.

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?