On October 23, 2026, TON Status reported completion of the transition to new public-overlay broadcasts. It says updated 2026.10 nodes with working QUIC connectivity should have more stable connections, while nodes that did not upgrade would lose synchronization. This is an infrastructure notice, not an instruction for ordinary holders to move their recovery phrase into a new wallet.
The release and the completed transition are separate events
The v2026.10 release was published on October 19. Its notes describe changes to public overlays, improved external-message processing, QUIC optimization and deprecation of RLDP2 with removal planned later. A release being available and a network transition being declared complete answer different questions; October 19 and October 23 should not be collapsed into a single date.
The earlier operator schedule placed node updates before configuration voting and set a Friday, October 23 deadline for full-node readiness, including QUIC. Those were operator duties. A person using a wallet application should not interpret a node deadline as an expiry date for their address or a demand to restore their wallet elsewhere.
Transport terminology does not describe a replacement coin
Public overlay and QUIC describe infrastructure in this announcement. RLDP2 being deprecated does not establish a deadline to exchange a token, and a newer node release is not itself a new wallet contract. If someone presents an urgent ‘TON 2026.10 migration’ link, ask what official holder action it supposedly implements. The cited notices do not provide a seed-import procedure for holders.
A stale node view can look like a wallet problem
| What you observe | Question to ask | Conclusion to avoid |
|---|---|---|
| A self-operated node stops advancing | Is it updated and meeting the announced connectivity requirements? | All TON transactions have stopped |
| A wallet screen shows old activity | Which data service supplies that screen? | A balance has necessarily been lost |
| A transaction appears in one view only | Are the observations current and about the same transaction? | The first view proves final receipt |
| A service reports its own maintenance | Which sending or crediting operations are affected there? | The node announcement specifies that service's reopening time |
The table is a diagnostic reading aid, not a live assessment of any provider. Imagine two views with different last-updated times: the older one cannot settle the state of an operation created after its displayed history. Record the timestamp and transaction reference before attributing the discrepancy to a failed payment. A second current source can help describe the discrepancy without authorizing a replacement transfer.
Choose actions according to your role
- If you operate a node, compare its installed release and synchronization with the official operator requirements.
- If you only use a wallet, check the wallet or service's own notices rather than changing server ports yourself.
- For a delayed operation, distinguish an unsigned request, a submitted transaction and a recipient's separate crediting record.
- Preserve timestamps and transaction references, and send that non-secret evidence to the relevant provider.
- Do not create another payment merely because one display is stale or a message claims the transition requires it.
Opening arbitrary ports on a personal computer is not a holder-level response to this notice. A provider running infrastructure is responsible for diagnosing its endpoint. If you run that infrastructure yourself, use the official deployment instructions for your actual installation; this article does not supply a universal network configuration or test a server's QUIC reachability.
What the completion report still cannot prove
The report describes the transition and the expected behavior of correctly prepared nodes. It does not inspect your wallet, certify that every service upgraded, confirm an individual transaction or announce an exchange's accounting result. Keep those questions separate when requesting support. A network-level improvement does not eliminate every unrelated application or custody issue.
Keep later exchange instructions tied to the actual order
Before an ordinary no-account swap, check the supported assets and exchange process for the exact sending route. The TON infrastructure notice does not establish KOT.CASH route availability, change its deposit instructions or extend an existing order. Resolve uncertainty about a prior payment before deciding whether another operation is needed.
Check subsequent operator updates alongside the October 23 completion statement from TON Status. The release notes alone are not proof of deployment, while the completion notice is not a measurement of every participant. No wallet, node, explorer account or transfer was tested in preparing this review.
FAQ
Does the TON node update require me to restore my wallet?
The cited transition notices concern node operators and their infrastructure. They do not provide a recovery-phrase migration requirement for ordinary holders.
Does TON network status prove my particular transfer arrived?
A network-level announcement does not inspect an individual payment or a recipient's crediting record. Check the actual transaction and the relevant service's own state.
Can a TON node RPC view be stale after the transition?
TON Status warns that nodes which did not upgrade would lose synchronization. Establish the data source and its currentness before using its output to judge a new payment.