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#80B12379alice.eth@eip155:1alice.eth@ethereumThe 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.
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.
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
The format of an Interoperable Name is <address>@<chain>#<checksum> where the components match the following regular expressions:
<interoperable-name> ::= <address> "@" <chain> [ "#" <checksum> ]
<address> ::= [.-:_%a-zA-Z0-9]*
<chain> ::= [.-:_a-zA-Z0-9]*
<checksum> ::= [0-9A-F]{8}
These components have the following meanings:
<address> can either be:
wallet.ensdao.eth<chain> can either be:
eip155:1 for Ethereum Mainnet, or solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d for Solana Mainnet.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 ChainReferenceLengthChainReferenceAddressLengthAddressNote: The Version field MUST NOT be included in the hashed data.
The checksum provides an optional integrity verification mechanism for Interoperable Names that include a raw target address.
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.
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.
The address 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 on Ethereum Mainnet could be represented as either of the following:
0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@eip155:1#80B12379
0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@ethereum#80B12379
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).
The address bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk on Bitcoin Mainnet could be represented as:
bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk@bip122:000000000019d6689c085ae165831e93#597D21A1
bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk@bitcoin#597D21A1
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).
<address> ExamplesENS resolves addresses on a chain-specific basis, as outlined in ENSIP-9 and ENSIP-11.
Assuming that wallet.ensdao.eth resolves to 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 for Ethereum mainnet either of the following could be used to represent the same target address:
wallet.ensdao.eth@eip155:1#80B12379
wallet.ensdao.eth@ethereum#80B12379
Assuming that wallet.ensdao.eth resolves to bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk for Bitcoin mainnet either of the following could be used to represent the same target address:
wallet.ensdao.eth@bip122:000000000019d6689c085ae165831e93#597D21A1
wallet.ensdao.eth@bitcoin#597D21A1
<chain> componentIf the <chain> component of an Interoperable Address does not contain a colon (:) it is interpreted as being 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:
/**
* Pseudocode to resolve the Interoperable Address associated with 'ethereum.on.eth'
* Using ENSIP-24 and the data key 'interoperable-address'
*/
// 1. Inputs
const domain = "ethereum.on.eth";
const key = "interoperable-address";
// 2. Derive the Node (Namehash)
const node = namehash(domain);
// 3. Locate the Resolver for the node
const registry = getContract(ENS_REGISTRY_ADDRESS);
const resolverAddress = registry.resolver(node);
// 4. Instantiate the Resolver
const resolver = getContract(resolverAddress);
// 5. Resolve the Interoperable Address
// ENSIP-24 Interface: data(bytes32 node, string key) -> bytes
const rawData = resolver.data(node, key);
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:
/**
* Pseudocode to resolve a chain label from an ERC-7930 Interoperable Address
* Using ENSIP-5, the namespace reverse.on.eth, and the text record key chain-label:0x00010000010a00
*/
// 1. Inputs
const interoperableAddress = "0x00010000010a00";
const namespace = "reverse.on.eth";
// 2. Construct the specific Text Record Key
// Format: "chain-label:" + [ERC-7930 Address]
const textKey = "chain-label:" + interoperableAddress;
// 3. Derive the Node (Namehash) for the reverse namespace
const node = namehash(namespace);
// 4. Locate the Resolver for 'reverse.on.eth'
// As the resolver will be set on the second level domain `on.eth` consideration should be given to ENSIP-10
const registry = getContract(ENS_REGISTRY_ADDRESS);
const resolverAddress = registry.resolver(node);
// 5. Instantiate the Resolver
const resolver = getContract(resolverAddress);
// 6. Query the Text Record (ENSIP-5)
// Signature: text(bytes32 node, string key) -> string
const chainLabel = resolver.text(node, textKey);
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.
<address> componentIf 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 specification 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.
<address> component, accommodating users and applications that prefer traditional address representations.<address> component.Copyright and related rights waived via CC0.