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
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
8🔥9❤7👍3
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
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
4❤9🔥6
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
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
7❤7🔥5👍3
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
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
14❤10🔥9
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
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
8🔥9👍7
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
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
6🔥10❤7👍5
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.
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.
328❤32👍12🔥11
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.
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.
341❤23👍12🔥10
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
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
5❤7🔥7👍5
Nodectl v0.5.1 & Node v0.8.0: RPC Resilience & Data Freshness
Lag protection on the fly, strict endpoint routing, and precise stake validation.
Nodectl protects your election decisions by automatically skipping lagging JSON-RPC endpoints before every request. Instead of unpredictable round-robin, it now enforces a strict priority-based fallback where the primary node carries all traffic and backups trigger only on failure, while periodic TTL cache refreshes eliminate frozen-stake accounting distortions.
On the node side, a new HTTP SSE endpoint enables real-time tracking of confirmed blocks. The latest update also delivers a major Cell DB performance boost via the RocksDB merge operator, along with further stability fixes.
⚠️Important: this release is non-revertible. Once upgraded, nodes cannot roll back to earlier versions, so plan your deployment accordingly.
Full changelogs:
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/nodectl%2Fv0.5.1
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.8.0
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/helm%2Fnodectl%2Fv0.3.1
Lag protection on the fly, strict endpoint routing, and precise stake validation.
Nodectl protects your election decisions by automatically skipping lagging JSON-RPC endpoints before every request. Instead of unpredictable round-robin, it now enforces a strict priority-based fallback where the primary node carries all traffic and backups trigger only on failure, while periodic TTL cache refreshes eliminate frozen-stake accounting distortions.
On the node side, a new HTTP SSE endpoint enables real-time tracking of confirmed blocks. The latest update also delivers a major Cell DB performance boost via the RocksDB merge operator, along with further stability fixes.
⚠️Important: this release is non-revertible. Once upgraded, nodes cannot roll back to earlier versions, so plan your deployment accordingly.
Full changelogs:
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/nodectl%2Fv0.5.1
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.8.0
▪️ https://github.com/RSquad/ton-rust-node/releases/tag/helm%2Fnodectl%2Fv0.3.1
4👍4🔥3
TON Rust Node v0.8.2: Network & Performance Optimization
Enhanced QUIC transport and memory efficiency.
Introduces a block sync overlay for observer-mode validators and adapts custom overlays to the QUIC transport layer, now featuring SNI support. This release also delivers key memory optimizations, streamlines Simplex version propagation to the validator manager, and resolves state resolver cache issues in the collator for improved node stability.
Read the Changelog:
https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.8.2
Enhanced QUIC transport and memory efficiency.
Introduces a block sync overlay for observer-mode validators and adapts custom overlays to the QUIC transport layer, now featuring SNI support. This release also delivers key memory optimizations, streamlines Simplex version propagation to the validator manager, and resolves state resolver cache issues in the collator for improved node stability.
Read the Changelog:
https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.8.2
8❤9🔥8👍5
TON Rust Node v0.8.3: Block v14 Support
Preparing for the block version upgrade.
This release adds full support for the block version 14. It updates the TVM and the transaction executor to ensure node stability and seamless compatibility with the new block version.
Read the Changelog:
https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.8.3
Preparing for the block version upgrade.
This release adds full support for the block version 14. It updates the TVM and the transaction executor to ensure node stability and seamless compatibility with the new block version.
Read the Changelog:
https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.8.3
1❤7👍4🔥2