We stayed quiet for a long time. We were building the product, supporting operators, and genuinely counting on fair competition and joint work — which, by the way,
was actually happening. Teams were finding bugs in each other's implementations, sharing observations, surfacing more and more nuances of how the protocol actually behaves. That's what healthy collaboration for the good of the ecosystem looks like.
We deliberately kept out of the public eye both the circumstances under which the decision to build this node was made, and who made it. We figured the product would speak for itself.
But since public claims about the status of the Rust implementation are now on the table —
let's talk facts.
Status of TON Rust Node.
The node has moved out of the experimental stage and is in
rollout. The first Rust validators went live on mainnet
more than 3 months ago and have been running stably ever since. Today on mainnet there are
several validators, dozens of full node / liteserver instances, and archive nodes. It's run by our team, by independent operators, and by infrastructure teams. The current migration request stands at
around a hundred validator nodes.
The nodes sync stably, participate in consensus, maintain the current state of the network, and create no problems for block propagation or compatibility.
Code, documentation, tooling — all open:
https://github.com/RSquad/ton-rust-node
Coverage: consensus (catchain & simplex), validator, full node, liteserver, archive, TVM/executor, and the full QUIC/ADNL/RLDP/Overlay/DHT stack. Infrastructure layer: Docker, Kubernetes/Helm,
nodectl for cluster management, election & staking automation, Prometheus/Grafana, HashiCorp Vault for key management without storing keys on disk. Load testing —
36 nodes across three geographies, 2000+ TPS sustained.
Yes, we occasionally run into issues. Yes, there were problems — it would be silly to pretend otherwise. But it would be equally silly to pretend that
90% of the time these issues trace back to breaking protocol changes pushed unilaterally, without coordination with teams maintaining alternative implementations. That's a process question, not an implementation quality question.
Now to the substance.
The argument in the original statement boils down to this: the priority is
MTONGA, therefore alternative implementations are
"not on the agenda." But
MTONGA is
Make TON Great Again.
Open again.
Great again.
Pavel Durov himself, announcing the next step, put it plainly: the focus shifts to
technological superiority.
Here's the thing: technological superiority in a blockchain
isn't one reference implementation controlled by one group. That's the
opposite of technological superiority. That's a monoculture. One bug in the only implementation, and the whole network halts. No amount of testing, reviews, or internal discipline closes that gap — because the blind spots inside a single team are
shared blind spots.Ethereum and Bitcoin — the two networks with the largest market caps in the entire industry — have operated with multiple independent clients for years, for exactly this reason. It's the only known way to build genuine resilience.
This isn't ideology. It's engineering.
Saying
"we don't need alternative implementations because we're focused on the technology" is a contradiction in a single sentence.
On ideals.
TON was conceived as
open, decentralized, free infrastructure. Telegram — as a space for
freedom of thought, action, and speech. Either those values exist or they don't.
You don't make TON open and great again through closed development of an open-source product, zero community support, unilateral breaking changes, and public attacks on alternatives instead of debate on the merits. That's the exact
opposite direction from what was originally built into TON, and from what Telegram itself proclaims.
We're for
free competition. For
openness. For
collaboration. For
facts. Our goal is to make the solution better, not to prove someone else's is worse.
