on.eth introduces a canonical, ENS-native registry for chains and their associated metadata, covering networks such as Base, Arbitrum, or Ethereum, among others. Together with ERC-7828, it enables Interoperable Names like `vitalik.eth@base`, combining an ENS name and a chain identifier into a single, human-readable format. Rather than relying on off-chain mappings, applications can resolve chain-specific addresses directly through ENS using verifiable on-chain data.
Today, chain resolution information is scattered across the web, living in GitHub repositories or app-specific mappings. Even within the ENS ecosystem, there has been no single shared source of truth.
on.eth introduces an ENS-native, on-chain registry for chain identifiers and related chain metadata representing blockchains such as Arbitrum (chain ID: 42161) or Linea (chain ID: 59144). Rather than pointing to a single piece of information, the registry allows applications to retrieve different kinds of metadata about a chain depending on their needs, such as its ERC-7930 Interoperable Address, CAIP-2 identifier, X handle, or website.
Together with ERC-7828, this enables human-readable cross-chain names such as:
vitalik.eth@
The result is cleaner UX, consistent naming across applications, and a trustless coordination layer for the Ethereum ecosystem.
The idea for on.eth emerged through discussions within the ENS and broader interoperability communities about the need for a canonical registry for chain identities. A formal proposal prepared by Unruggable was subsequently submitted to the ENS DAO and approved through a DAO vote, ensuring the namespace remains neutral, credible, and aligned with Ethereum's long-term coordination goals. Rather than introducing a new authority, the proposal places chain naming inside ENS as shared infrastructure.
The idea behind on.eth is simple: give chains a canonical namespace inside ENS. Each chain receives a subdomain such as
zksync.on.eth,optimism.on.eth, orethereum.on.eth.
These names resolve through the on.eth Chain Resolver, which functions as both resolver and registry. It maps human-readable chain names to canonical identifiers and chain metadata using standard ENS resolution flows.
Instead of asking off-chain databases what a chain name such as zksync represents, applications can query ENS directly and retrieve the relevant metadata in a verifiable and shared way across the ecosystem.
The resolution process works in the same way as any other ENS name. It starts on Ethereum mainnet with the Universal Resolver. A name like base is interpreted as a label under the on.eth namespace, meaning the Universal Resolver is asked to resolve base.on.eth. Chain metadata is stored using standard ENS record types, including text records (ENSIP-5) and binary data records (ENSIP-24), which can be resolved through the same ENS resolution flow.
For forward resolution, one piece of metadata defined for all chains is the ERC-7930 Interoperable Address, stored using ENSIP-24 data resolution under the key interoperable-address. The current resolver implementation was developed by Unruggable as a reference deployment aligned with these standards. Chain names therefore do not resolve to standard Ethereum addresses, but instead to the chain-specific component of an ERC-7930 address, which uniquely identifies the execution environment.
The namespace also uses reverse.on.eth for reverse resolution, enabling clients to map an ERC-7930 interoperable address back to a human-readable chain label.
With canonical chain identities in place, we can introduce a clean syntax for cross-chain names. In combination with on.eth, ERC-7828: Interoperable Names enables ENS-native interoperable names of the form:
Format: <name>@<chain>. For example `vitalik.eth@base`.
The structure is intentionally minimal. It combines an ENS name with a chain suffix derived from the on.eth namespace. Rather than introducing a new naming system, it extends the mental models users already understand. The complexity is handled entirely during resolution.
Let's walk through what happens when a a wallet or application encounters the interoperable name vitalik.eth@base.
The client separates the ENS name vitalik.eth from the chain suffix base. Both components are resolved through standard ENS flows.
The Universal Resolver on Ethereum mainnet acts as the entry point. The chain suffix base resolves first via the on.eth Chain Resolver using an ENSIP-24 data call. The name vitalik.eth then resolves via its configured resolver (for example, the public resolver or a custom resolver) to the address configured for Base, reflecting the chain-specific address for the resolved environment.

Once the wallet address and the canonical chain address are retrieved, the client combines them into a single ERC-7930 Interoperable Address, which encodes the account together with its execution environment in a single machine-readable representation.
Because on.eth is intended to serve as shared infrastructure, its governance model matters.
Under the adopted governance model, the ENS DAO remains the ultimate owner of the on.eth name. This ensures that control over the namespace cannot be lost or captured by a single operator. If necessary, the DAO retains the ability to reassign control.
Operational management will ultimately be delegated to a dedicated multisig. The multisig handles the initial registration of chains and the setup of their records. The intention, however, is that control over a chain's metadata is ultimately handed to the respective chain operator so that they manage and update their own records.
This structure preserves neutrality at the namespace level while allowing chain operators to maintain their own metadata without requiring ongoing DAO governance for routine updates.
Without a shared registry, interoperable naming remains fragile. Wallets and applications maintain their own chain mappings, and those mappings can drift over time.
An on-chain registry changes that dynamic. Instead of relying on off-chain coordination, applications can resolve chain identities directly through ENS, using standard resolution flows and on-chain verifiable data.
For users, this reduces friction when interacting across networks. Names like alice.eth@optimism become easier to interpret and safer to use because the chain component is resolved against a canonical source of truth. Wallets and apps will still need to implement this standard for users to truly feel this simpler structure for transacting on different EVM chains.
For developers, the impact is more structural. Smart contracts and clients gain access to a neutral coordination layer for chain metadata, removing the need for hardcoded mappings or external registries. Libraries such as the Interop SDK from Wonderland make it straightforward for applications to resolve interoperable names and construct interoperable addresses.
In that sense, on.eth extends ENS beyond naming accounts. It introduces a way to name execution environments themselves. In an increasingly interoperable blockchain ecosystem, coordination across execution environments becomes infrastructure. on.eth positions ENS as the registry layer for that coordination.