ADNL

ADNL — Abstract Datagram Network Layer — is the lowest-level networking protocol in TON. Every node, validator, full-node, light-client, TON Site, or TON Proxy speaks ADNL, and many higher-level TON protocols (RLDP for reliable transfer, the overlay protocol for shard subscriptions, TON DHT for peer discovery) ride on top of it.

What problem it solves

Conventional IP networking has two awkward traits for a peer-to-peer blockchain:

• Addresses are mutable. A node behind NAT or a dynamic IP changes address constantly.
• Authentication is layered separately. TLS, certificates, CAs sit on top, and each protocol re-implements them differently.

ADNL collapses identity, addressing, and authentication into one primitive: a 256-bit identifier derived from a public key.

How addressing works

A node generates a long-lived key pair. Its ADNL address is SHA-256(type_id || public_key), where type_id says which key family is in use. That hash is the only thing other nodes need to send messages to it. To find the actual IP/port behind an ADNL address, a node queries the TON DHT — a Kademlia-style distributed hash table that maps ADNL addresses to network endpoints.

Two consequences:

• Addresses are stable across IP changes. Move a TON Site to a new server, keep the same key, the address stays put.
• Authentication is automatic. A peer’s identity is its address; you can’t impersonate without the private key.

Transport

ADNL works over UDP primarily, with a TCP fallback for environments that block UDP. It is connectionless and unreliable — like raw UDP — but each datagram can be optionally signed and encrypted with the recipient’s public key.

Reliability and ordered delivery come from layers above (RLDP), not from ADNL itself.

Where it shows up

• TON Sites are reached by ADNL address; the .ton domain stores it.
• Validator-to-validator traffic during consensus rounds runs over ADNL overlays.
• Light clients subscribe to shard updates via ADNL overlay channels.
• TON Storage peers exchange chunks over ADNL.

Comparison with libp2p

Conceptually ADNL is in the same family as libp2p (used by IPFS, Polkadot): public-key identity, DHT-based peer discovery, optional encryption. It is simpler and more opinionated, with the trade-off that the TON ecosystem is its only consumer — there is no “ADNL on Ethereum”.

What developers need to know

For application developers building Mini Apps or dApps, ADNL is invisible — TON Connect, jetton transfers, get-method calls all hide it. ADNL surfaces when you:

• Run a TON Site (you generate an ADNL key for the endpoint).
• Operate a validator or a public lite-server (your node has an ADNL identity).
• Build infrastructure tools (indexers, archivers) that connect to lite-servers directly.

Caveats

• Privacy is partial. ADNL hides IPs from peers that only know the address, but DHT entries do leak endpoint information to network observers. Use anonymity tools if your threat model requires it.
• Spec stability. The protocol is well-documented but evolves; long-running infrastructure projects pin to a specific node version.