The Open Network

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.