On April 10th, TON activated Catchain 2.0 on mainnet. Block time dropped from 2.5 seconds to 400 milliseconds. Finality dropped from 10 seconds to approximately one second. Pavel Durov called it step one of seven in a structured upgrade roadmap.
Most coverage focused on the speed numbers. This post focuses on something most developers haven't thought about yet: what a 10x performance upgrade does to your infrastructure stack.
What Actually Changed Under the Hood
Catchain 2.0 is a complete replacement of TON's consensus mechanism. It doesn't patch the old approach - it discards it entirely.
The practical result:
| Metric | Before | After |
|---|---|---|
| Block time | ~2.5s | 400ms |
| Finality | ~10s | ~1s |
| Block rate | baseline | 6x higher |
The upgrade also introduced Streaming API v2 - a new layer that pushes state updates to applications the moment a block lands. Instead of polling the chain for new data, apps can subscribe to a stream and receive updates in real time.
Durov's recommendation for developers is direct: update your apps to use Streaming API v2. The chain is already real-time. The app layer needs to catch up.
The Infrastructure Problem Nobody Is Talking About
Here is the thing about blockchain performance upgrades that rarely makes the announcement post.
When a chain gets 6x more blocks per second, every application querying that chain gets 6x more traffic to handle. Every app, every bot, every indexer that hits a TON endpoint is now making roughly six times as many requests as it did last week.
That number gets bigger when you account for the user growth that faster, cheaper transactions are supposed to attract.
Public nodes were not designed for this pattern. The rate limits that were invisible before become hard ceilings. Free shared endpoints start dropping requests under load. Applications that worked reliably yesterday begin failing in ways that are difficult to debug - not because your code changed, but because the underlying traffic volume did.
This is the gap between a protocol upgrade and production reliability. And it is a gap that most developers discover at the worst possible time: after they have already shipped.
What This Means If You Are Building on TON Right Now
If you are using public or free shared RPC endpoints:
Test your request volume against the new block rate. If your application queries per block or subscribes to events, your baseline traffic just increased 6x. Check whether your current endpoint handles that load before your users do.
If you are polling for state updates:
Switch to Streaming API v2. Polling was already inefficient at 2.5 second blocks. At 400ms it creates unnecessary load on both your infrastructure and the node you are querying. Streaming is the correct pattern for real-time applications on the post-Catchain network.
If you are running a payment application or Mini App:
Subsecond finality changes what you can promise users. A payment that previously took 5-10 seconds to confirm now confirms in under a second. That is a meaningfully different UX. But it only holds if your infrastructure can keep up with confirmation requests at the new throughput.
If you are building high-frequency DeFi:
Arbitrage bots, liquidation bots, and on-chain order book logic that was not viable at 2.5 second block times now becomes worth reconsidering. The infrastructure requirement for these use cases is even more demanding - you need low-latency dedicated access, not shared endpoints.
The TAC Angle
One upgrade-adjacent development worth noting: TAC, the EVM-compatible execution layer on top of TON, benefits from the same underlying performance improvements. If you are building Solidity-based applications that need to interact with the TON ecosystem - including Telegram Mini Apps - TAC gives you EVM tooling with TON-native distribution. That combination becomes more compelling as the base layer gets faster.
Evaluating Your Stack
Before Catchain 2.0, many TON applications could get away with shared public endpoints. The traffic volume was manageable and the performance requirements were forgiving.
That calculus has changed. The practical checklist for any team with a TON application in production:
- Measure your current RPC request rate per minute
- Multiply by 6 to estimate the new baseline under Catchain 2.0
- Check whether your current endpoint's rate limits accommodate that number
- If not - or if you have no visibility into those limits - switch to a dedicated endpoint before the traffic increase catches you
At GetBlock, we provide dedicated and shared TON RPC nodes built for this kind of load. Dedicated nodes give you guaranteed throughput and latency isolation - no competing with other applications for capacity on a shared endpoint. We also support TAC nodes for teams building on the EVM layer.
If you want to test your current setup, the simplest approach is to run a load simulation at 6x your current request volume and watch for rate limit errors or degraded response times. Better to discover the ceiling in a test than in production.
The Bigger Picture
Catchain 2.0 is step one of seven in the MTONGA roadmap. Step two - a 6x reduction in transaction fees - has been announced but not yet scheduled. If that lands as described, TON will have subsecond finality and fees around $0.0005 per transaction.
That combination - fast, cheap, with a billion-user distribution channel through Telegram - makes TON infrastructure worth taking seriously. The builders who will benefit most are the ones who have their stack ready when the user growth arrives, not the ones scrambling to upgrade after it does.
The chain is already real-time. The question is whether your infrastructure stack is.
Running Web3 is a show by GetBlock covering the technology that actually powers the Web3 industry. Episode 8 covers the full MTONGA roadmap and what Catchain 2.0 means for builders.
GetBlock provides RPC node access across 130+ blockchains including TON and TAC. Explore TON nodes or TAC nodes.