TON Core v2026.05-rc: what's in the new network release

On May 25, 2026, the TON team shipped the TON Core v2026.05 release candidate — a large planned update to the main network node. The build merges 33 pull requests, and among them there’s at least one change that affects every smart-contract developer (TVM v14) and several serious infrastructure fixes that matter to validators.

Here’s what’s inside and who should update now vs wait for stable.

TVM v14: a new virtual machine version

The headline change for smart-contract developers is the upgrade of TVM (TON Virtual Machine) to version 14. Every TON smart contract executes inside the TVM, and any change to its opcode set potentially:

• shifts gas usage in already-deployed contracts (usually downward, but edge cases exist);
• adds new instructions the compiler can emit in new contract versions;
• closes old edge cases.

The exact instruction list and gas-model changes will be clear from the final stable tag and accompanying docs. Before stable, we recommend not changing gas-sensitive code in production, but reading the changelog ahead of time makes sense — especially if your contracts are expensive to execute.

In parallel with Core, the team shipped Tolk 1.4.1 — a minor update to the smart-contract language replacing FunC. Tolk and TVM evolve together: new TVM opcodes often become the first optimisation targets for the Tolk compiler.

Consensus cleanup: catchain is gone

A few years ago, TON used catchain — its own BFT-based validator consensus mechanism. Since the Simplex release it has been legacy, and in v2026.05-rc the team fully removes catchain from the repository.

What this means:

• For network users — nothing visible. Transaction finality, block times, and validator behaviour stay the same, because Simplex has been live for a while.
• For validator operators — less code in the node, fewer failure paths, simpler diagnostics. Configs that still reference catchain (if any remain in custom overrides) can be deleted.
• For core developers — final closure of a large legacy branch that previously consumed hours of support load.

In parallel, the team improved Simplex slot handling: “Do not treat Simplex slots unaccepted by manager as normal” — a fix for the edge case where the manager rejects a slot but the node was still counting it as normal.

Networking stack: new overlays and adnl-proxy removed

In v2026.05-rc, the team modernised several layers of the networking stack:

Block-sync overlay. Block candidates now flow through a dedicated block-sync overlay rather than the shared channel. This separates traffic: messages critical for finality latency travel separately from utility traffic, lowering the risk of stalls under peak load.

Disable legacy RLDP for full-node shard inbound. RLDP is the reliable-delivery layer on top of ADNL. The old RLDP is no longer used for incoming messages on full nodes processing shards. This is movement toward RLDP2, which is now the main transport.

adnl-proxy removed. An entire component that allowed proxying ADNL traffic through dedicated nodes has been removed from the repository. With the new networking architecture the need has gone — users get fresh data through standard ADNL channels.

For ordinary nodes (lite-servers serving wallets, for example) these changes are internal optimisations. For node-cluster operators — worth checking configs: if any reference adnl-proxy as part of a path, it won’t pick up after the update.

Validators: weight cap and explicit readiness signaling

Two validator-focused changes:

Cap validator set total weight. The total weight of the validator set now has an upper bound. Previously, a specific combination of stakes and epoch parameters could theoretically yield excessive voting concentration at a large validator. Now this is bounded at the protocol level.

Explicit startup-readiness signaling in validator-engine. The validator engine now explicitly signals readiness after startup. This is critical for orchestrating validator clusters (Kubernetes, systemd with dependencies, custom tooling) — previously you had to guess from logs whether the node was ready to accept validator duties.

Liteserver: get shard client state. The lite-server gets a new method to expose shard-client state. Useful for indexers and analytics services.

If you operate a validator, these changes are good for production — but in production take them only from the stable tag.

Smaller fixes and dev tooling

A few less prominent but useful patches:

• Fix bad assertion in MtCarloComputeShare — fix an incorrect assert in share computation. Not a critical bug, but removes a source of false panics under load.
• Fix wrong getOriginalFwdFee formula in docs — the getOriginalFwdFee formula in the docs was corrected. Smart-contract developers: check whether you’re computing forward-fee by the old formula in your own contracts.
• Fix persistent state split part formatting — the output format for persistent state split parts.
• Switch to clang-format-22 for linting — linter update. External contributors will need a fresh clang-format locally.
• tontester: Add FullNode.fullnode_key getter — test infrastructure expansion.
• Remove old-style BlockId formatting — the old BlockId output format is gone.
• Remove two CMake options — build configuration simplification.

Who should do what

When to expect stable

The team doesn’t publish a date for the v2026.05 stable. Based on the rhythm of prior releases, stable typically ships 1–4 weeks after an RC — provided no critical bugs surface on testnet. The releases page in ton-blockchain/ton is the best place to watch.

For broader context on network upgrades — Simplex, sharding, bridge updates — see our TON roadmap Q2-Q3 2026 piece. If you want to understand how sharding (the foundation TVM sits on) works today, see how TON sharding works.