This proposal introduces a binary format to describe a chain-specific address.
This is achieved through a versioned, length-prefixed binary envelope that supports arbitrary-length data. The interpretation and serialization rules for the data within this envelope are defined by companion standards (CAIP-350), which provide profiles for each chain type and define the serialization rules for each namespace.
The address format utilized on Ethereum mainnet (ERC-55) is shared by a large number of other blockchains. However, this format does not encode any information about the chain on which an interaction is intended to occur, which can introduce ambiguity and operational risk.
In practice, this limitation has led each protocol to define its own ad hoc way of representing the combination of address and chain, typically using separate fields and protocol-specific conventions. This fragmentation complicates interoperability across protocols, increases tooling complexity, and leads to inconsistencies at the infrastructure level.
This proposal builds on insights from CAIP-10 and CAIP-50. It offers a binary canonical Interoperable Address format which:
These features can not be added to existing standards as they are not easily extensible - this one is.
CAIP-10 proposes a standard text format to represent an address on a specific chain (referenced by its CAIP-2 identifier).
The standard does not concern itself with the serialization/deserialization of the target address. It assumes knowledge of the native address format for each chain and does not enforce any serialization or canonicalization rules.
While it is trivial to add support for chains to CAIP-10, the format is not optimized for usage within smart contracts as strings are an inefficient way to store data on-chain.
CAIP-10 depends on CAIP-2, which limits the chain reference to 32 characters. This constraint means that CAIP-2 can not losslessy represent a chain. e.g. Solana chains utilize the leading 32 characters of the base58btc-encoded genesis blockhash, which is not a uniquely deterministic way of representing a chain.
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.
Target Address
: The address itself, independent of chain context. Serialized per the CAIP-350 rules for the applicable namespace. In the examples below, the target address is 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045.
Chain-specific Address : An address representation that includes both the target address and the chain being targeted. The following are examples of chain-specific addresses:
arb:0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045Interoperable Address
: A binary payload which unambiguously identifies a target address on a target chain. e.g. 0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045
An Interoperable Address as defined by this standard MUST have the following binary format:
The components outlined above have the following meanings:
Version
: A 2-byte version identifier. For version 1 (this specification), this MUST be 0x0001 (big-endian). Future versions SHOULD be standardized in separate ERCs.
ChainType : A 2-byte value corresponding to a CASA namespace. It allows users to interpret and display the ChainReference and Address. Values are defined in the corresponding CAIP-350 profile for the namespace.
ChainReferenceLength : A 1-byte integer encoding the length of ChainReference in bytes. Note that it MAY be zero, in which case the Interoperable Address MUST NOT include a chain reference.
ChainReference : Variable length, binary representation of the CAIP-350 chain reference. Serialization of the ChainReference within a specific namespace MUST follow the algorithm defined in the namespace's CAIP-350 profile. Chain profiles are maintained by the Chain-Agnostic Standards Alliance (CASA).
AddressLength : 1-byte integer encoding the length of Address in bytes. Note that it MAY be zero, in which case the Interoperable Address MUST NOT include an address. It MUST NOT be zero if the ChainReferenceLength is also zero.
Address : Variable length field containing the binary encoding of the characters of the serialized address. The serialization for a specific ChainType MUST follow the rules of its corresponding CAIP-350 profile.
If you choose to display an Interoperable Address it is RECOMMENDED that you display it as a lower case hexadecimal string.
Components
| Key | Value |
|---|---|
| Version | 1 |
| ChainType | 0x0000 |
| ChainReferenceLength | 1 |
| ChainReference | 1 |
| AddressLength | 20 |
| Address | 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 |
Interoperable Address
These components produce the following Interoperable Address:
Components
| Key | Value |
|---|---|
| Version | 1 |
| ChainType | 0x0002 |
| ChainReferenceLength | 32 |
| ChainReference | 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d |
| AddressLength | 32 |
| Address | MJKqp326RZCHnAAbew9MDdui3iCKWco7fsK9sVuZTX2 |
Interoperable Address
These components produce the following Interoperable Address:
Components
| Key | Value |
|---|---|
| Version | 1 |
| ChainType | 0x0000 |
| ChainReferenceLength | 0 |
| ChainReference | N/A |
| AddressLength | 20 |
| Address | 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045 |
Interoperable Address
These components produce the following Interoperable Address:
Components
| Key | Value |
|---|---|
| Version | 1 |
| ChainType | 0x0002 |
| ChainReferenceLength | 32 |
| ChainReference | 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d |
| AddressLength | 0 |
| Address | N/A |
Interoperable Address
These components produce the following Interoperable Address:
These rules ensure that future standards that build upon this one maintain backwards compatibility.
Future versions:
This specification defines a canonical binary representation that is not intended to be used directly in user-facing contexts. If an implementer chooses to display an Interoperable Address directly, it is RECOMMENDED that it be represented in lowercase hexadecimal string.
The conversion of an Interoperable Address to and from text representations isn’t defined by this ERC, but by the companion standards established in CAIP-350. CAIP-350 specifies, on a per-namespace profile basis, the rules for converting the binary components (ChainReference and Address) into their text representations, which MAY be used for the presentation of chain-specific addresses in user-facing contexts.
ERC-7828 follows this approach and augments it to provide a more human-readable text representation of an Interoperable Address for end-users.
This ERC defines a compact binary format for a chain-specific address, primarily for use in smart contracts. Other contexts (such as display to end-users or programmatic use in APIs) may prefer a different representation of a chain-specific address. For the sake of simplicity, definition of these representations is left to other ERCs, such as ERC-7828, which defines a human-readable string representation of a chain-specific address.
The interoperability roadmap benefits significantly from first having a standardized binary format for addresses, which allows the message passing and intents verticals to move forward on a consistent common interface.
The rationale for some of the low level specification decisions are outlined below:
Address and ChainReference components to be zero-length to make this standard flexible and to allow developers to use a single, uniform standard for many different jobs. For example if a user wants to represent an address on any compatible chain, or if the user simply wants to represent the chain itself.base58 or base64) in order to make it easier for wallets and dApps to work with, and convert between, addresses that both use and do not use this addressing standard.While this standard aims to be a foundation to be able to canonically refer to addresses on different chains, that guarantee is going to be a leaky abstraction in the real world, given that e.g. a particular chain namespace might define a serialization scheme that can't guarantee canonicity of addresses, or a given network might have two valid CAIP-2 ids referring to it.
It is therefore advised for implementers requiring canonicity of addresses (e.g by using them as keys in smart contract mappings or other key-value stores), to thoroughly review the CAIP-350 profile of a chain namespace for the possibility of a lack of canonicity of addresses (which should be noted in the profile's 'Extra Considerations' section) as well as collisions with other already-supported namespaces.
Copyright and related rights waived via CC0.