Why do we need this?
Ethereum is multichain
Apps, wallets, infrastructure providers and onchain protocols need ways to refer to an account on a specific chain.
Mistakes matter
Sending to the address on the wrong chain can mean lost funds.
Ad hoc approaches
Currently apps, wallets, and protocols implement ad hoc approaches to identifying a chain-specific address, leading to fragmentation and hindering interoperability.
No good solutions today
Existing standards do not work across use-cases and chains.
How does it work?
ERC-7930: a compact binary Interoperable Address format for use in smart contracts and other machine-readable contexts.
ERC-7828: an Interoperable Name format for end-users, optionally using ENS and an onchain chain registry for maximum readability.
These standards work together to support interoperability use-cases across Ethereum.
The Specifications
CAIP-350
Cross-Chain Address Serialization
Living specification that defines how blockchain addresses and chain identifiers are serialized. Each blockchain namespace (Ethereum, Bitcoin, Solana, etc.) maintains its own implementation profile.
View Specification →ERC-7930
Interoperable Addresses
Binary format that binds address and chain together — compact, verifiable, and extensible across any blockchain ecosystem, as long as they have a CAIP-350 profile.
View Specification →ERC-7828
Human-readable Interoperable Names
Defines a standard <address>@<chain> text representation, supporting optional resolution of ENS names and readable chain identifiers based on an onchain registry.
View Specification →SDK & Implementation
Install the SDK to implement Interoperable Addresses in your application.
$ npm install @wonderland/interop-addresses viemFrequently Asked Questions
Why two separate ERCs?
ERC-7930 provides the foundational binary format that works everywhere, but is optimised for use in smart contracts. ERC-7828 focuses on human-readable addresses, adding ENS integration for better UX and checksums for safe sharing.
What about chain abstraction?
These ERCs complement chain abstraction. While abstraction hides complexity, interoperable addresses ensure safety when users DO need to know which chain they're using. Think of it as "abstraction with transparency."
Do I need to use ENS?
No. ERC-7930 works with raw addresses. ENS (via ERC-7828) is optional but recommended for better UX.
Does this work with non-EVM chains?
Yes! Both ERCs can support addresses on non-EVM chains throughout Ethereum, and can be extended to support non-Ethereum chains such as Bitcoin. The specifications build upon CAIP-350, a meta-specification that defines binary encoding for blockchain addresses across different ecosystems.
What is CAIP-350 and how does it relate to Interoperable Addresses?
CAIP-350 is a living specification from the Chain Agnostic Standards Alliance that provides a template for how different blockchain ecosystems serialize addresses and chain identifiers. Each blockchain namespace (Ethereum, Bitcoin, Solana, etc.) maintains its own implementation profile. ERC-7930 and ERC-7828 leverage this registry for serialization and deserialization of chain-specific addresses.
What kind of developers can use Interoperable Addresses?
Wallet and app developers can use Interoperable Addresses (ERC-7828 + ERC-7930) to create standardized and legible send flows. Infrastructure developers can simplify cross-chain interactions using the compact ERC-7930 binary standard.
How do I get started as a developer?
Install the SDK: npm install @wonderland/interop-addresses viem. For implementation examples and guides, see the Interop SDK documentation.
What is the status of the onchain chain registry?
on.eth is a canonical, ENS-native registry for chains and their associated metadata, covering networks such as Base, Arbitrum, or Ethereum. The ENS DAO has approved usage of the domain for this purpose, and the registry is being initialized with chains using the custom chain resolver. Learn more about the registry in the ENS blog post. The registry is available as an experimental feature in the interop-addresses package.
What if a name resolves to different addresses?
The Interoperable Name specification includes 4-byte checksums calculated over the resolved Interoperable Address. If a name resolves to a different address or there's an error, the checksum won't match and will alert about the problem. Checksums help prevent errors and detect inconsistencies in resolution.
Backed by the Ethereum community
