Nominator Pool 2.0
Nominator pools let Gram holders stake funds to support network validation and earn rewards without running their own validators.
Nominator Pool 2.0 replaces the original smart contract created in 2022 with a redesigned implementation in Tolk.
Key improvements:
— Up to 32 validators per pool, up from 1.
— Up to 512 nominators per pool, up from 40.
— Reward withdrawals without withdrawing the full stake.
— Lower gas fees.
— Automatic reimbursement of validator gas costs.
— Support for nominators on both the basechain and masterchain.
— A single pool for all validation rounds. Separate pool contracts for even and odd rounds are no longer required.
— A dedicated pool owner management role has been added, separate from validators and nominators.
The contract is fully open source, with comprehensive documentation, a management web UI, and MyTonCtrl support.
https://github.com/ton-blockchain/nominator-pool-v2#ton-nominator-pool-v2-smart-contract
Nominator pools let Gram holders stake funds to support network validation and earn rewards without running their own validators.
Nominator Pool 2.0 replaces the original smart contract created in 2022 with a redesigned implementation in Tolk.
Key improvements:
— Up to 32 validators per pool, up from 1.
— Up to 512 nominators per pool, up from 40.
— Reward withdrawals without withdrawing the full stake.
— Lower gas fees.
— Automatic reimbursement of validator gas costs.
— Support for nominators on both the basechain and masterchain.
— A single pool for all validation rounds. Separate pool contracts for even and odd rounds are no longer required.
— A dedicated pool owner management role has been added, separate from validators and nominators.
The contract is fully open source, with comprehensive documentation, a management web UI, and MyTonCtrl support.
https://github.com/ton-blockchain/nominator-pool-v2#ton-nominator-pool-v2-smart-contract
❤25⚡9✍8👍4🤩4👌3👀2🦄1
Updated staking smart contract lineup
Single-nominator (v1.1) — Direct validation with one validator and one nominator. The nominator receives 100% of the rewards.
Nominator-pool (v2) — Private staking pools with a small group of nominators and validators.
Liquid-staking — User-facing staking products with many depositors. Issues jettons representing staked Gram for use in DeFi. Used by @StakeeBot and Tonstakers.
Single-nominator (v1.1) — Direct validation with one validator and one nominator. The nominator receives 100% of the rewards.
Nominator-pool (v2) — Private staking pools with a small group of nominators and validators.
Liquid-staking — User-facing staking products with many depositors. Issues jettons representing staked Gram for use in DeFi. Used by @StakeeBot and Tonstakers.
❤24👍16🔥9🤝4🤡2
Forwarded from TOLK lang
🫧 Introducing new tools beyond smart-contract development
In May, we released Tolk v1.4 and Acton — a new toolchain for building and testing TON smart contracts.
Since then, we've been working on the next part of the problem.
Writing a contract is only the on-chain part of dApp development.
Once the contract is ready, you need an environment to work with the network, inspect transactions, verify deployed code, and run E2E scenarios — including the off-chain part.
So we've been extending Acton in that direction.
🔍 Actonscan
A developer-focused explorer built around Tolk ABI.
Messages, get-methods, errors and storage are displayed in human-readable format instead of raw bytes.
You can inspect transaction flows, emulate messages, call get-methods, explore storage mutations and network configuration.
Actonscan is based on an open-source ABI catalog with 200+ frequently used contracts, so even deployed FunC bytecode can be described through Tolk types.
Visit: actonscan.com and the ABI catalog.
🧪 Acton Studio
A local workspace for developing the off-chain part of a dApp.
Use TON Center and LiteAPI, test off-chain integration and cross-chain bridges, and check that an indexer correctly parses transactions.
Two environments are available:
Simulator — a fast, controllable local network. Start in 0.1 sec, fork mainnet, modify state of any account, mint jettons, time-travel
Localnet — a real TON network running actual C++ validators, liteservers and APIs in Docker.
Both can be used from the CLI, making them suitable for automation, E2E tests, CI, and agents.
Studio also provides UI for faucets, an embedded Actonscan, state/blocks/config view, and debugging transactions directly in the browser — for any local environment.
Try:
and follow the docs.
🔐 TON Verifier revisited
The new Verifier connects deployed code back to its source using code hash.
It provides the source code, ABI, and source maps. There is no IPFS involved — contract sources are kept on GitHub and served by a dedicated backend.
This means an explorer automatically understands a newly deployed contract once it's verified — showing human-readable traces and allowing failed transactions to be debugged step by step directly from the browser.
Visit: verifier.ton.org.
🌳 From contracts to dApps
Tolk is a language for smart contracts. With its auto-generated ABI, it provides the standard interface for external tools.
Acton covers the entire on-chain development lifecycle: testing, debugging, publishing, and everything around the contract itself.
Acton Studio extends that workflow to the off-chain layer of dApps — local networks and APIs, snapshots, and E2E integrations.
It's the natural next step: not just developing smart contracts, but building the applications around them.
In May, we released Tolk v1.4 and Acton — a new toolchain for building and testing TON smart contracts.
Since then, we've been working on the next part of the problem.
Writing a contract is only the on-chain part of dApp development.
Once the contract is ready, you need an environment to work with the network, inspect transactions, verify deployed code, and run E2E scenarios — including the off-chain part.
So we've been extending Acton in that direction.
🔍 Actonscan
A developer-focused explorer built around Tolk ABI.
Messages, get-methods, errors and storage are displayed in human-readable format instead of raw bytes.
You can inspect transaction flows, emulate messages, call get-methods, explore storage mutations and network configuration.
Actonscan is based on an open-source ABI catalog with 200+ frequently used contracts, so even deployed FunC bytecode can be described through Tolk types.
Visit: actonscan.com and the ABI catalog.
🧪 Acton Studio
A local workspace for developing the off-chain part of a dApp.
Use TON Center and LiteAPI, test off-chain integration and cross-chain bridges, and check that an indexer correctly parses transactions.
Two environments are available:
Simulator — a fast, controllable local network. Start in 0.1 sec, fork mainnet, modify state of any account, mint jettons, time-travel
blockchain.now, create snapshots, and reproduce scenarios locally.Localnet — a real TON network running actual C++ validators, liteservers and APIs in Docker.
Both can be used from the CLI, making them suitable for automation, E2E tests, CI, and agents.
Studio also provides UI for faucets, an embedded Actonscan, state/blocks/config view, and debugging transactions directly in the browser — for any local environment.
Try:
acton up
and follow the docs.
🔐 TON Verifier revisited
The new Verifier connects deployed code back to its source using code hash.
It provides the source code, ABI, and source maps. There is no IPFS involved — contract sources are kept on GitHub and served by a dedicated backend.
This means an explorer automatically understands a newly deployed contract once it's verified — showing human-readable traces and allowing failed transactions to be debugged step by step directly from the browser.
Visit: verifier.ton.org.
🌳 From contracts to dApps
Tolk is a language for smart contracts. With its auto-generated ABI, it provides the standard interface for external tools.
Acton covers the entire on-chain development lifecycle: testing, debugging, publishing, and everything around the contract itself.
Acton Studio extends that workflow to the off-chain layer of dApps — local networks and APIs, snapshots, and E2E integrations.
It's the natural next step: not just developing smart contracts, but building the applications around them.
❤33🔥26👍19🤯3😱2
Tolk 1.5 Programming Language
—
—
— Type aliases as directional subtypes.
— Reorganized purity concept and dead-code removal.
— Colorful compilation errors with multiple locations and hints.
— Several bytecode optimizations.
PR »
Author's notes »
—
@inline functions with multiple returns.—
break/continue in loops.— Type aliases as directional subtypes.
— Reorganized purity concept and dead-code removal.
— Colorful compilation errors with multiple locations and hints.
— Several bytecode optimizations.
PR »
Author's notes »
👍28🐳10⚡8❤5💩2🌭2🖕2💅2💊2👾2
TON Connect 5.0.0
TON Connect 5.0.0 is now available with improved support for Gram Wallet in Telegram.
dApp developers, please update:
Important: If your dApp uses
Many Mini Apps currently omit this fallback, which violates the specification and causes authentication to fail with Gram Wallet in Telegram.
TON Connect 5.0.0 is now available with improved support for Gram Wallet in Telegram.
dApp developers, please update:
@tonconnect/sdk@5.0.0@tonconnect/ui@5.0.0@tonconnect/ui-react@5.0.0Important: If your dApp uses
ton_proof, ensure your implementation follows the documentation, including the get_public_key fallback when the public key cannot be extracted from walletStateInit.Many Mini Apps currently omit this fallback, which violates the specification and causes authentication to fail with Gram Wallet in Telegram.
❤30🔥10😐9😁5😭3👾3☃2🦄2💊1
❤13🔥11👨💻6💊1
Telegram Wallet: Ecosystem Guidelines
— dApps: Update to the latest version of TON Connect. If your dApp uses
— Explorers: We recommend adding support for identifying and displaying Telegram Wallet accounts, displaying key rotation actions, and labeling gasless transactions (example).
— Standalone non-custodial wallets: When creating wallets in your app, continue using the
— dApps: Update to the latest version of TON Connect. If your dApp uses
ton_proof, verify that your implementation complies with the specification.— Explorers: We recommend adding support for identifying and displaying Telegram Wallet accounts, displaying key rotation actions, and labeling gasless transactions (example).
— Standalone non-custodial wallets: When creating wallets in your app, continue using the
wallet-v5r1 smart contract by default, as tg-wallet-v1 is designed specifically for Telegram. Please add support for importing and using existing tg-wallet-v1 wallets (instruction).❤29🥰12🔥8🤗4🌭2🖕2💊1
TON Node Update 2026.10
Security improvements
— Isolation of validators and collators from the public overlay.
— Automatic global balance verification.
Networking improvements
— Improved handling and delivery of external messages, including large messages.
— QUIC implementation improvements. RLDP2 is deprecated and will be removed in a future releases.
This release also includes additional fixes and improvements.
After the update, two separate validator votes will enable automatic global balance verification and Plumtree broadcasts in the public overlay. Plumtree is expected to improve block delivery even when the public overlay contains a large number of misbehaving nodes.
Full changelog »
Update instructions »
Security improvements
— Isolation of validators and collators from the public overlay.
— Automatic global balance verification.
Networking improvements
— Improved handling and delivery of external messages, including large messages.
— QUIC implementation improvements. RLDP2 is deprecated and will be removed in a future releases.
This release also includes additional fixes and improvements.
After the update, two separate validator votes will enable automatic global balance verification and Plumtree broadcasts in the public overlay. Plumtree is expected to improve block delivery even when the public overlay contains a large number of misbehaving nodes.
Full changelog »
Update instructions »
❤30👍21🔥12🥰2🖕2😴1💊1
The TON 2026.10 update reduced network traffic on validators (first chart). Traffic on a public overlay node also dropped after enabling the new Plumtree broadcasts (second chart).
Plumtree has also made block delivery in the public overlay significantly more stable.
The network capacity freed by these changes will be used to further increase the performance of TON shardchains.
Plumtree has also made block delivery in the public overlay significantly more stable.
The network capacity freed by these changes will be used to further increase the performance of TON shardchains.
👍39❤21👀11😁7🔥5🤬3🥰1😱1🤩1💊1
Understanding TON’s New Networking Architecture
Nearly every update over the past year has introduced incremental changes to TON’s network architecture to improve security, reduce traffic and increase performance.
As a result, TON’s network architecture has changed substantially. This article describes the new architecture.
1. Shared private overlays
The masterchain and each shardchain have a separate private overlay. Each now includes all validators (~400) and all collators.
Previously, these overlays included only their respective current validators and collators. Blocks were shared with the remaining validators and collators through a separate block-sync overlay. The block-sync overlay has now been removed, simplifying the network topology.
2. Protected overlay
The protected overlay serves critical infrastructure supporting the blockchain, including rebroadcaster nodes.
It was previously called fast-sync. That name is no longer appropriate: fast synchronization is a requirement for every overlay, including the public overlay. The protected overlay is intended to improve the security and stability of the blockchain and its critical infrastructure.
3. Validator and collator isolation
Validators and collators no longer communicate directly over the public overlay. Rebroadcasters forward blocks to the public overlay and relay external messages in the opposite direction.
This isolation improves security and reduces validators’ network traffic and CPU usage. The freed resources will be used to increase network performance.
4. Rebroadcasters
Rebroadcaster code is open source and will be merged into the main branch soon.
Like collators, rebroadcaster nodes are operated by some validator operators. Additional rebroadcaster deployments are not currently required.
5. Three broadcast types: Gossip, Two-Step and Plumtree
Two-Step Broadcast was developed as part of Sub-Second update for private validator overlays.
Plumtree Broadcast is a new Plumtree-like implementation designed for overlays with dynamic membership. It maintains reliable synchronization even when a large proportion of nodes perform poorly. It is used in the public and protected overlays. The implementation differs from the classic Plumtree algorithm but follows the same underlying ideas.
Gossip Broadcast, the original implementation, remains in limited use for some broadcast types.
6. Replacing RLDP1/2 with QUIC
QUIC was standardized in May 2021 as RFC 9000. TON’s initial networking implementation predated this standardization and used custom RLDP protocols for reliable data transfer, with functionality similar to QUIC.
During 2026, RLDP1/2 have been progressively replaced with QUIC. The next update will complete the migration, after which RLDP1/2 will no longer be used in the TON blockchain.
Nearly every update over the past year has introduced incremental changes to TON’s network architecture to improve security, reduce traffic and increase performance.
As a result, TON’s network architecture has changed substantially. This article describes the new architecture.
1. Shared private overlays
The masterchain and each shardchain have a separate private overlay. Each now includes all validators (~400) and all collators.
Previously, these overlays included only their respective current validators and collators. Blocks were shared with the remaining validators and collators through a separate block-sync overlay. The block-sync overlay has now been removed, simplifying the network topology.
2. Protected overlay
The protected overlay serves critical infrastructure supporting the blockchain, including rebroadcaster nodes.
It was previously called fast-sync. That name is no longer appropriate: fast synchronization is a requirement for every overlay, including the public overlay. The protected overlay is intended to improve the security and stability of the blockchain and its critical infrastructure.
3. Validator and collator isolation
Validators and collators no longer communicate directly over the public overlay. Rebroadcasters forward blocks to the public overlay and relay external messages in the opposite direction.
This isolation improves security and reduces validators’ network traffic and CPU usage. The freed resources will be used to increase network performance.
4. Rebroadcasters
Rebroadcaster code is open source and will be merged into the main branch soon.
Like collators, rebroadcaster nodes are operated by some validator operators. Additional rebroadcaster deployments are not currently required.
5. Three broadcast types: Gossip, Two-Step and Plumtree
Two-Step Broadcast was developed as part of Sub-Second update for private validator overlays.
Plumtree Broadcast is a new Plumtree-like implementation designed for overlays with dynamic membership. It maintains reliable synchronization even when a large proportion of nodes perform poorly. It is used in the public and protected overlays. The implementation differs from the classic Plumtree algorithm but follows the same underlying ideas.
Gossip Broadcast, the original implementation, remains in limited use for some broadcast types.
6. Replacing RLDP1/2 with QUIC
QUIC was standardized in May 2021 as RFC 9000. TON’s initial networking implementation predated this standardization and used custom RLDP protocols for reliable data transfer, with functionality similar to QUIC.
During 2026, RLDP1/2 have been progressively replaced with QUIC. The next update will complete the migration, after which RLDP1/2 will no longer be used in the TON blockchain.
❤39👍23🔥19🤣7🤝5😢3💊2😴1