Lite client
A TON client that does not synchronise the full blockchain but reads selective data from a lite server over ADNL. The lite-client model underpins most TON SDKs and wallets.
Aliases: lite client, ton client
Lite client is the client side of the TON network protocol, designed for devices that cannot — and do not want to — keep a full copy of the chain state. Instead of synchronising the masterchain and shards, a lite client talks to one or more lite servers and pulls only the pieces of data it needs at the moment.
Why it exists
Running a full TON node requires substantial resources: tens of gigabytes of disk, a stable internet connection, and a valid network configuration. That makes sense for validators and infrastructure services but is absurd for a mobile wallet or a browser dashboard. The lite-client model solves the problem: knowing only the addresses and public keys of lite servers, the client can interact with the chain securely.
How it works
A typical request cycle:
- The client opens an ADNL connection to a lite server.
- It fetches the current masterchain block and the validator signatures.
- It queries the data it needs — an account balance, a contract state, a get-method result.
- It receives the response together with a Merkle proof showing that the data corresponds to the latest block.
- It verifies the proof locally and uses the data.
When sending a transaction, the lite client merely posts a signed external message to a lite server; from there validators propagate it across the network and include it in a block.
Where it shows up
Practically every library for talking to TON is a lite client under the hood:
- TonWeb — the original JavaScript client.
- ton-core / ton-crypto / ton-lite-client — the modern TypeScript stack from ton-org.
- tonutils-go — a Go client popular with backend teams.
- pytonlib / pytoniq — Python clients commonly used in bots and indexers.
These SDKs expose high-level methods such as “get account balance”, “call get-method”, “send jetton”, but every such call ultimately becomes a lite-server request.
Trust and proofs
The main difference between a lite client and an ordinary REST client wrapping a third-party indexer is built-in verifiability. A lite client does not have to trust the server: validator signatures and Merkle proofs let it confirm locally that the data really comes from the chain. In practice many SDKs simply trust the default set of TON Foundation lite servers and skip proof verification for every response, but the option is always there.
Limitations
A lite client only works with what a lite server returns. If the server is unreachable, the client cannot function. To improve reliability, serious applications connect to several lite servers and fail over between them. Lite clients also do not build their own historical index — for deep queries, applications use dedicated services on top of archive nodes.