TON Sites

TON Sites are websites that live on the TON network rather than on the conventional DNS + IP web. Instead of an A record pointing to a server, a TON Site is reached through an ADNL address recorded in a .ton domain. The TON Proxy (a piece of software running on a user’s machine, in a wallet, or as a public gateway) resolves the name and tunnels traffic to the right node.

How resolution works

1. User types example.ton in their browser (or wallet’s built-in browser).
2. The client looks up the .ton domain in the TON DNS resolver tree.
3. The domain returns a dns_adnl_address record — a 256-bit ADNL identifier.
4. The TON Proxy connects to that ADNL endpoint over the TON peer-to-peer network.
5. The endpoint serves HTML, like any other web server.

There is no DNS, no Cloudflare, no certificate authority in this path — encryption and addressing come from ADNL’s public-key model.

How users access them

• Tonkeeper, MyTonWallet, Wallet. Their built-in browser resolves .ton natively.
• TON Proxy CLI. A small utility that runs locally and forwards *.ton traffic from a normal browser through the TON network.
• Public gateways like foundation.ton.site map TON Sites to the conventional web — convenient but defeats the decentralisation angle.

Use cases

• Censorship-resistant publishing. A .ton site is not blocked by traditional DNS or IP filtering; only blocking the TON network itself can take it down, which is much harder.
• Project landing pages. Some TON-native projects host a .ton mirror of their main site as a statement.
• Decentralised storage front-ends. Combined with TON Storage, a TON Site can serve files by storage bag ID.
• Mini App alternatives. A TON Site can ship a web UI without depending on Telegram or conventional hosting.

Differences from the regular web

• Discovery. No Google indexing. You find TON Sites through directories, channels, and the .ton registry.
• Performance. TON Proxy adds latency — typical page loads are noticeably slower than HTTPS on a CDN.
• Reach. Most users do not have a TON Proxy installed. Public gateways improve reach but reintroduce a single point of trust.

Practical caveats

• HTTPS-style certificates do not apply. Trust comes from the ADNL public key matching the DNS record. If you trust the resolution chain, you trust the content.
• Mobile support is uneven. Wallet apps integrate the proxy for in-app TON Sites, but a system-wide proxy on iOS/Android is not yet a smooth experience for non-technical users.
• Hosting. Anyone can run a TON Site by exposing an ADNL endpoint and pointing a .ton domain at it. There is no hosting business in the conventional sense; lots of small site operators run their own nodes.

Where they fit

TON Sites occupy a niche similar to ENS-resolved IPFS gateways on Ethereum — clearly decentralised, not yet mass-market. For an SEO-driven content site, conventional HTTPS hosting still wins; for a censorship-sensitive announcement page or a brand statement, a .ton mirror adds a credible decentralisation layer.