TON Rust Node Update v0.1.2

Winner winner, update dinner. Welcome back, builders!

This production-tuned update brings better observability, solid health checks, and a few performance wins.

What’s inside:

— Prometheus metrics
Exposes 51 Prometheus metrics across 8 subsystems, served at GET /metrics on the metrics port (default 9100).

— Liveness and readiness probes
Adds /healthz and /readyz to the metrics HTTP server alongside /metrics, so Kubernetes can use the same port for health checks. Currently both endpoints return HTTP 200 when the metrics server is running.

— Grafana dashboard out of the box
Ships with a bundled Grafana dashboard and a recommended Prometheus and Grafana setup for Kubernetes deployments, so you can start monitoring without building dashboards.

— Helm chart 0.2.0
Pins the image tag to a specific version, parameterizes the init container image via initImage.*, and changes the default pullPolicy from Always to IfNotPresent for more predictable deployments.

Full changelog: https://github.com/RSquad/ton-rust-node/releases/tag/v0.1.2-mainnet

Helm Update v0.3.0

Fresh bread from the Helm bakery. Chart bends, no forked end.

Best wishes to Kiln for shaping this release with real ops insight.

What’s inside:

— Extensibility hooks
Supports extraInitContainers, extraContainers, extraVolumes, and extraVolumeMounts for init steps, sidecars, and mounts.

— Production integrations
Supports podAnnotations, podLabels, and serviceAccount for common platform integrations like Vault, IAM, service mesh, and cost tracking.

— Env injection
Supports extraEnv and extraEnvFrom to pass ConfigMaps, Secrets, and Downward API into the main container cleanly.

— Networking and access control
Moves to per-port Services and hostPort, with optional NetworkPolicy for public ADNL and TCP CIDRs.

One more polish:

— ServiceAccount toggle rename
serviceAccount.create renamed to serviceAccount.enabled for consistency with other toggles.

Docs patched up:

— Logger targets documented
Updates documentation with additional logger targets for core components.

— Logging note
Note added that HTTP request logging is not available.

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

Helm Update v0.3.1

This update is so small it barely deserves a notification. Go back to sleep, DevOps.

What’s inside:

— imagePullSecrets
Support for private registries. Because sometimes your containers need a "Do Not Disturb" sign.

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

Nodectl Release v0.1.0

Validators soon just became validators now. Image is out. May your first election be intentional.

What’s new:

— Validators are live
Validator election management is available via the Nodectl.

— nodectl setup guide
Covers validator deployment and election flow.

— Key management for validators
Fullnodes can keep keys in config.json. Validators use an encrypted vault via secrets_vault_config.

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

Helm Update v0.3.2

Older charts might misbehave with this update. Changes may be incompatible, so upgrade carefully.

What’s new:

— storage.<volume>.resourcePolicy
Adds configurable helm.sh/resource-policy per volumeClaimTemplate. Defaults: keep for main/keys; omitted for db/logs.

— storage.<volume>.annotations
Adds extra annotations per volume PVC.

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

TON Rust Node Updates v0.2.1 & Helm v0.4.0

Big node bump, tiny hotfix, loud Helm changes. The classic trilogy.

Node Update v.0.2.1

What’s inside:

— Collator dispatch queues
Deferred messages with dispatch queues, per-account processing, and configurable limits.
— TVM emulator
TVM emulator with C FFI for transaction emulation and runGetMethod.
— Liteserver stability
Stabilized liteserver responses on fresh blocks.
— Storage and Merkle improvements
CellsDB bugfixes and performance improvements, plus Merkle update speedup via apply_for_with_cells_loader.
— Control server access
Anonymous client access with no explicit authorization required.
— Secrets vault compatibility
Backward compatibility for vault files created by v0.1.x.

Also:

— Image repo moved to ghcr.io/rsquad/ton-rust-node/node
— Vault connection is now configured via environment variables only.
— StorageCell renamed to StoredCell.
— JSON-RPC sendBoc payload limit removed.
— Fixes across validator sessions, storage limits, and TVM JSON import/export.

Full changelogs:
▪️v0.2.0: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.2.0-mainnet
▪️ v0.2.1: https://github.com/RSquad/ton-rust-node/releases/tag/node%2Fv0.2.1-mainnet

Helm Update v0.4.0

What’s inside:

— Chart renamed
Changed from ton-rust-node to node.
— Chart OCI moved
From oci://ghcr.io/rsquad/helm/ton-rust-node to oci://ghcr.io/rsquad/ton-rust-node/helm/node.
— Default image repo updated
Changed from ghcr.io/rsquad/ton-rust-node to ghcr.io/rsquad/ton-rust-node/node.
— Vault config via chart values
secrets_vault_config in config.json is no longer supported, use vault.url / vault.secretName / vault.secretKey and VAULT_URL env var.
— NetworkPolicy redesigned
Per-port ingress rules, allowCIDRs removed, use per-port allowFrom. TCP ports now require explicit enabled true, ADNL remains public by default.

Additionally:

— Service labels
services.<port>.labels for all service types, plus per-replica label overrides for ADNL.
— Helm templating support
extraContainers, extraInitContainers, and nodeConfigs values now support Helm templating.

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

Nodectl Update v0.1.1

Wallets evolve. Tooling keeps up.

What’s inside:

— V1R3 Wallet Support
The nodectl now support the V1R3 wallet type.

— Simplified Configuration
subwallet_id has no effect for V1R3 wallets and is ignored.

— Helm Chart Update (v0.1.2)
Default nodectl image tag is now v0.1.1, so new installs pick up V1R3 support by default.

Full changelogs:
▪️v0.1.1: https://github.com/RSquad/ton-rust-node/releases/tag/nodectl%2Fv0.1.1
▪️v0.1.2: https://github.com/RSquad/ton-rust-node/releases/tag/helm%2Fnodectl%2Fv0.1.2

Nodectl Update v0.2.0

The control room just got smarter. More signal, less manual babysitting, and wallets that don’t live in the last century.

What’s inside:

— Supports Wallet V4/V5
Adds wallet contract v4/v5 support with address verification and code hash validation.

— ton-http-api multi-endpoint failover
Adds round-robin failover across multiple TON HTTP API endpoints with per-endpoint API keys, plus ton-http-api add to append endpoints.

— Node and pool visibility
Adds control server status to config node ls and resolved pool addresses with live balances to config pool ls.

— Logging that’s actually configurable
Moves logging into the JSON log section with rotation, limits, and console or file output. Adds config log ls and config log set for quick updates without manual edits.

— Vault reload on config reload
Reopens the vault on each config reload so newly added secrets are picked up without a service restart.

— Control HTTP server updated
Migrates the control HTTP server to Axum.

One more fix:

— Wallet deployment deduplication
Deploys a wallet only once even if it’s configured for multiple nodes.

— Wallet send polish
Fixes --bounce handling, clarifies the default confirmation prompt, and makes wallet version input case-insensitive.

Plus a bunch of smaller fixes and docs updates.

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

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.