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 on-chain 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 on-chain registry.
View Specification →SDK & Implementation
Install the SDK to implement Interoperable Addresses in your application.
$ npm install @wonderland/interop-addressesFrequently 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. For implementation examples and guides, see the Interop SDK documentation.
What is the status of the onchain chain registry?
The onchain chain registry is currently under development in the chain-resolver project and is approaching final testing. It will be powered by a custom ENS resolver under the dedicated ENS name on.eth. Until this is live, the SDK uses data from ethereum-lists/chains, using shortName values as identifiers.
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
