ERC-7930 Interoperable address (Interoperable Addresses)
Review · Names & metadata · created 2025-02-02
Defines a format that combines an address and its associated chain information into a single binary value. It can hold addresses from chains other than Ethereum, such as Solana, within the same framework.
Why it is needed
The address format used on Ethereum mainnet (ERC-55) is also used identically by many other blockchains. However, this format contains no information about which chain the address is intended for, so the same address can exist on multiple chains, creating ambiguity and operational risk. As a result, each protocol has created its own ad hoc method for combining addresses and chains, typically by adding a separate field or using protocol-specific conventions. This fragmentation makes cross-protocol interoperability difficult, complicates tooling, and causes notation inconsistencies at the infrastructure level. An existing text-based standard (CAIP-10) exists, but strings are inefficient to store and handle in on-chain contracts, and the chain reference length is limited to 32 characters, which cannot losslessly represent some chains. This proposal solves this problem with an extensible binary standard format that combines chain identification information and the address into one.
In depth
Binary structure: six fields
An interoperable address is a binary value consisting of the fields Version, ChainType, ChainReferenceLength, ChainReference, AddressLength, and Address in that order. Version is 2 bytes and must be 0x0001 in big-endian for this specification (version 1). ChainType is a 2-byte value corresponding to a CASA namespace, and it determines how the following ChainReference and Address are interpreted and displayed. ChainReferenceLength is a 1-byte integer holding the byte length of ChainReference, and ChainReference is a variable-length binary value pointing to the chain. AddressLength is a 1-byte integer holding the byte length of Address, and Address is the variable-length binary encoding of the serialized address. Because length fields precede the data, arbitrary-length data can be held.
Serialization rules are defined by CAIP-350
This standard itself defines only the envelope structure; the interpretation and serialization rules for the data inside the envelope are defined by the companion standard CAIP-350. CAIP-350 provides profiles by chain type, and within a given namespace, the serialization of ChainReference must follow the algorithm defined in that namespace's CAIP-350 profile. The serialization of Address must also follow the rules in the CAIP-350 profile for that ChainType. Chain profiles are maintained by the Chain-Agnostic Standards Alliance (CASA). Because namespace-specific rules are separated out this way, supporting a new chain type only requires adding a profile, without needing to change the format itself.
Zero-length fields and chain identifiers
ChainReferenceLength can be 0, in which case the interoperable address must not include a chain reference. For example, this can represent an EVM address that does not specify a particular chain. AddressLength can also be 0, in which case the value becomes a Chain Identifier referring to the chain itself rather than an address, and must not include an address. However, if ChainReferenceLength is 0, AddressLength must not be 0. The reason both fields are allowed to be zero-length is to let a single unified standard handle multiple use cases. It allows representing either an address usable on any compatible chain, or representing the chain itself alone.
Encoding shown through an example
Encoding the Ethereum mainnet address 0xd8dA6bF26964aF9D7eEd9e03E53415D37aA96045 produces 0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045. Version is 0x0001, ChainType is 0x0000, ChainReferenceLength is 1, ChainReference is 1, AddressLength is 20 (0x14), followed by the 20-byte address. Solana mainnet uses ChainType 0x0002 with a 32-byte ChainReference and a 32-byte Address. An EVM address that omits the chain reference starts with 0x000100000014, and the Solana mainnet chain identifier ends with AddressLength of 0. If displaying it directly on screen, a lowercase hexadecimal string representation is recommended.
Versioning rules and backward compatibility
The Version field is 2 bytes, and it is recommended that future versions be standardized as a separate ERC. Future versions should be easily convertible to this specification's interoperable address format, and if a format is not backward compatible with this specification's parsing rules, the most significant bit of the version field must be set to 1. It must also be possible to define an address, a chain, or both, and while fields may be added, the data needed to reconstruct a version 1 interoperable address exactly, bit for bit, must not be changed or removed. Versions that represent only a subset of a CAIP namespace are also permitted.
Comparison with existing standards
CAIP-10 is a text-format standard for representing an address on a specific chain, but it does not define serialization and normalization rules for the target address and assumes knowledge of each chain's native address format. Also, strings are inefficient for on-chain data storage, making them unsuitable for use within contracts. CAIP-2, which CAIP-10 depends on, limits chain references to 32 characters; for example, Solana uses the first 32 characters of the base58btc-encoded genesis block hash, which is not a representation that uniquely determines the chain. This standard avoids these limitations with a binary format, and for cases requiring a human-readable representation, it defers to a separate standard such as ERC-7828. Existing standards could not easily be extended to add such features, which is why a new extensible format was created.
A proposal still under review
The status of this proposal is Review. Since it has not yet been finalized, its content may change.
Things to watch out for
- Canonicity of addresses is not always guaranteed: This standard aims to provide a foundation for canonically referring to addresses across multiple chains, but in practice that guarantee can leak. Some chain namespaces may define serialization methods that cannot guarantee address canonicity, and a single network may have two valid CAIP-2 identifiers.
- Profiles should be reviewed before using this as a mapping key: Implementers who use an address for purposes requiring canonicity, such as a contract mapping key or key-value store key, are advised to carefully review the CAIP-350 profile for the relevant chain namespace to check for the possibility of broken canonicity (which should be documented in the profile's Extra Considerations section) and for potential conflicts with other namespaces already supported.