The Multi-Blockchain Design

Most blockchains are a single chain of blocks. Ethereum is one chain. Bitcoin is one chain. TON is fundamentally different — it is a blockchain of blockchains. The network consists of multiple interacting chains organized in a hierarchy, each serving a specific purpose.

This architecture is what enables TON to scale beyond what single-chain designs can achieve. Understanding it is essential to understanding TON's security model.

The Masterchain

The masterchain is TON's backbone — a single, authoritative chain that stores the network's global state:

  • Validator set: The current list of validators and their stakes
  • Configuration parameters: Network-wide settings (gas prices, staking rules, election parameters)
  • Shard state hashes: Cryptographic commitments to the state of every shardchain
  • Governance decisions: Approved proposals and parameter changes

The masterchain does not process user transactions directly. Think of it as the "constitution" of the network — it defines the rules, and all other chains follow them.

Workchains

Workchains are independent blockchains that actually process transactions and execute smart contracts. TON's design supports up to 232 workchains (over 4 billion), though currently only two exist:

Workchain 0 (Basechain) The primary workchain where all user transactions, token transfers, and smart contract interactions happen. This is where your Toncoin lives.
Workchain -1 (Masterchain) The masterchain itself is technically workchain -1. It handles validator elections, configuration changes, and stores shard state proofs.

Each workchain can have its own rules: different virtual machines, different address formats, different transaction formats. This makes TON extensible — a future workchain could support EVM compatibility, privacy features, or entirely new execution models.

Shardchains and Infinite Sharding

This is TON's most innovative feature. Each workchain can split into up to 260 shardchains. Each shardchain is responsible for a subset of accounts, determined by the account address prefix.

How it works:

1
Normal load

Under normal conditions, a single shard handles all transactions for the workchain.

2
Load increases

When a shard becomes overloaded, it automatically splits into two shards. Accounts starting with "0" go to one shard, accounts starting with "1" go to the other.

3
Recursive splitting

Each new shard can split again if needed. The process is recursive — the network can keep splitting until every account has its own shard if necessary.

4
Load decreases

When shards are underutilized, they merge back together. The network dynamically adjusts to actual demand.

💡
Why "infinite" sharding?

Because the theoretical limit is 260 shards (over 1 quintillion), the network can always split further to meet demand. In practice, this means TON will never run out of throughput capacity.

Cross-Shard Communication

When a smart contract on shard A needs to interact with a contract on shard B, TON uses Instant Hypercube Routing. Messages are routed through intermediate shards using a hypercube topology, ensuring delivery in O(log N) hops where N is the number of shards.

This is fundamentally different from Ethereum, where all contracts share one global state. In TON, contracts communicate asynchronously via messages — similar to how microservices communicate in modern software architecture.

TON Virtual Machine (TVM)

TVM is the execution engine for TON smart contracts. Key characteristics:

  • Stack-based: Like the JVM, TVM operates on a stack rather than registers
  • Bag of Cells (BoC): All data in TON — transactions, blocks, contract state — is stored as trees of cells. Each cell holds up to 1023 bits and 4 references to other cells
  • Continuation-based: TVM supports continuations, enabling complex control flow and gas management
  • Deterministic: Given the same input, TVM always produces the same output across all validators

Smart contracts on TON are written in FunC (a C-like language) or Tact (a higher-level, TypeScript-like language). Both compile to TVM bytecode called Fift.

Consensus: BFT Proof-of-Stake

TON uses a Byzantine Fault Tolerant (BFT) Proof-of-Stake consensus mechanism called the Catchain protocol:

  • Validator elections: Every ~18 hours, a new validator set is elected based on stake
  • Minimum stake: Validators must stake a significant amount of Toncoin (currently ~300,000 TON)
  • Slashing: Validators that act maliciously or go offline lose a portion of their stake
  • Fault tolerance: The network remains secure as long as fewer than 1/3 of validators are Byzantine (malicious)
  • Finality: Once a block is confirmed by 2/3+ of validators, it is final and cannot be reversed

Security Implications of the Architecture

⚠️
Asynchronous means different security risks

Because TON contracts communicate via messages (not shared state), race conditions, message ordering attacks, and bounce handling bugs are unique vulnerability classes that don't exist on Ethereum.

  • Cross-shard latency: Messages between shards take multiple blocks to deliver, creating timing windows
  • Bounce handling: If a message to a contract fails, TVM sends a "bounce" message back. Contracts that don't handle bounces correctly can lose funds
  • State rent: Unlike Ethereum, TON contracts must pay for storage. A contract that runs out of funds for storage is frozen and can lose state

Summary

  • TON is a multi-blockchain system: masterchain, workchains, and shardchains
  • Infinite Sharding allows the network to dynamically scale to any transaction volume
  • Cross-shard communication uses Instant Hypercube Routing
  • TVM executes smart contracts using the Bag of Cells data structure
  • BFT PoS consensus provides fast finality with slashing for bad actors
  • The asynchronous architecture creates unique security considerations
🎉
You now understand TON's architecture!

This knowledge is essential for understanding how TON wallets, staking, and DeFi work under the hood.

Related Tutorials