ENS Contenthash Meets TON ADNL

Let’s talk about what it means for an ENS name to point beyond the familiar decentralized storage networks and into a live TON Site.

ENS names can point to decentralized content through the contenthash record. Until now, the most common targets were IPFS, IPNS, Arweave and Swarm. An ENS name could resolve to a CID, a storage identifier or another decentralized web resource.

ADNL adds TON Sites to that model.

A TON Site is an HTTP service reachable through TON’s network stack. Instead of being identified by a conventional DNS name or a fixed IP address, it is identified by an ADNL address: a 32-byte identifier derived from a public key.

The goal of this work was simple: make that ADNL identity understandable to the ENS ecosystem through the same contenthash tooling applications already use.

name.eth
  -> ENS contenthash record
  -> adnl://<TON Site address>
  -> ENS libraries decode the record
  -> an ADNL-aware gateway routes the request to TON
  -> the TON Site responds over RLDP / ADNL

This is not a bridge. There is no new Ethereum smart contract, wrapped asset or custom ENS resolver.

The ENS name remains owned and managed on Ethereum. The service behind it can be hosted through TON’s network layer.

What was added

The work had to land across every layer that handles a contenthash record.

A multicodec identifier

First, ADNL was added to the multicodec registry as adnl, with code 0xb69910.

Multicodec is the shared registry used to identify decentralized formats and protocols. ADNL no longer needs to be represented as an application-specific byte sequence: compatible implementations can identify it through the same assigned code. The registry currently marks the entry as draft, while the identifier is already used consistently across the ENS integrations below.

An ENS content-hash profile

Next, ENS content-hash added the ADNL encoding profile. It encodes and decodes a 32-byte ADNL address represented as:

adnl://<64 hexadecimal characters>

The implementation validates the address length and maps the raw bytes to the registered multicodec identifier.

Support in ENS.js

ENS.js then exposed ADNL as a supported contenthash protocol. Applications using the standard ENS developer library can now recognize, display, encode and decode adnl:// records through the normal contenthash APIs.

A user-facing ENS App implementation

Our ENS App v3 implementation adds the user-facing layer: ADNL validation, provider support, TON iconography and the ability to enter an ADNL URI in the profile editor.

This implementation lives in the TONresistor ENS App fork. It demonstrates the complete editing flow without claiming that every public ENS App deployment has enabled ADNL already.

Routing in eth.limo’s gateway stack

Finally, eth.limo’s dweb-proxy-api added ADNL resolver and gateway support.

When TON support is enabled, the resolver recognizes an ADNL contenthash record, converts the 32-byte hexadecimal address into TON’s hostname-safe ADNL representation and directs the request to a configured RLDP-HTTP TON proxy. The gateway can then preserve the original HTTP path while routing the request to the corresponding TON Site.

Why this matters now

The important milestone is not only that one ENS name can point to one TON Site.

The important part is that ADNL is now present in the shared primitives: multicodec, ENS content-hash and ENS.js. Future integrations do not need to invent a format, debate address encoding or maintain separate custom parsers.

This opens a clearer path for:

ENS explorers and profile tools to display ADNL records correctly.
Wallets and browsers to support adnl:// alongside IPFS and Arweave.
Gateways to resolve ENS names to TON Sites.
Decentralized applications to use TON Sites as an additional frontend deployment path.
Infrastructure projects to publish services, documentation, APIs or RPC endpoints through a stable ADNL identity.

Each integration still needs to choose to support ADNL. Standardization does not make every browser, wallet or gateway resolve it automatically. What it does provide is interoperability: the identifier, encoding and core ENS libraries now agree on the same representation.

That makes further adoption much easier.

ENS gives TON Sites a familiar Ethereum identity layer. TON gives ENS names another decentralized network path.

Guide: How to host a TON Site with ENS.

Keep resisting.

Select Language