ERC-7828: Interoperable Names

Abstract

This proposal defines an Interoperable Name, a chain-specific address format with the structure <address>@<chain>#<checksum>.

The <address> can be an address, or an ENS name.

The <chain> can be a CAIP-350 chain identifier, or it can be a human-readable label. This specification defines how such labels can be resolved to chain-specific metadata, via the Ethereum Name Service (ENS).

The optional <checksum> allows clients to verify the integrity of the Interoperable Name.

The result is chain-specific addresses such as:

• 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@eip155:1#80B12379
• alice.eth@eip155:1
• alice.eth@ethereum

Motivation

The current Ethereum address landscape is evolving toward an ecosystem with hundreds, and eventually thousands, of L2s that share the same address format as Ethereum mainnet. This means an address by itself is insufficient to determine which chain it is associated with. This ambiguity can result in funds being sent to an unreachable address on the wrong chain.

ERC-7930 introduced a binary format for representing a target address on a specific blockchain. While this binary data is well suited for low-level usage (e.g. in smart contracts), its meaning is semantically opaque to human users.

The core motivation for introducing the Interoperable Name standard is to provide maximally readable, chain-specific addresses for user-facing interactions.

A foundational text representation (e.g. 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@eip155:1) enables a significantly more readable chain-specific address format. An expanded form that leverages the name resolution capabilities of the Ethereum Name Service (ENS) further improves readability, allowing addresses to be expressed in a maximally human-friendly form (e.g. wallet.ensdao.eth@ethereum).

An on-chain registry provides a canonical source of truth for mapping human-readable chain labels to the metadata associated with each chain. Today, chains are identified using a variety of specifications (e.g. CAIP-2 and EIP-155 for EVM-compatible networks), whose formats are not necessarily semantically clear to human users. By introducing an on-chain registry, applications can refer to a chain using a readable identifier such as base, rather than an opaque identifier like eip155:8453 or 8453.

Historically, the mapping from chain names to identifiers has, since EIP-155, been maintained off-chain using a centralized list.

This approach has several shortcomings:

• It does not scale with the growing number of blockchains
• It relies on a trusted centralized maintainer
• It does not support non-EVM chains

This specification defines an architecture that enables chain operators to take ownership of their chain-specific data, thereby reducing reliance on a single centralized entity and ensuring data integrity.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Terminology

This section builds upon the Terminology defined in ERC-7930.

Interoperable Name : A human-readable chain-specific address format meant to be used by humans for user-facing interactions. e.g. 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:1#4CA88C9C

Interoperable Name Definition

The format of an Interoperable Name is <address>@<chain>#<checksum> where the components match the following regular expressions:

Syntax

These components have the following meanings:

• <address> can either be:

  • A target address as defined in ERC-7930.
  • An Ethereum Name Service (ENS) name. e.g., wallet.ensdao.eth

• <chain> can either be:

  • The string representation of a specific blockchain as defined in CAIP-350. For example eip155:1 for Ethereum Mainnet, or solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d for Solana Mainnet.
  • A human-readable label identifier for a specific chain, defined and registered as a subdomain of the on.eth ENS name. An on-chain resolver contract maps these labels to their corresponding canonical ERC-7930 chain identifiers, and exposes additional chain metadata.

• <checksum> is defined as the first 4 bytes (8 characters) of the Keccak-256 hash, represented as a hexadecimal string (Base16, as specified in RFC 4648). The hash is computed over the concatenation of the following binary fields from the canonical ERC-7930 Interoperable Address:

  • ChainType
  • ChainReferenceLength
  • ChainReference
  • AddressLength
  • Address

Note: The Version field MUST NOT be included in the hashed data.

Checksums

The checksum provides an optional integrity verification mechanism for Interoperable Names that include a raw target address.

• The checksum is OPTIONAL but RECOMMENDED when the
  component represents a target address, as it helps mitigate homoglyph and spoofing attacks for chain-specific addresses.
• A checksum SHOULD NOT be included when the
  component is an ENS name
• Clients MAY include or omit the checksum when displaying or sharing an Interoperable Name.
• Clients MAY accept Interoperable Name inputs with or without a checksum.
• When a checksum is provided for a target address, clients MAY validate it by deriving the underlying Interoperable Address and recalculating the checksum.

UI/UX developers are encouraged to determine the most appropriate way to warn users when a checksum does not match, when resolution fails, or any other scenario they deem necessary to ensure user safety and clarity.

Versioning

This specification does not define its own versioning mechanism.

Implementers SHOULD ensure they are up to date with the version of ERC-7930 they are using. Refer to the versioning section of ERC-7930 for detailed rules.

Implementations MUST maintain convertibility between Interoperable Names and the corresponding ERC-7930 Interoperable Address binary format.

Target Address Examples

Ethereum Mainnet

The address 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 on Ethereum Mainnet could be represented as either of the following:

Note: In the second example ethereum is the chain label for Ethereum Mainnet in the on-chain ENS resolver set for the on.eth namespace (see below).

Non-EVM chains

The address bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk on Bitcoin Mainnet could be represented as:

Note: In the second example bitcoin is the chain label for Bitcoin Mainnet in the on-chain ENS resolver set for the on.eth namespace (see below).

ENS <address> Examples

ENS resolves addresses on a chain-specific basis, as outlined in ENSIP-9 and ENSIP-11.

Note: When the <address> component is an ENS name, a checksum SHOULD NOT be included (see Checksums above). The examples in this section therefore omit the optional #<checksum> suffix.

Ethereum Mainnet

Assuming that wallet.ensdao.eth resolves to 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 for Ethereum Mainnet either of the following could be used to represent the same target address:

Non-EVM chains

Assuming that wallet.ensdao.eth resolves to bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk for Bitcoin Mainnet either of the following could be used to represent the same target address:

Resolving the <chain> component

If the <chain> component of an Interoperable Name does not contain a colon (:) it is interpreted as being a label under the on.eth ENS namespace.

The resolver for on.eth MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the ERC-7930 Interoperable Address for the specified chain label using the key, interoperable-address. For example if you resolve the interoperable-address data record for ethereum.on.eth the Interoperable Address 0x00010000010100 SHOULD be returned.

The on-chain resolver for on.eth MAY implement aliasing so that multiple chain labels, such as op.on.eth and optimism.on.eth, resolve to the same underlying data. To ensure consistency and integrity, there must be a single canonical representation of this data.

A pseudocode implementation of this resolution is as follows:

The resolver for on.eth MUST implement ENSIP-5 - Text Records, and allow for the resolution of text records for the reverse.on.eth namespace of the form chain-label: followed by the ERC-7930 Interoperable Address you are trying to discern the label for. For example, the Interoperable Address representing Ethereum Mainnet is 0x00010000010100. Resolution of the text record chain-label:0x00010000010100 for the reverse.on.eth namespace SHOULD return ethereum.

While multiple labels - such as op.on.eth and optimism.on.eth — may resolve to the Interoperable Address 0x00010000010a00, the reverse resolution process will always return the canonical label: optimism.

A pseudocode implementation of this resolution is as follows:

Additional implementation details about the resolver contract implementation can be discerned by referencing the ENS documentation, and viewing the verified source code of the contract set as the resolver for on.eth.

Resolving the <address> component

If the <address> component contains a period (.), it is assumed to be an ENS name. Because ENS fully integrates with the Domain Name System (DNS), any traditional domain name can function as an ENS name, as can any name using the blockchain-native .eth extension.

If an ENS address is used within the <address> component, it MUST be resolved subject to the ENS resolution specifications, giving consideration to the target chain specified in the <chain> component.

The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specifications outline how one resolves an ENS name to discern the address for a specific chain. Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.

If a target address has been used for the <address> component (or once the ENS name has been resolved to a target address) it should be serialized subject to the rules defined in the relevant CAIP-350 profile for the given <chain>. This ensures that different valid text representations (e.g., case variations in an address) resolve to a single, canonical binary form, which is essential for consistent checksum calculation and data integrity.

Rationale

• The Ethereum Name Service (ENS) is a well-established blockchain identity primitive that enables the registration of human-readable names (e.g. example.eth, wallet.ensdao.eth) which resolve to addresses on a chain-specific basis. ENS is widely used, familiar to users, and well understood by implementers.
• For flexibility and backwards compatibility, this specification allows a raw target address to be used in the <address> component, accommodating users and applications that prefer traditional address representations.
• In this specification, checksums are defined as OPTIONAL. While they provide meaningful integrity guarantees for raw, chain-specific target addresses, their applicability to ENS-based names is limited. ENS names may resolve to different addresses over time depending on resolver behavior, which means that a previously generated checksum may no longer validate even when resolution is correct. In addition, when using ENS, users already delegate name normalization, resolution, and validation to ENS-specific mechanisms, so applying checksums in these cases provides limited additional security while increasing complexity and ambiguity for implementers. As a result, checksums are primarily intended to protect the integrity of raw, chain-specific addresses, while remaining optional and flexible for user-facing applications.
• The ERC-7930 Version field is excluded from checksum calculation to allow the same Interoperable Name to remain valid across version upgrades of the binary format.

Security Considerations

• Implementers MUST give consideration to the name normalization specifications of the Ethereum Name Service so as to avoid homoglyph or spoofing attacks. These are outlined in ENSIP-1 and ENSIP-15.
• Users should stay vigilant of address poisoning attacks when using a raw target address in the <address> component.
• ENS resolution depends on resolver contracts set for each name. Resolvers may change over time, and wildcard resolvers (ENSIP-10) may return dynamic data.

Copyright

Copyright and related rights waived via CC0.