LibraryConsensus2021Design paperCorpus record
The Open Network
TON. Nikolai Durov.
Durov's design for a multi-chain system of account-chains gathered into shardchains, with a masterchain that records the others. It began as Telegram's network design and continued as The Open Network after Telegram stepped away from the original launch.
The Open Network paper describes a bag of sharded blockchains that can split and merge, with a masterchain recording their hashes, aimed at very high throughput and instant-feeling payments.
The five-minute read
Many chains, one master
Workchain shards process their own transactions. The masterchain commits their latest hashes. A client who trusts the masterchain header has a directory to every shard.
Shards split and merge
A busy shard is supposed to become two. A quiet pair is supposed to become one. The paper treats dynamic sharding as normal operation, not as a hard fork.
Instant hypercube routing
Messages between shards take a path through the shard graph. The paper's low-latency claim depends on that routing, not only on a fast local consensus.
Validators stake on the masterchain
A global set is elected, then subsets validate shards. The election is the sybil control. Catchain, the Byzantine protocol named in the design, runs inside those subsets.
The original authors left
The paper was written for Telegram's effort. The network that now runs is a continuation by other developers. The text is not a statement by today's operators, and today's operators are not the 2021 paper.
One action, walked through
- Validators are elected on the masterchain according to stake.
- Subsets are assigned to shards. Each subset runs Catchain to produce shard blocks.
- Shard block hashes are committed on the masterchain, which itself is a small chain with tight finality goals.
- A message from one shard to another is routed across intermediate shards, each of which includes it in a block.
- If load stays high, the shard configuration splits. The masterchain records the new configuration so clients can find the right subset.
The argument, unpacked
The masterchain is a bottleneck on purpose
Everything that must be globally visible funnels through one chain of hashes. That is how a client stays sane. It is also a limit. If the masterchain is small and slow, shards cannot be allowed to outrun what it can notarize. The paper's huge throughput numbers have to be read against that funnel.
Dynamic sharding is an availability problem
Splitting a shard means both new shards must have the state and the validators they need, at the moment of the split. A paper diagram of a binary tree does not move bytes. The operational question is the design question.
Authorship and operation have diverged
Citing TON as Telegram's live system is inaccurate. Citing the live network as if every parameter matched the original paper is also inaccurate. Say which object you mean.
What has to be true
- The masterchain validator set is large and honest enough for its own Byzantine assumption.
- Shard subsets are reassigned so a captured group does not keep a shard.
- Routing actually finds a path before users time out. A message stuck between shards is a lost payment from the user's side.
- Clients verify masterchain commitments rather than trusting an endpoint that summarises them.
What happened after the paper
Telegram stepped away after legal action around the original offering. An independent community continued the network now called TON. Consensus details, the validator market and application layers have moved on. Use the paper for the masterchain-and-dynamic-shard architecture. Use the live network for anything about today's operators.
What to check before you use the idea
- What is the masterchain's block time, and how many shard hashes must it commit?
- When did this shard last split or merge, if ever?
- How are validators assigned to shards, and how fast can a bad subset be removed?
- Is the citation about the paper, about Telegram, or about the current network?
Terms
- Masterchain
- The chain that records validator sets and the latest hashes of every shard.
- Shardchain
- A chain responsible for a slice of accounts, able in the design to split or merge.
- Catchain
- The Byzantine protocol the design uses inside a validator subset.
- Hypercube routing
- The paper's path for a message to move across shards in a small number of hops.
The problem the paper names
A single chain that tries to hold every account becomes the bottleneck, and a sharded design that lets shards diverge without a master record becomes impossible to verify. TON's paper specifies both the shard structure and the masterchain that notarises it.
What the design proposes
- Account-chains roll up into shardchains. Shardchains can split and merge.
- The masterchain stores hashes and validator sets that make the shard state checkable.
- Messages between accounts are asynchronous, with an explicit hypercube-style routing story in the original design.
How the mechanism is specified
- Validators are elected for a masterchain round and assigned to shards.
- Instant hypercube routing, in the paper, is a claim about message delivery across shards, not a measured latency.
- The original Telegram issuance plan is not this page. The page is about the protocol text.
What this page does not treat as proven
- Telegram's abandoned launch and the later community network are different institutional facts. The paper does not adjudicate them.
- Split and merge logic is where sharded designs get their bugs. The paper is not a bug bounty.
- We do not repeat performance slogans from secondary write-ups.
Why a venture studio still reads it
A useful reference for ventures that need many account chains and one place a third party can look to see which shard hashes were signed. If there is no master record, verifiers are back to trusting a gateway.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.