Catchain

Catchain is TON’s internal BFT consensus protocol — the mechanism validators use to agree on the next block. It plays the role Tendermint or HotStuff plays in other chains, but is tuned for TON’s architecture of shards and fast-rotating validator groups.

How it works

When a validator group is assigned to a specific shard, a dedicated catchain session is launched for it. Inside the session nodes exchange votes in several rounds: block proposal, voting, commit. Agreement is reached once validators representing at least 2/3 of stake have signed the block.

A session lives for roughly 1000 blocks (around 15–20 minutes), after which the group is reshuffled at random. That short lifetime limits the window for long-running collusion — even a temporary malicious majority is broken up the next round.

Properties

• Low finalisation latency. Masterchain blocks finalise in 2–3 seconds; shard blocks are even faster because the validator messages are short.
• Dedicated gossip layer. Catchain runs on top of ADNL and is isolated from user network traffic.
• Liveness under faults. If up to 1/3 of validators are offline or byzantine, the protocol still produces a block — just more slowly.

What developers need to know

Catchain is an implementation detail; dApps never touch it directly. They care about block finality, which a lite-server reports. But when reasoning about network throughput it’s useful to keep in mind: the catchain round is the lower bound on inter-block time.