on.eth Launches Canonical Chain Registry, Bringing Cross-Network Identity to ENS

TL;DR

• on.eth introduces a canonical $ENS-native registry for chains and metadata, replacing scattered GitHub and app-specific mappings with an on-chain source of truth.
• With ERC-7828, $ENS says the registry enables interoperable names like vitalik.eth@base, allowing wallets and apps to resolve cross-network identities through standard $ENS flows.
• The system assigns each chain an on.eth subdomain, uses metadata records, and keeps governance with the $ENS DAO while operators manage their own chain records.

What $ENS launched this week is bigger than a naming tweak, because on.eth turns chain identity into shared infrastructure. The system introduces a canonical, $ENS-native registry for blockchain networks and their metadata, covering chains such as Base, Arbitrum and Ethereum. That matters because chain resolution data has often lived in GitHub repositories or app-specific mappings, leaving no single shared source of truth. By moving metadata on-chain inside $ENS, the project aims to replace scattered coordination with a verifiable naming layer that applications can query. It reads like an attempt to standardize fragmentation before it worsens.

A registry built to make cross-network names actually usable

The most immediate consequence is a cleaner path toward human-readable names across multiple chains. $ENS says on.eth works with ERC-7828 to support interoperable names in the format

Under the hood, the registry is designed as native $ENS plumbing rather than a bolt-on database. Each chain receives a subdomain like zksync.on.eth, optimism.on.eth or ethereum.on.eth, and those names resolve through the on.eth Chain Resolver, which acts as both resolver and registry. Chain metadata is stored using standard $ENS record types, including text records and binary data records. Forward resolution uses the ERC-7930 Interoperable Address under the interoperable-address key, while reverse.on.eth supports reverse resolution back to a human-readable chain label for clients. That architecture keeps everything inside familiar $ENS flows for developers across wallets everywhere.

Just as important, $ENS is framing on.eth as neutral coordination infrastructure, not private control over chain naming. The namespace emerged from interoperability discussions, then moved through an $ENS DAO proposal and vote that kept ownership of on.eth with the DAO itself. Operational management will ultimately sit with a dedicated multisig, while control over a chains metadata is intended to be handed to the relevant chain operator. In practical terms, $ENS is trying to reduce hardcoded mappings, improve UX across networks, and position itself as the registry layer for interoperable execution environments. That governance pitch matters.