TON was designed from day one as a network where sharding is not an optional L1 add-on but the architecture itself. TON Foundation marketing tends to quote “millions of TPS”; engineering posts cite the 104,715 TPS October 2024 record; explorers will show you 40 tx/s. All three are true in their own frame, but they describe different worlds. This article walks the architecture top-down to show where the high TPS comes from and where the design genuinely runs out of headroom.
TON architecture: masterchain, workchains, shardchains
The network is hierarchical. At the top sits the masterchain (workchain ID -1) — a service blockchain that stores network configuration, the validator set, the list of active shards and finalises state across the whole system. There is exactly one masterchain.
Underneath the spec allows up to 2^32 parallel workchains, each potentially with its own VM, address format and fee rules. In 2026 mainnet only one workchain is live — basechain (workchain ID 0). That is where every familiar transaction lives: TON transfers, jetton movements, NFTs, DEX contracts.
Each workchain in turn dynamically splits into shardchains. Per the TON Whitepaper, section 2 the theoretical ceiling is 2^60 shards per workchain. Production is far more modest: shard-prefix length is capped at 4 bits, so basechain can split into at most 16 shardchains at any moment. That gap between the spec ceiling and the production cap is the source of most of the “millions of TPS versus 40 tx/s” confusion we are about to unpack.
The architectural invariant: each contract lives in exactly one shard, and which shard is determined by the prefix of its account ID. When a shard splits in two, contracts whose ID begins with 0... stay on one child shard, those with 1... move to the other. The address itself does not change.
iWhat '16 shards' really means
When TON Foundation says basechain “scales up to 16 shards”, they mean the protocol may run up to 16 parallel shardchains simultaneously, each with its own validator subset. If only 4 are active, the other 12 are dormant and spin up only when load demands. The live count is a dynamic value visible in tonviewer and chainspect.
Dynamic sharding: split, merge and the Infinite Sharding Paradigm
Most sharded networks (Near, formerly Ethereum 2.0) fix the shard count in protocol and change it only by hard fork. TON decides on the fly. That is the Infinite Sharding Paradigm from the whitepaper: conceptually every account has its own virtual blockchain, and real shardchains are simply groupings of those per-account chains by ID prefix.
Split/merge mechanics:
- When shard load exceeds the upper threshold defined in validator config, the shard splits in two — one additional bit is added to the prefix. Account IDs do not move; they are now served by a different validator subset.
- When load drops below the lower threshold, two sibling shards merge back together.
- Both thresholds are network-config parameters, voted on by validators and not pinned to a single public number in the docs.
For developers the effect is that you write the contract as if sharding does not exist. All routing detail is hidden inside the protocol via hypercube routing — a scheme that delivers cross-shard messages through intermediate blocks. Specs in TON docs and the original Catchain paper.
The price for that transparency is cross-shard latency. A message sent from a contract in one shard to a contract in another is not delivered atomically in the same block: it is first committed in the source shard, then routed via the masterchain, then accepted in the destination shard. Before Catchain 2.0 this took roughly 12 seconds with several shards active; after April 2026 the number dropped proportionally but still measures in seconds — typically 1.2-2s depending on load.
Real TPS, the 104,715 test, and what sits between
Here is the table to keep in mind whenever you read any TPS figure for TON:
| Source | TPS | What it actually measures |
|---|---|---|
| Chainspect, May 2026 | ~40 | Mainnet average over the last hour |
| Chainspect, recent 100-block peak | 1,542 | Short burst during airdrop / event |
| Oct 2024 test, CertiK-attested | 104,715 | 256 Alibaba Cloud nodes, 512 shardchains, synthetic contracts, 10 minutes |
| TON Foundation theoretical | ”millions” | Extrapolation assuming full 2^60 shard expansion |
The 104,715 TPS test from October 2024, attested by CertiK, is the engineering upper bound, not the network’s day-to-day reality. The setup: the team spun up 256 high-spec nodes on Alibaba Cloud, activated 512 shardchains simultaneously, and drove pre-deployed contracts under load for 10 minutes. These were not vanilla transfers — the public write-up stresses that the contracts performed “complex execution”. The test rig is reproducible from github.com/ton-blockchain/performance-test.
Why does mainnet deliver 40 tx/s when the hardware can sustain 104K:
- Validator and shard counts. Mainnet runs roughly 408 validators (chainspect) and typically 4-8 active shards at any moment — not 512.
- Actual demand. The mix of users who actually exist on TON today generates 40 tx/s. That is demand, not ceiling.
- Geographic distribution. The test ran in one datacentre; mainnet is globally distributed, which adds consensus latency.
- Transaction mix. Real traffic is dominated by jetton transfers (heavier than raw TON sends) and DEX interactions (multi-message flows).
The honest read: 104,715 TPS is evidence that the architecture will not bottleneck as demand scales. It is not a claim that the network is ready to absorb Visa-grade volume today.
Catchain 2.0: what shipped on April 9, 2026
Catchain 2.0 is the largest consensus upgrade in TON mainnet history. Shipped on April 9, 2026. What changed:
- Block time dropped from ~5s to ~0.4s.
- Finality dropped from ~10s to ~0.8s.
- Throughput rose roughly 10x on the same validator set.
- Annual issuance rose from 0.6% to 3.6% — the cost of more frequent blocks.
Under the hood, Catchain is a pBFT-derived consensus requiring more than 2/3 of validator signatures. Catchain 2.0 rewrote the pipeline so that proposing the next block now runs in parallel with verifying the previous one — that overlap is the main source of the latency win. Implementation notes live in blog.ton.org and in the protocol whitepaper.
From the user’s perspective the observable change is that transfers and DeFi interactions are now noticeably snappier. Jetton-transfer confirmations feel “instant” rather than “two Mississippi”. For DEXes the gap between blocks is now tight enough that arbitrage has moved closer to CEX cadence.
!3.6% issuance, in context
A 6x increase in issuance is a meaningful tokenomics shift. Validators receive more TON as block reward, but holders are diluted slightly faster. The long-run net depends on whether demand for blockspace (fees plus burns) catches up with the new issuance pace. At mid-2026 it is too early to call — we need at least two more quarters of data.
Where the design actually runs out of headroom
Reading only the press posts leaves an impression of an “infinitely scalable” network. In practice TON’s architecture has specific, named bottlenecks.
1. Single-account bottleneck. All transactions for one contract must land in one shard — otherwise prefix-based routing breaks. A hot DEX pool, a popular auction contract, or a viral mini-app contract is therefore capped at the throughput of a single shard. Practical ceiling: a few hundred tx/s per contract. The architectural answer is to shard the contract at the application level (multiple parallel pool contracts, sharded NFT collections), which adds engineering cost.
2. Cross-shard latency. Hypercube routing is an elegant theoretical solution, but the price is multi-block latency between shards. Pre-Catchain 2.0 the number was ~12s; now it sits around 1.2-2s, but it still costs several blocks. For UX tuned around “one-second confirmation” this is visible in complex DeFi flows where a message threads through 3-4 contracts in different shards.
3. The prefix cap. The declared 2^60 shards per workchain live only in the spec. The production parameter caps shard prefix at 4 bits — 16 shards on basechain. Reaching “million-TPS” territory is several protocol upgrades away, not a config flag.
4. Test vs production. The 104,715 TPS run used 256 high-spec servers in a single datacentre with pre-deployed synthetic contracts. Mainnet runs 408 geographically distributed validators on heterogeneous hardware with a real transaction mix. The order-of-magnitude gap is not a bug, it is the difference between two operating regimes.
5. Inflation as the price of speed. A 10x throughput gain came with a 6x issuance increase. That is a legitimate choice, but it is a choice, not a free upgrade.
Comparing with other L1s on the same metrics helps calibrate expectations:
| Chain | Theoretical TPS | Real TPS (1h) | Block time | Finality | Nakamoto coef. |
|---|---|---|---|---|---|
| TON | 104,715 (test) | 40 | 0.4s | 0.8s | ~408 validators |
| Solana | 65,000 | ~1,000 | 0.4s | 12.8s (full) / 2.5s | 20 |
| Ethereum L1 | ~30 | 15-20 | 12s | ~13 min | ~3 |
| Aptos | ~160,000 | ~100 | <1s | <1s | 16 |
TON beats Ethereum L1 on latency and throughput by orders of magnitude, beats Solana on finality (0.8s vs 12.8s at a comparable block time), and beats Aptos on practical decentralisation (~408 validators vs 16). It loses to Solana and Aptos on theoretical and demonstrated per-chain TPS, and that loss is architectural: monolithic Solana/Aptos designs optimise for global ordering, while sharded TON optimises for parallelism.
Roadmap through 2027
Durov announced MTONGA (Make TON Great Again) in early 2026 — a seven-step optimisation programme. Mid-May 2026 status:
- Catchain 2.0 — shipped April 9, 2026.
- Roughly 6x fee cut — announced, target ~$0.0005 per jetton transfer.
- Validator/collator split. Validators will watch only the masterchain; a new collator role will pre-assemble shardchain blocks. Goal: lower validator hardware requirements while raising throughput.
- Optimistic collation. Collators will forward blocks for propagation before validation completes, shaving another second from the latency budget.
- AgenticKit, Rust Node v1, Tolk dev tools. Developer tooling and an alternative Rust node client — reducing the network’s dependence on the single C++ implementation.
- A new consensus layer. The post-Catchain-2.0 evolution; details not yet public.
- Layer-2 Payment Network + BTC Teleport bridge. A fast-payments layer and a native Bitcoin bridge.
Delivery is spread across 2026-2027. Pragmatic expectation: by end-2026, fee reduction and the start of collator/validator split work; through 2027, Rust node and L2 payment network in production.
What this means for builders and holders
If you are building a TON dApp in 2026, the reasonable defaults are:
- Finality ~0.8s — design UX for “near-instant” rather than “synchronous”.
- Cross-shard messages are not atomic. Hide complex multi-contract flows behind a state machine that handles intermediate states correctly.
- One contract, one shard. If you anticipate a high-throughput scenario (mass airdrop, hot NFT mint), shard the state at the application layer.
- 104,715 TPS is not a marketing cudgel, it is a ceiling under a specific configuration. Plan for 100-300 tx/s per contract as your working baseline.
If you are a holder thinking about long-term network health, the indicators that matter are validator-count resilience (does decentralisation hold after the collator/validator split lands), real inflation (does it stay at the announced 3.6% rather than drifting up), and the L2 payment layer (which should absorb high-frequency micropayments and offload L1).
Sources
- TON Whitepaper — the original architecture spec.
- docs.ton.org/develop/blockchain/shards — shard documentation.
- Catchain paper — consensus paper.
- chainspect.app/chain/ton — live TPS and validator metrics.
- github.com/ton-blockchain/performance-test — repo behind the 104,715 TPS run.
- blog.ton.org — Catchain 2.0 and MTONGA announcements.
Top comments (0)