ADNL (TON)

Last updated: October 25, 2026

Applies to: TON

Endpoint and plans: TON RPC endpoint.

In more detail

ADNL has distinct uses on the TON network. Nodes communicate with one another over UDP, while lite clients use ADNL over TCP to query liteservers. A direct liteserver connection therefore speaks a binary protocol rather than HTTP. A client that accepts an HTTPS URL is using an API layer instead of connecting directly to that server's ADNL port.

For a TCP connection, the client needs the server's IP address, TCP port and Ed25519 public key. The configuration represents that identity with the pub.ed25519 constructor. The key is needed to establish the encrypted connection to the expected server; an IP and port alone are insufficient. This public identity key is connection data, not a private signing key or an HTTP API credential.

The encrypted channel carries TL-serialized requests from lite_api. For example, liteServer.getMasterchainInfo asks for the latest masterchain block known to the server. Transport and method are separate layers: ADNL carries the request, while lite_api defines what it asks and how the answer is structured. An HTTP v2 facade can expose equivalent reads as JSON; an indexed API can additionally answer database-backed queries.

History is a separate constraint from transport. ADNL does not turn a regular liteserver into an archive node: the answer still depends on what the receiving node retains. When current reads work but an older block is unavailable, investigate the answering liteserver's history window. See the liteserver term and the linked not-in-db guide for that distinction.

See also

• Liteserver (TON)
• Masterchain (TON)

All terms in the RPC and blockchain glossary