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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 5
Code
Source, repository, and what is actually hosted
- ton.org white paperhttps://ton.org/whitepaper.pdf
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
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.
Claim 05 · Paper model
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.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 Many chains, one master
Observation
What the study says
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.
Model
What has to hold
Shard subsets are reassigned so a captured group does not keep a shard.
Falsifier
What would retire it
What is the masterchain's block time, and how many shard hashes must it commit?
02 Shards split and merge
Observation
What the study says
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.
Model
What has to hold
Shard subsets are reassigned so a captured group does not keep a shard.
Falsifier
What would retire it
When did this shard last split or merge, if ever?
03 Instant hypercube routing
Observation
What the study says
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.
Model
What has to hold
Routing actually finds a path before users time out. A message stuck between shards is a lost payment from the user's side.
Falsifier
What would retire it
What is the masterchain's block time, and how many shard hashes must it commit?
04 Validators stake on the masterchain
Observation
What the study says
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.
Model
What has to hold
The masterchain validator set is large and honest enough for its own Byzantine assumption.
Falsifier
What would retire it
How are validators assigned to shards, and how fast can a bad subset be removed?
05 The original authors left
Observation
What the study says
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.
Model
What has to hold
The masterchain validator set is large and honest enough for its own Byzantine assumption.
Falsifier
What would retire it
Is the citation about the paper, about Telegram, or about the current network?
03 Sequence
One action, as an operating tape
- 01Validators are elected on the masterchain according to stake.
- 02Subsets are assigned to shards. Each subset runs Catchain to produce shard blocks.
- 03Shard block hashes are committed on the masterchain, which itself is a small chain with tight finality goals.
- 04A message from one shard to another is routed across intermediate shards, each of which includes it in a block.
- 05If load stays high, the shard configuration splits. The masterchain records the new configuration so clients can find the right subset.
04 Load-bearing
The argument, and where a pitch drops it
The masterchain is a bottleneck on purpose
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Telegram's abandoned launch and the later community network are different institutional facts. The paper does not adjudicate them.
Dynamic sharding is an availability problem
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Split and merge logic is where sharded designs get their bugs. The paper is not a bug bounty.
Authorship and operation have diverged
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Telegram's abandoned launch and the later community network are different institutional facts. The paper does not adjudicate them.
05 Register
What has to be true
Stake and threshold · Not re-measured
The masterchain validator set is large and honest enough for its own Byzantine assumption.
Model · Not re-measured
Shard subsets are reassigned so a captured group does not keep a shard.
Network · Not re-measured
Routing actually finds a path before users time out. A message stuck between shards is a lost payment from the user's side.
Model · Not re-measured
Clients verify masterchain commitments rather than trusting an endpoint that summarises them.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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
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 the desk 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.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
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.