Why a TON transaction can't be found by hash alone

Last updated: September 22, 2026

At a glance

What you see

You have a TON transaction hash from a wallet or explorer, but the account-history method you are using needs more than a hash. Paging an account's transactions with only a hash, or only an lt, returns the wrong page or an error.

Why this happens

TON's documentation says each transaction of an account "carries a logical timestamp, lt, that strictly increases with every new transaction of the account", and that "transactions follow a strict order defined by the prev_trans_hash field", together with prev_trans_lt. A transaction is identified by the account address, its lt and its hash; together they fix its place in that account's history. Account-history methods therefore page backwards from an lt and hash taken from the oldest transaction of the previous page, with an optional lower lt bound.

What to do

1. Store the account address, lt and hash of every transaction you process — not the hash alone.
2. Page an account's history by passing the lt and hash of the oldest transaction you received, always together.
3. Use the lower lt bound to stop at a transaction you have already processed.
4. If you only have a hash, find the account involved first (from your own records or the message) and search its history.

When this is not our problem

Per-account logical time and the (account, lt, hash) identity are part of TON's design and hold on every liteserver, whoever operates it, Triport included.