The TON Core team is working to enable transactions on the TON blockchain to be executed in less than 1 second β with no reduction in decentralization or scalability.
We have expanded the dev team and continue to implement the Optimization Roadmap that was published and partially completed earlier this year. Major L1 and API updates are ahead.
We plan to show the results in the TON main network as early as the first half of next year.
We have expanded the dev team and continue to implement the Optimization Roadmap that was published and partially completed earlier this year. Major L1 and API updates are ahead.
We plan to show the results in the TON main network as early as the first half of next year.
π41π€―27π€©13β€6π³4π€‘3π€2π₯1π1π1
TON x Chainlink
The TON Core team was happy to help Chainlink integrate their product with TON.
Chainlink smart contracts are written in our new programming language, Tolk.
Meanwhile, we contributed to 3 more big upcoming releases β all starting or ending with βC.β
The TON Core team was happy to help Chainlink integrate their product with TON.
Chainlink smart contracts are written in our new programming language, Tolk.
Meanwhile, we contributed to 3 more big upcoming releases β all starting or ending with βC.β
X (formerly Twitter)
Chainlink (@chainlink) on X
.@ton_blockchain, the L1 bringing Web3 to Telegramβs 900M+ users, is adopting Chainlink CCIP as the canonical cross-chain infrastructure for its native token TON, making it a Cross-Chain Token (CCT) to be transferable across leading blockchains.
https:/β¦
https:/β¦
π30π₯21π€―9β€6π©4π3π€£2π₯°1
Node Update TON 2025.10, TON 2025.11
β Optimistic collation & validation: nodes can generate and verify block candidates before the previous block is fully finalized.
β New block compression algorithm.
β Enhanced overlays, peer discovery, and sync.
β Various improvements and fixes.
Full Changelog Β»
β Optimistic collation & validation: nodes can generate and verify block candidates before the previous block is fully finalized.
β New block compression algorithm.
β Enhanced overlays, peer discovery, and sync.
β Various improvements and fixes.
Full Changelog Β»
β€12π₯9π―4
Blockchain configuration updated
The following improvements to the TON blockchain configuration were made by a network-wide vote of validators:
1. The parameter for launching BTC Teleport has been updated.
2. Updated system configuration smart contract code:
β Removed code related to an unused configuration key. Note that the configuration key itself was reset back in 2023.
β Added custom slot functionality that will be useful for stablecoins.
The following improvements to the TON blockchain configuration were made by a network-wide vote of validators:
1. The parameter for launching BTC Teleport has been updated.
2. Updated system configuration smart contract code:
β Removed code related to an unused configuration key. Note that the configuration key itself was reset back in 2023.
β Added custom slot functionality that will be useful for stablecoins.
π₯17β€7β‘7
TVM 12
β Bounced messages can now include the full message body, error code, and additional data.
β New low-cost TVM instructions.
β Various improvements and fixes.
Full Changelog Β»
β Bounced messages can now include the full message body, error code, and additional data.
β New low-cost TVM instructions.
β Various improvements and fixes.
Full Changelog Β»
π₯19β‘9π€©7β€2
Tolk 1.2 Programming Language
β Rich bounced messages support (TVM 12).
β Cheaper smart-contract deployment thanks to new TVM 12 capabilities.
β Redefined address type.
β Improved compilation errors.
β Anonymous functions (lambdas).
β Borrow checker to catch undefined behavior.
Read more Β»
β Rich bounced messages support (TVM 12).
β Cheaper smart-contract deployment thanks to new TVM 12 capabilities.
β Redefined address type.
β Improved compilation errors.
β Anonymous functions (lambdas).
β Borrow checker to catch undefined behavior.
Read more Β»
π₯14π10β‘7β€2β€βπ₯2π₯°1
TON Docs
Tolk β the language for TON - TON Docs
π23β‘21π14π5π2β€1
TON Core pinned Β«The TON Core team is working to enable transactions on the TON blockchain to be executed in less than 1 second β with no reduction in decentralization or scalability. We have expanded the dev team and continue to implement the Optimization Roadmap that wasβ¦Β»
Node Update TON 2025.12
CellDB 2.0 and the Fast State Serializer are now enabled by default.
The validator engine gains parallelism, network traffic compression is improved, along with various fixes and enhancements.
Full Changelog Β»
CellDB 2.0 and the Fast State Serializer are now enabled by default.
The validator engine gains parallelism, network traffic compression is improved, along with various fixes and enhancements.
Full Changelog Β»
π35π₯°12π₯10π±5β€3π3π2π€―1
The R&D phase has been completed β research and development of the task of speed up operations in the TON blockchain to less than 1 second while maintaining scalability, security, and decentralization.
During the work, three key areas were identified that, taken together, will allow the desired result to be achieved.
1. L1 and Node improvements
1.1. New Catchain 2.0 consensus
The current Catchain + BCP consensus stack has been replaced with a new protocol β Catchain 2.0, based on Simplex / Alpenglow algorithms adapted to the TON architecture.
The consensus protocol determines how validators share data, verify and accept blocks with transactions.
Simplex and Alpenglow are modern open consensus protocols that are characterized by high speed and relative simplicity.
Catchain 2.0 allows blocks to be finalized in 200β400 milliseconds while maintaining the same level of security. Previously, the block finalization time was about 2.5 seconds.
An additional advantage in terms of security is the widespread knowledge of these protocols, which greatly simplifies their audit.
1.2. New block broadcast protocol β "two-step" broadcast
Blocks are transferred between network nodes using the broadcast protocol. We have redesigned this network protocol, reducing the block delivery delay from approximately 700 ms to ~100 ms.
1.3. Additional optimizations
A number of additional optimizations have also been made to the C++ implementation of the TON node, including:
β block compression during transmission;
β parallelization of validation;
β the ability to exchange data between validators not only via the RLDP2 protocol, but also via TCP or QUIC. Based on the test results, it may be possible to switch to one of these protocols.
In addition to the main solutions, the internal statistics system was refined, as well as the internal tools for benchmarks and measurements for nodes, validators, and API.
2. API
2.1. Reduced API latency
The Toncenter API has been optimized, resulting in a latency of 30β100 milliseconds for obtaining the status of an operation via the Streaming API V2.
2.2. New functionality
Streaming API V2 in Toncenter now returns two statuses of operation instead of one:
confirmed β the block has appeared in the shardchain;
finalized β the block has been accepted into the masterchain.
Previously, only the finalized status was supported.
3. UX
A new UX approach has been proposed. Since an operation with the confirmed status has a rollback probability of less than 1%, applications can display it to the user at this stage. The user can then immediately perform the following operations without waiting for finalization.
At the finalized stage, the application can additionally mark in the UI that the operation is completely finalized.
This is similar to the confirmation model in other blockchains, where the operation is displayed after being included in the first block, and final finalization occurs after several block confirmations β at the same time, the user can immediately continue interacting with the blockchain.
This is a solid addition to last year's UX and kernel updates.
All of the above components have been completed separately. Component integration is underway, followed by testing on the TON test network.
During the work, three key areas were identified that, taken together, will allow the desired result to be achieved.
1. L1 and Node improvements
1.1. New Catchain 2.0 consensus
The current Catchain + BCP consensus stack has been replaced with a new protocol β Catchain 2.0, based on Simplex / Alpenglow algorithms adapted to the TON architecture.
The consensus protocol determines how validators share data, verify and accept blocks with transactions.
Simplex and Alpenglow are modern open consensus protocols that are characterized by high speed and relative simplicity.
Catchain 2.0 allows blocks to be finalized in 200β400 milliseconds while maintaining the same level of security. Previously, the block finalization time was about 2.5 seconds.
An additional advantage in terms of security is the widespread knowledge of these protocols, which greatly simplifies their audit.
1.2. New block broadcast protocol β "two-step" broadcast
Blocks are transferred between network nodes using the broadcast protocol. We have redesigned this network protocol, reducing the block delivery delay from approximately 700 ms to ~100 ms.
1.3. Additional optimizations
A number of additional optimizations have also been made to the C++ implementation of the TON node, including:
β block compression during transmission;
β parallelization of validation;
β the ability to exchange data between validators not only via the RLDP2 protocol, but also via TCP or QUIC. Based on the test results, it may be possible to switch to one of these protocols.
In addition to the main solutions, the internal statistics system was refined, as well as the internal tools for benchmarks and measurements for nodes, validators, and API.
2. API
2.1. Reduced API latency
The Toncenter API has been optimized, resulting in a latency of 30β100 milliseconds for obtaining the status of an operation via the Streaming API V2.
2.2. New functionality
Streaming API V2 in Toncenter now returns two statuses of operation instead of one:
confirmed β the block has appeared in the shardchain;
finalized β the block has been accepted into the masterchain.
Previously, only the finalized status was supported.
3. UX
A new UX approach has been proposed. Since an operation with the confirmed status has a rollback probability of less than 1%, applications can display it to the user at this stage. The user can then immediately perform the following operations without waiting for finalization.
At the finalized stage, the application can additionally mark in the UI that the operation is completely finalized.
This is similar to the confirmation model in other blockchains, where the operation is displayed after being included in the first block, and final finalization occurs after several block confirmations β at the same time, the user can immediately continue interacting with the blockchain.
This is a solid addition to last year's UX and kernel updates.
All of the above components have been completed separately. Component integration is underway, followed by testing on the TON test network.
π₯52π28β€22β‘6π¦2