TON Blockchain v6.0.8

Release Date: August 26, 2026 Tags: WALLETS, TRANSACTIONS, RELIABILITY

Overview

One unusual transaction destroyed the whole TON history, and the history was ten rows deep anyway. Both problems live on the same screen: the master wallet view an operator opens to reconcile a day's movements.

A transfer sent from the wallet carries a message with no value attached, and reading that value was unguarded. Because the failure happened while mapping the page rather than one row, it did not lose the odd transaction — it lost every transaction beside it, as a server error. An outgoing transfer is exactly what an operator looks at the master wallet to see.

The page size was separately hardcoded to ten, which is not a history but the last page of one, permanently, with no way to reach anything older. Requires Core v6.7.2.

Update Instructions

pnpm updator

Restart the backend. There is no database change and no configuration.

Fixed

One odd transaction took the entire transaction list with it

Two reads on the same row were guarded inconsistently, two lines apart: the sender address was written defensively and the amount beside it was not. A wallet-initiated transfer carries an external incoming message with no value — and on some responses no incoming message at all — so reading the amount off it threw, and the whole page was lost to a server error.

• Fixed the amount read, so a transaction that carries no incoming value is reported at the amount its outgoing message actually moved rather than costing the page.
• Fixed the outgoing-message read, which assumed a list that the public endpoint omits entirely on some transaction shapes.

The history was ten transactions and could not be widened

• Changed the default page size from a hardcoded ten to fifty, and made it a parameter so a caller can ask for more.
• It is bounded rather than unlimited: the public endpoint an install uses without an API key rate-limits hard, and an unbounded read there fails as a timeout rather than as a large answer.