lt (logical time)

lt (logical time) is a TON-specific concept: a monotonic uint64 counter incremented on every transaction inside a shard. It’s the TON equivalent of a Lamport timestamp in distributed systems.

Why it exists

Physical time (utime / Unix timestamp) on distributed nodes is only approximately synchronised (NTP precision). For strict ordering, TON uses lt:

• Every transaction has its own lt and prev_lt.
• Messages inside a transaction are ordered via created_lt.
• lt always increases within an account/shard — no collisions, no “same moments”.

Where you’ll see it

In tonapi / toncenter responses, utime and lt usually sit side by side: utime for UX (“received at 12:34”), lt for deduplication and precise sorting. When paginating an account’s transactions, the correct cursor is (lt, hash), not utime.

Example from an API response

Shortened JSON of one transaction from getTransactions:

{
  "transaction_id": {
    "lt": "48125293000003",
    "hash": "9f5b...c1"
  },
  "utime": 1716908123,
  "in_msg": { "created_lt": "48125293000002", "value": "100000000" },
  "out_msgs": [
    { "created_lt": "48125293000004", "destination": "EQA..." }
  ]
}

Notice: the lt of in_msg is below the transaction’s lt; the out_msgs lts are above. Each message gets its own lt at creation, so the order “incoming → execution → outgoing” is rigidly guaranteed.

lt vs utime — when to use which

Task	Correct field
”When did this happen” in UI	utime
Comparing “did A happen before B”	lt
Dedupe in a DB	(account, lt) — unique pair
Paginating tx history	cursor (lt, hash)
Locating a specific operation	lt + hash

Using utime for ordering is a common mistake: thousands of transactions can share the same second, and utime collapses them together.

Logical time in a shardchain

Every shardchain has its own lt counter, disjoint from other shards. This doesn’t break causality: on cross-shard messages, the receiving shard takes the sender’s created_lt, and its own lt simply steps above the incoming value. That’s how “happens-before” is built across TON’s distributed system without a global clock.

Bounds and overflow

lt is uint64, upper bound ~1.8 × 10¹⁹. At 1000 tx/s per shard that’s roughly 580 million years to overflow — practically never.