Lite server

Lite server is the network endpoint through which external clients gain read-only access to the current state of the TON blockchain. Technically it is a process running next to a validator or archive node that handles a specific set of RPC calls over ADNL.

Why it exists

A full TON node is a heavyweight piece of software: it stores the state of every shard, follows the masterchain, and validates blocks. Most applications — wallets, dashboards, explorers — do not need that capability; they only need to ask “someone who already knows” for a particular piece of data. That is exactly the role of the lite server: it tracks the current chain state and answers client queries with compact, signed responses.

How it is built

Architecturally a lite server consists of:

• A TCP-like channel over ADNL. The client knows the server’s public key and address (host plus port) and opens an encrypted session.
• A method set — getMasterchainInfo, getAccountState, runSmartcMethod, sendMessage and others. Through these the client reads account state, runs a contract get-method, or submits a new external message.
• Signatures and proofs. For critical responses the lite server returns a Merkle proof relative to the latest masterchain block, so the client can independently verify that the data is genuine and not forged by the server.

The list of public lite servers operated by TON Foundation lives in global.config.json, which most SDKs ship with by default.

Where it is used

• Wallets such as Tonkeeper, MyTonWallet and the in-Telegram Wallet talk to lite servers to display balances, history and fees.
• Tonscan, Tonviewer and similar explorers partially rely on lite servers for fresh data, on top of their own indexers for historical queries.
• Developer SDKs (TonWeb, ton-core, tonutils-go) use a lite server to broadcast deployment transactions and call get-methods.

How it differs from other endpoints

Alongside lite servers, the TON ecosystem also offers friendlier entry points such as the tonapi.io HTTP API and similar third-party indexers. They are easier to integrate (plain REST or GraphQL) but less trust-minimised: they do not return cryptographic proofs. A lite server is lower-level but trustless by default — given a proof, a client can verify the answer itself without relying on the operator.

Limitations

Lite servers are read-oriented and tuned for current state. History deeper than the most recent blocks is usually served only by archive nodes or with limits. Heavy historical workloads are handled by separate indexers built on top of archive nodes. The pool of public lite servers is also finite, so applications under load may hit timeouts; production projects typically run their own lite server or use a commercial pool.