Live TON Sites: how apiton finds and ranks sites on .ton domains

apiton.org now has a Live TON Sites list: .ton domains that serve a website of their own inside the TON network, ordered by a rank, plus a recently live view. This article explains where that list comes from — which on-chain data we read, how each site is checked, what "live" and "parked" mean, and how the order is computed — so you know what the list can and cannot tell you.

If you are new to TON DNS, start with How TON DNS and TON Sites work: it covers dnsresolve, record categories and the two kinds of sites (ADNL and TON Storage).

Step 1: which domains have a site record

A domain "has a site" when its DNS record for the category sha256("site") is set (TEP-81). The record is one of two things:

• dns_adnl_address — the ADNL id of a server, reached through the TON DHT and RLDP;
• dns_storage_address — the id of a TON Storage bag that holds the site's files.

apiton already keeps a catalog of .ton domains with the address of each domain's NFT item. To read the record we call dnsresolve directly on that item with an empty subdomain, which returns all of the domain's records in one get-method call over the liteservers. We keep only the site record. Each domain is re-read about once a week, and right away when the domain's contract shows a new transaction (a record change is a transaction on the item).

No site is contacted in this step: it only reads the blockchain.

Step 2: probing the site

Every domain with a site record gets a probe: a plain GET / sent to the site over RLDP (for an ADNL address) or fetched from the Storage bag, with the header Host: <name>.ton. The Host header matters — some hosting providers serve many sites from one ADNL address and pick the site by Host.

The probe is deliberately small. With the default settings it waits up to 15 seconds for an ADNL site (a server missing from the DHT typically takes 9–15 s to fail) and up to 30 seconds for a Storage bag (a bag that no peer has warmed up can take that long), reads at most 256 KB of the page, and follows redirects only within the site itself: a redirect to another path on the same host (say, / to /index.html) is followed for up to 3 hops. A redirect to any other host is not followed — it is itself a signal (see below).

Each probe ends in one of these outcomes:

Outcome	Meaning
dht_not_found	the ADNL id is not in the DHT: the server is gone or offline
unreachable	no answer in time (connection or RLDP timeout, Storage bag not found)
http_error	the site answered with HTTP status 400 or higher, with an empty page, with a redirect loop or a redirect without a target, or with a small error page served as 200 (its title or main heading is just a status code such as "404", or says "not found", "internal server error" and the like)
parked	the site answered, but with a parking page, a hosting placeholder, a domain-sale page or an anti-bot check (below), or redirected to another host
live	the site answered with something that is not a parking page

A new domain starts as unknown until its first probe.

Parked vs live

A large share of site records point to parking pages — marketplaces set one ADNL address on many domains to show a "this domain is for sale" page. Such a domain answers perfectly well, so "answered" alone is not enough. apiton marks a site parked when any of these holds:

• the site answers with an HTTP redirect to another host — outside TON that is a parking; to another .ton name it is an alias, and the target domain is probed on its own;
• the page is a domain-for-sale landing: its title or main heading says "domain for sale", "buy this domain" and similar, or starts with the domain name followed by "for sale";
• the page is an anti-bot or captcha check ("Just a moment…", "Checking your browser" and similar titles) and is small — that is not the site's own content, and it comes back on every probe;
• the answer redirects away from TON (an HTTP redirect, a <meta http-equiv="refresh"> or a JavaScript redirect to an ordinary https:// URL, not a .ton one) and the page is small;
• the page's title is just the domain name (as written or in punycode) and there is almost no other visible text — the typical hosting placeholder;
• the title is a known placeholder such as "Redirecting";
• the same ADNL or bag id is shared by 20 or more domains and the answer redirects away or is a stub, or exactly the same content is served on 20 or more domains.

A small site titled with its own domain but with real text of its own stays live, even when it shares hosting with parked domains. Everything else that answered below HTTP 400 with a non-empty page that is not an error page is live. That is a technical status, not a quality judgment; the rank below is what pushes substantial sites up.

How often sites are re-checked

With the default settings:

• live sites are probed every 6 hours, parked ones every 7 days;
• a failing site backs off: 1 hour after the first failure, 24 hours after the second, then 7 days;
• a live site survives one failed probe (a single lost packet should not drop it from the list); the second failure in a row takes it off the live list until it answers again;
• when several sites are due at once, live sites due for a re-check are probed first, so the live list stays fresh even while a backlog of new domains waits for its first probe.

The domain page on apiton.org shows the result of the latest probe — for example foundation.ton: status, the page <title>, "live since", the share of successful probes over 30 days, the response time and when it was last checked.

How the list is ranked

Only live sites that have not been taken down are ranked. The score is a weighted sum (default weights in brackets):

• uptime (0.35) — the share of probes over the last 30 days that got an answer;
• speed (0.15) — 1 / (1 + latency in seconds): 250 ms gives 0.8, 1 s gives 0.5;
• links (0.20) — how many other live .ton sites link to this one (links to *.ton found in the probed HTML), on a log scale normalised to the best-linked site;
• content (0.10) — 0.4 for having a <title>, 0.2 for a description, up to 0.4 for page size (full at 10 KB);
• age (0.10) — how long the site has been continuously live, full at 90 days;
• popularity (0.10) — reserved for a view count; it is zero for every site today.

Sites that serve byte-for-byte the same page (same content hash) are treated as mirrors: only the best of them keeps a rank. This stops one template on hundreds of domains from filling the top.

The Live TON Sites list is ordered by this rank, 50 sites per page. The Recently live view orders the same sites by the moment they came alive, newest first.

Numbers at the time of writing

On 26 September 2026 the apiton API reported, among the 196,666 .ton domains in the catalog:

• 94 live sites;
• 1,449 parked;
• 145 dht_not_found, 17 unreachable and 14 http_error;
• 1,246 domains with a site record not yet probed.

Parked pages outnumber live sites about fifteen to one: over 500 of them were one hosting provider's "this domain is for sale" page, served from a single site id, with the domain name as the title and a redirect to an external marketplace. apiton classifies such pages as parked, so only sites with their own content count as live. The probes and the site-record sweep have not reached every domain yet, so the Live TON Sites list and the home page are the place to see the current count.

The same data through the API

Every number above comes from the public apiton API, which you can call yourself:

# the top of the live list
curl -X POST https://app.apiton.org/v2.Catalog/List \
  -H 'Content-Type: application/json' \
  -d '{"kind":"domain","site":"live","sort":"site_rank","limit":50}'

# one domain's site record and last probe
curl -X POST https://app.apiton.org/v2.Nft/Domain \
  -H 'Content-Type: application/json' \
  -d '{"domain":"foundation.ton"}'

site also accepts record (any domain with a site record); sort accepts site_live_since. v2.Catalog/Summary returns the live count as live_sites. The full list of request fields is in Using the apiton API with curl.

Limits of the list

• It only covers domains in apiton's catalog, and only sites that answer GET /.
• "Live" means "answered with non-parking content at the last probes", not "safe" or "useful". apiton does not review site content; sites are removed only by a manual takedown.
• A site on a single slow server can flap between live and unreachable; the uptime share shows it.

To check a domain, its owner and expiry date in Telegram, send its name to @apitonBot.