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.