Liteserver (TON)
Last updated:
Applies to: TON
Endpoint and plans: TON RPC endpoint.
In more detail
A full node keeps blockchain state locally; a lite client asks a liteserver for the pieces it needs. The liteserver exposes binary lite_api queries over ADNL. An HTTP API can translate application requests into those queries, so using JSON does not by itself tell you how much historical data is available behind the API.
Liteservers can return cryptographic proofs with blockchain data, allowing a client to verify the response. In the TON API comparison, this distinguishes direct liteserver access from HTTP v2 and indexed v3 APIs, which do not expose those proof bundles. A JSON response should therefore not be treated as a proof merely because a liteserver supplied its underlying data.
A regular liteserver does not retain the complete block history. An archive liteserver stores old blocks and states as well as current data. Historical availability depends on the answering node's configuration: a request for an old masterchain sequence number can succeed on an archive node and fail on a regular one. A reachable server is not evidence that a particular old block remains in its database.
These are node roles, not interchangeable promises. Liteserver mode serves lite-client queries; archive liteserver mode adds full historical storage; validator mode participates in consensus by signing blocks. When diagnosing a historical read, check retention separately from connectivity and from whether the node validates blocks. The linked troubleshooting guide explains the resulting not-in-db errors.