TON Blockchain v6.1.0

Release Date: September 4, 2026 Tags: WITHDRAWALS, REFUNDS, RELIABILITY, TON

Overview

Two ways a TON withdrawal could pay the wrong amount, in opposite directions. A withdrawal larger than the sending address's balance debited the customer and refunded nothing: the handler marked the row failed and then returned as if it had succeeded, so the queue sent the confirmation email, booked the platform fee and skipped the refund. And a withdrawal whose transfer was broadcast but whose hash could not be read back, or whose send call threw after the network had already accepted the message, was marked failed and refunded while the coins were on-chain.

Both now end where every other chain ends: a short balance fails and refunds, and a transfer that may be on-chain is parked as TIMEOUT for an operator, which neither the queue nor the admin reject door will refund.

Requires Core v6.7.6 and Ecosystem v6.5.0. Core carries the reject door that refuses TIMEOUT rows; Ecosystem carries the shared outcome-classification and fee-tracker helpers this addon imports.

Update Instructions

# 1. Update the addon in Admin → System → Extensions
# 2. Restart the backend
pnpm updator

No schema change, no seeder, no .env change. Update Core and Ecosystem in the same window: without Core 6.7.6 the new TIMEOUT rows can still be refunded by hand from the admin queue.

Upgrade Notes

TIMEOUT rows need an operator

A TIMEOUT row means the transfer was sent and its outcome could not be read. Look the sending address up on a TON explorer: if the transfer landed, set the row complete with its hash; if it did not, reject it once the message's expiry has passed and the explorer shows nothing. TON_MAINNET_RPC_API_KEY remains the strongest lever against these, because anonymous Toncenter at roughly one request per second is exactly the condition that starves the hash lookup.

Fixed

• Fixed — a withdrawal larger than the address's live balance throws, so the queue refunds the debit. It used to mark the row FAILED and return normally; the queue read the return as success, sent the confirmation email, booked the platform fee and never ran the refund, and a FAILED row cannot be rejected from the admin queue.
• Fixed — a confirmation poll that never finds its transaction parks the row as TIMEOUT instead of FAILED, so a transfer that was broadcast is never refunded on the strength of a slow or rate-limited read.
• Fixed — a send call that throws re-reads the wallet's sequence number for a little over a minute, past the message's own expiry. A sequence number that advanced means the network accepted the transfer, so the row is TIMEOUT; one that did not means nothing left, so the row is FAILED and refunded.
• Fixed — the network fee the address burns on a withdrawal is recorded on the row and debited from the address's per-chain tracker, so a later "withdraw everything" no longer fails against a tracker that never saw the fee leave.

Changed

A core carved out for the platform's own sends

• Changed — handleTonWithdrawal now runs on sendTonFromWallet, exported for Core 6.7.6's pool-backing engine: a send from a wallet's own address with an optional memo (the payload the exchange asks for), the payload and seqno handed to the caller before the hash exists, the hash found by matching that payload in the wallet's outgoing messages as the handler always did. The handler's row writes are unchanged and pinned. Requires Core 6.7.6 and Ecosystem 6.5.0.