TON Rust Node is here. Chaos unleashed.

Blocks screaming, systems bending, unstoppable power?

Breaking ground on the TON network
after the TON Rust Node launch, like never before.

Follow the signal: https://tonrust.io

🎬 Tech Updates EP2 | Roman Nguyen

Yesterday we announced TON Rust Node. Today, meet the team behind it.

Roman Nguyen, CTO of RSquad Blockchain Lab, explains what they built and why it matters for anyone running TON infrastructure.

👉 Watch the full episode

💬 What would you like to see from TON in 2027? Share below.

Gateway|TON Community | TON Builders | TON Hubs |X | YouTube | LinkedIn TON.org

Node Update v0.3.0 & Helm Update v0.4.1

Drop the node. Bump the chart. Back to building.

Node Update v0.3.0

What’s inside:

— Simplex consensus (feature-gated)
Adds a feature-gated Simplex consensus implementation.

— JSON-RPC expansion
Adds getAccount and getBlock, plus an updated OpenAPI spec.

— Download and metrics tooling
Adds a state downloads limit, an applied blocks metric, and a TPS measurement tool (test tooling).

— ADNL tuning
Improves broadcast behavior (randomized neighbours, smaller waves, FEC timeout tuning, wider GetRandomPeers spreading) and increases send buffer limits.

— Telemetry update
Switches throughput calculations to current_average.

— Non-accelerated consensus behavior
Disables validation/collation task await for non-accelerated consensus.

Fixes:

— Consensus and collation robustness
Slot bounds checks, safer windows, better error handling, simplex earliest collation time handling.

— Stability on restarts
Preserves DB on stop, registers overlay before bootstrap, replaces dead overlay clients.

— Networking and liteserver correctness
ADNL packet/multipart handling, broadcast ID validation, LITESERVER_PUBLIC_KEY parsing, overlay leak fix, FinalCert broadcast fix, plus execution/stats correctness fixes.

Full changelog: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.3.0

Helm Update v0.4.1

What’s inside:

— Default image tag updated to v0.3.0

Full changelog: https://github.com/RSquad/ton-rust-node/releases/tag/helm%2Fnode%2Fv0.4.1

If the nodes are united,
they will never be divided

Built complete. Built to run. The repository is now public on GitHub.
What was built to perform can now be opened in full form.

Source code: https://github.com/RSquad/ton-rust-node

Nodectl Update v0.3.0 & Nodectl Helm Chart Update v0.2.0

Control got sharper. Visibility got deeper.

Nodectl Update v0.3.0

What’s inside:

— REST API authentication
Login, token revocation, auth middleware, login rate limiting, token-based access, and new auth / api login CLI commands.

— Election status dashboard
Election lifecycle tracking, stake totals, and election metadata in both API and CLI.

— Validator keys listing
Validator keys, election IDs, timestamps, statuses, key IDs, and ADNL addresses available in both API and CLI.

— Kubernetes DNS support
Control server addresses can use internal DNS names, not just IPs.

— Swagger auth support
Swagger UI includes Bearer token authentication with an Authorize button.

— New flags for filtering and output
--filter=<name> for elections and validators, plus --format=json|table for config list commands.

Also improved:

Bounceable wallet addresses in config wallet ls, smoother endpoint round-robin, safer wallet listing when TON API is unavailable, auth hot reload, and extended version output

Full changelog: https://github.com/RSquad/ton-rust-node/releases/tag/nodectl%2Fv0.3.0

Nodectl Helm Chart Update v0.2.0

What’s inside:

— Flexible Service & Network settings
Adds service.nodePort, service.clusterIP, service.loadBalancerIP, and service.externalTrafficPolicy for fine-grained networking.

— NetworkPolicy Update
networkPolicy.allowCIDRs has been removed. Use networkPolicy.allowFrom instead, which supports standard selectors (ipBlock, podSelector, namespaceSelector).

Full changelog: https://github.com/RSquad/ton-rust-node/releases/tag/helm%2Fnodectl%2Fv0.2.0

TON Rust Node v0.4.0: Ready for Simplex & QUIC

Back with a major v0.4.0 release, ensuring your setup is ready for TON's latest network-wide upgrades.

Archival mode is live, featuring the CellsDB cache and stable shard split/merge handling. Core logic is fixed: direct TON config queries and corrected fee accounting.

Read the Changelog: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.4.0

TON Rust Node v0.5.0: Synced with C++ Node

Now up to date with the C++ implementation.

v0.5.0 adds Simplex consensus changes, optimizes network connections, and fixes transaction execution, LiteServer runSmcMethod, config params, and Merkle updates.

Read the Changelog: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.5.0

TON Rust Node v0.5.1: LiteServer Response Fix

Response corrected. Block proof traversal optimized.

Fixes LiteServer response handling for listBlockTransactions so clients accept it correctly, while making block proof traversal more efficient.

Read the Changelog: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.5.1

Nodectl v0.4.0 & Node v0.5.2: Adaptive Staking & Performance Optimization

Here with a major release focused on validator efficiency and smoother operations.

This update brings adaptive staking with adaptive_split50, multi-nominator pool support, built-in voting, and persistent ADNL addresses. Fast-sync over QUIC is more efficient, while fixed TVM stack serialization improves LiteServer stability.

Full changelogs:
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/nodectl%2Fv0.4.0
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.5.2

TON Rust Node v0.5.3: Validator Connectivity Improvements

Stronger validator links. Smoother networking across epochs.

Optimizes QUIC for high-latency links to improve validator-to-validator connection reliability, while keeping ADNL validator keys persistent across epochs.

Read the Changelog:
https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.5.3

TON Rust Node v0.6.0: Infrastructure Upgrade

Improving core performance and resilience.

Brings Vault support for managing node secrets, optimizes Simplex consensus and collator performance, and enhances node database efficiency. Also resolves TVM compatibility issues and ensures correct archive truncation after reboots.

Read the Changelog: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.6.0

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.

Finally.

We know and we see the support from everyone using this node — and trust us, there are more of you than it might look from the outside. To everyone who took a chance on this node, ran it in production, reported issues, or just shared honest feedback — thank you. This product is what it is because of you.

We keep building. More is coming: technical deep-dives, the reasoning behind architectural decisions, migration case studies. And, in time, the backstory — what we've seen, what we've worked around, and why this node had to be built at all. We've held a lot of it back so far. But since we're working in public now, there's no real reason not to start sharing the facts. Stay tuned.

We're just getting started.

Nodectl v0.5.0 & Node v0.7.0: Validator Continuity & Security Hardening

Keys locked tight, pools tuned right, node running light.

Static ADNL becomes the default across elections, nominator pools get deploy modes for cleaner setup, and automation covers wallet and pool deploys and top-ups.

On the node side, secrets move into vault-based storage, while external message processing, archival memory usage, CellDb efficiency, and the handling of compressed BOCs, external messages, and TVM transactions all improve.

Full changelogs:
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/nodectl%2Fv0.5.0
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.7.0
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/helm%2Fnodectl%2Fv0.3.0