TON validators and block collators no longer talk to the public part of the network directly: separate rebroadcaster nodes forward blocks there and carry external messages back. On November 6 the team that develops the TON node described the blockchain's network architecture as a whole, as it stands after almost a year of updates. This matters first of all to anyone running a validator or their own full node: they need a working QUIC port, and the next update removes the old RLDP1 and RLDP2 transport protocols entirely.

The post on Telegram — @toncore
Description of TON's new network architecture, November 6

What exactly has been rebuilt

This is about the networking layer — how nodes find each other and pass blocks and messages around. The description announces no changes to the rules of sharding or consensus: what changes is which subnetworks carry data between the masterchain, the shardchains and the rest of the network.

TON nodes exchange data through overlays — subnetworks that include only the nodes taking part in one job: validating a particular shard, serving blocks to anyone who asks, and so on. The description names three kinds:

OverlayWho is in itHow blocks are broadcast
Private, one for the masterchain and one for each shardchainall validators (about 400) and all collatorsTwo-Step
Protectedcritical infrastructure, including rebroadcastersPlumtree
Publicany full nodesPlumtree, blocks come from rebroadcasters

The masterchain is the main chain that ties together the states of all shards; a shardchain is a chain that processes its own share of the network's accounts. A collator assembles a candidate block from transactions, and a validator checks and signs it: on mainnet these roles were split by the 2026.08 update of August 17.

Shared private overlays instead of block-sync

Previously a shard's private overlay included only the validators and collators serving it in the current round. The rest received that shard's blocks through a separate block-sync overlay, which was added to the node code in May. Now the private overlay of the masterchain and of every shardchain includes all validators and all collators in the network, and block-sync is gone: blocks reach every validator by the same route as the current ones.

In the current round, which began on November 12 at 05:30 UTC, there are 375 validators (the team's description says about 400), 100 of which sign masterchain blocks (config parameter 34, tonapi).

The protected overlay

The protected overlay serves the infrastructure the network cannot run without, including rebroadcasters. It used to be called fast-sync. The name was changed because, according to the team, fast synchronisation is now required of every overlay, the public one included, and the point of this one is security and stability. In the node's October commits it is still called fast-sync.

Validator isolation and rebroadcasters

Validators and collators no longer take part in the public overlay. Rebroadcasters stand between them and the rest of the network: they take finished blocks and broadcast them into the public overlay, and pass external messages — the ones that enter the network from wallets and services — in the opposite direction.

Isolation arrived with node release v2026.10 on October 19, which removed validators and collators from public overlays; two weeks before the release the code received changes such as "don't send externals to public overlay from validators" and "isolate validators from public overlays with catch-up fallback". According to the team, isolation improves security and reduces validators' network traffic and CPU load.

The rebroadcaster code is open in the rebroadcast-to-public branch: as of November 12 it holds eight commits on top of the main branch, the latest from October 22 — a public rebroadcaster mode, a configurable number of peers for Plumtree forwarding, a whitelist of peers, metrics. It is promised to be merged into the main branch soon. Like collators, rebroadcasters are run by some validator operators, and no additional ones need to be deployed for now.

Three ways to broadcast

  • Gossip — TON's original broadcast: a node passes data to its neighbours, they pass it to theirs. It remains in use for some message types.
  • Two-Step — built as part of the Sub-Second update for private validator overlays, whose membership is known in advance.
  • Plumtree — TON's own take on the algorithm of the same name, for overlays with changing membership, the public and the protected one. In classic Plumtree nodes build a tree: a block travels in full along its branches, while other neighbours get a short notice that the block exists, and a missing block can be requested through it. TON's implementation, the team says, differs from the classic one but follows the same ideas. It keeps nodes in sync even when a large share of them perform poorly.

There was a practical reason too. Starting September 23, a large number of nodes that do not forward traffic appeared in the public overlay, and delivery of blocks and external messages through it got worse. Plumtree was switched on in the public overlay by the October 21 vote for the second version of the consensus protocol — that vote is covered in detail in the piece on global version 16. On October 23 the network completed the move to the new broadcasts in the public overlay. According to the team's data, traffic then fell both on validators and on a public overlay node, and block delivery became noticeably more stable.

QUIC instead of RLDP

For reliable data transfer TON has used its own RLDP protocols from the start — close to QUIC in what they do, but predating QUIC's standardisation (RFC 9000, May 2021). Over 2026 RLDP1 and RLDP2 were gradually replaced with QUIC; release 2026.10 deprecated RLDP2. The next node update will complete the migration, and RLDP will no longer be used in the TON blockchain. No date has been announced for that update.

How it got here

WhenWhat
July 28, 2025Accelerator update: the collator appeared in the node code as a separate node type
April 2026Sub-Second mode, Two-Step broadcast in private overlays
2026.04-1 — 2026.06QUIC instead of RLDP and the ADNL transport, block-sync and fast-sync overlays, Plumtree; a node's inbound traffic fell about fourfold, outbound twofold
August 172026.08: collators enabled on mainnet
October 192026.10: validators and collators removed from the public overlay, RLDP2 deprecated
October 21–23Plumtree in the public overlay
by November 6block-sync removed, fast-sync renamed to the protected overlay
next updateRLDP1 and RLDP2 removed

The freed resources, the team says, will go into shardchain performance. The target named in September is 1,000–2,000 transactions per second per shardchain; in a September 4 test a single shardchain handled 600–650 transactions per second in Sub-Second mode, and split in two as the load kept growing.

What it means for validators and developers

  • Validator operators. A validator machine no longer serves the public overlay, which takes some traffic and load off it. For the 2026.10 update validators were given 24 hours after release. Since October 19 masterchain block production has declined by about 2.5% on average, and total validator rewards per round by 1.45%. In the same message the team lists seven masterchain validators that consistently underperform, possibly because of hardware below the minimum requirements.
  • Full node and liteserver operators. Blocks arrive from rebroadcasters through the public overlay, and external messages reach validators through them too. The QUIC port on a node has had to work since October 23; nodes not updated to 2026.10 lose sync.
  • App developers. The architecture description contains no changes to smart contracts, fees or APIs: everything listed sits at the node level. Exchanges, wallets, Telegram and Toncenter API do not use the public overlay, according to the network team; those who run their own node are advised in the same message to use one of the public HTTP APIs alongside it.