Shardchain
A dynamic subdivision of a workchain in TON. The network splits and merges shardchains on the fly to absorb load — the foundation of TON's claimed throughput.
Aliases: shard, ton shard, dynamic sharding
A shardchain is a slice of a TON workchain. Instead of one global chain that processes every transaction (Bitcoin, Ethereum L1), TON splits a workchain into multiple shardchains that run in parallel, each handling a subset of accounts.
Dynamic sharding
The defining feature of TON is that sharding is dynamic. The network watches block load and automatically:
- Splits a shard in two when load grows past a threshold. Each new shard takes half of the address space.
- Merges two adjacent shards back when load drops, to save on validator overhead.
This happens without a hard fork, without governance, and without users noticing. Each shardchain has its own validator committee assigned per round, drawn from the global validator set.
How addresses are routed
Every TON account address has a 256-bit hash. A shardchain owns a prefix of that hash space, e.g. shard 0x0… owns all accounts whose hash starts with 0. When the shard splits, one new shard takes prefix 00… and the other 01…. A wallet in shard 0 simply finds itself in 00 after the split — same address, smaller shard.
Shardchains and the masterchain
Shardchains do not coordinate state on their own. Each shardchain block carries a reference to the latest masterchain block, and each masterchain block embeds the latest shardchain hashes. This is how TON glues parallel shards into one logical network: a payment in shard A can prove its existence to a contract in shard B by walking the masterchain link.
Why this is hard
Most “sharded” L1s (Near, ETH 2.0 sharded plans, Polkadot parachains) treat shards as static. Dynamic sharding adds two problems:
- Cross-shard messages must survive splits and merges. TON solves this with hypercube routing — at most O(log N) hops between any two shards.
- Fork choice must agree on the shape of the shard tree. The masterchain is the source of truth: validators sign off on the new shape every round.
In practice, the basechain rarely runs with more than 4–8 shards; the architecture is sized for hundreds, but production traffic has not required it yet.
What it means for developers
For the most part, nothing. Wallet libraries, jetton standards, and TON Connect all hide the shard. But if you build infrastructure (an indexer, a payment processor) you must subscribe to all active shards, not just one — otherwise you’ll miss transactions when load spikes and a new shard appears.