After the Speed: TON's June Update Fixes the Harder, Less Glamorous Half

The April upgrade that pushed confirmation times under a second is out of scope here. You've probably heard about it already.

But speed was never the finish line. The real test of a chain is the moment some project blows up and everyone rushes in to grab it at the same second. It can run smooth on a quiet day and still seize up under a stampede, and that is the dividing line. TON's June update is about exactly that, the harder and less glamorous things that come after "fast."

Two things happened this week

On June 1, every machine that maintains the chain (the validators) was required to install new node software at the same hour. On June 3, they vote on-chain to decide whether to switch on the new abilities that software carries.

The voting part is worth a pause. TON doesn't change its own rules because some company flips a switch. The validators pass them by an on-chain vote, in the open, and anyone can watch what's being voted on and where it stands on a dashboard like lagus.cooking. Rule changes laid out in daylight and decided by the participants, that alone is worth noting.

What's up for the vote is mostly a handful of improvements.

First, the most direct one: keeping the network steady when it's crowded

The machines that maintain the chain are constantly passing freshly made "draft blocks" back and forth to confirm each other. Until now those drafts shared the same road as ordinary traffic. This update opens a dedicated express lane just for them, so drafts move faster and clog less, and it also raises how much data each block can carry, which lifts how much the network can chew through per unit of time.

What that means for you is direct. Next time some hot mint, airdrop, or meme coin opens and a crowd pours in at the same second, the chance of the chain seizing up and your app spinning forever goes down. Speed is what you feel on a normal day. This is what holds the line in a traffic jam. Two different things.

Next, an upgrade to the "brain" that runs contracts

The engine that runs every TON contract steps up to a new version on mainnet. The part you'll feel most: it now understands signatures made by Ethereum wallets. Before, if you wanted to use a MetaMask-style Ethereum wallet to authorize something on TON, someone had to bolt on a translation layer in the middle, and it often broke. Now contracts read it directly, and one more barrier between the two ecosystems comes down.

It also quietly aligns a contract's fee "estimate" with what actually gets charged, so you'll see fewer cases of "the screen says one number, the deduction is another." To be clear: this is not cheaper fees, it's a more honest quote.

And one few people will notice: rebalancing staking

Staking got attractive lately, a lot of capital poured in to become validators, and the entry bar got pushed up as a result. When the bar climbs, smaller validators risk getting squeezed out, and the network drifts toward concentration in a few large hands, which is not a good look for a chain that calls itself decentralized. This change loosens an internal rule that was choking that, so validators near the minimum don't get thrown off the bench as the bar rises.

I owe you an honest line here. The same change also hands the big players more room, letting more of their capital count as effective weight, so it isn't beating down the whales. It's leaving the small players a way to survive while the bar rises. And it doesn't touch the staking reward formula at all, so what you earn follows the same rule as before. If you stake through a pool or a staking service, what this means for you is simple: the validator you're betting on holds its seat a little more securely.

A word on the bridge

This batch of votes also includes a more administrative item: flipping a few on-chain switches to formally begin retiring the old cross-chain bridge that shuts down for good on September 1. If you still hold assets bridged over from Ethereum years ago, remember to bridge them back before it closes. I've covered that before, so I won't go long on it here.

Finally, a contrast worth sitting with

April's "it got faster" made headlines because it was easy to grasp, easy to tell, and the numbers looked good. Nothing in the June batch is a slogan: hold up under congestion, recognize one more kind of signature, keep small validators from being squeezed out. They aren't sexy. And yet these unglamorous follow-ups are exactly what decides whether last month's speed survives real traffic.

What's even more worth chewing on is the how. Not one of these was forced through by someone's decree. They were written into the software, laid out in the open, and switched on only if the validators vote them in, with you able to watch the whole thing on a public board. How a chain changes its own rules matters as much as how fast it runs. This June, it changed the latter and put the former on display.

For those who want to go deeper: a map of this update

(Reminder: June 1 is the mandatory new node binary. Items marked "vote" only switch on via the June 3 on-chain vote and are not in effect as of June 1.)

• Mandatory node release: ton-blockchain/ton v2026.05 (published 2026-05-31; RC v2026.05-rc 2026-05-25). Highlights: block candidates over a dedicated block-sync overlay, multiple collation/validation/block-application performance optimizations, TVM v14 code, removal of legacy code (catchain / adnl-proxy / rldp1).
• Config8 (vote): set TVM version to 14 + enable the full_collated_date capability. v14 behavior is in doc/GlobalVersions.md (Version 14 section): SENDMSG fee estimate aligned with the actual charge, ECRECOVER accepts Ethereum's v=27/28, RIST255/CHKSIGN fixes, action-phase bounce change. Code in PR #2392. The v14 code sat on the testnet branch in May; mainnet activation comes from this vote.
• Config30 (vote): enable_observers 0→1, turning on the dedicated overlay for fast block-candidate broadcasts between validators. Code in PRs #2380, #2382, shipped in v2026.05, dormant until voted on.
• Config29 (vote): max_collated_bytes set to 10 MB (consensus / CatchainConfig parameter). Related collated-data optimizations in PR #2384.
• Config17 (vote): max_stake_factor 3→4.5. Field defined in crypto/block/block.tlb (min_stake / max_stake / min_total_stake / max_stake_factor). Effective-stake formula in crypto/smartcont/elector-code.fc (true_stake = min(stake, (max_f × smallest_stake) >> 16), where factor 1.0 = 65536). Rewards are distributed in proportion to effective stake, which is why the official note says "won't affect rewards." Thresholds 824,000 / 2,425,000 → expected 1,000,000 / 3,000,000 TON (TON Status, 2026-05-02).
• Config79/80/81 (vote): bridge address changes to proceed with the bridge-v3 shutdown (permanent on September 1).
• Governance: these config changes are all decided by on-chain validator voting; lagus.cooking (@lagus_research) reads the live mainnet config contract and renders the proposals in plain English.

Honest note: I did not verify the exact field definitions for Config29/30 or the full_collated_date flag name against source, so those rest on the official announcement; the rest (the release, Config8/17, the overlay PRs) are matched to source or release notes.