--- eip: 7930 title: Interoperable Addresses description: An extensible binary format to refer to an address specific to one chain. author: Teddy (@0xteddybear), Joxes (@0xJoxess), Nick Johnson (@Arachnid), Francisco Giordano (@frangio), Skeletor Spaceman (@skeletor-spaceman), Racu (@0xRacoon), TiTi (@0xtiti), Gori (@0xGorilla), Ardy (@0xArdy), Onizuka (@onizuka-wl), Sam Kaufman (@SampkaML), Marco Stronati (@paracetamolo), Yuliya Alexiev (@yuliyaalexiev), Jeff Lau (@jefflau), Sam Wilson (@samwilsn), Vitalik Buterin (@vbuterin), Thomas Clowes (@clowestab), Mono (@0xMonoAx), Prem Makeig (@nxt3d), Orca (@0xrcinus) discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365 status: Draft type: Standards Track category: ERC created: 2025-02-02 --- ## Abstract 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 the [CAIP-350] companion standard, which provide profiles for each chain type and defines the serialization rules for each namespace. ## Motivation The address format utilized on Ethereum mainnet ([ERC-55]) is shared by a large number of other blockchains. 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: - Binds together chain identification and the raw address. - Is compact for usage with cross-chain message passing and intent declaration. - Extends beyond EVM blockchains. These features can not be added to existing standards as they are not easily extensible - this one is. ### Comparisons with other standards #### CAIP-10 [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. ## Specification 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. ### Terminology **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: - The _Interoperable Address_ definition outlined in this specification - The addressing format outlined in [ERC-3770], e.g. `arb:0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045` - The _Interoperable Name_ definition outlined in [ERC-7828] **Interoperable Address** : A binary payload which unambiguously identifies a _target address_ on a target chain. e.g. `0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045` ### _Interoperable Address_ Definition An _Interoperable Address_ as defined by this standard MUST have the following binary format: ``` ┌─────────┬───────────┬──────────────────────┬────────────────┬───────────────┬─────────┐ │ Version │ ChainType │ ChainReferenceLength │ ChainReference │ AddressLength │ Address │ └─────────┴───────────┴──────────────────────┴────────────────┴───────────────┴─────────┘ ``` 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. ### Examples #### Example 1: Ethereum mainnet address **Components** | Key | Value | | :--- | :--- | | **Version** | `1` | | **ChainType** | `0x0000` | | **ChainReferenceLength** | `1` | | **ChainReference** | `1` | | **AddressLength** | `20` | | **Address** | `0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045` | **Interoperable Address** These components produce the following _Interoperable Address_: ``` 0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045 ^^^^-------------------------------------------------- Version ^^^^---------------------------------------------- ChainType ^^-------------------------------------------- ChainReferenceLength ^^------------------------------------------ ChainReference ^^---------------------------------------- AddressLength ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Address ``` --- #### Example 2: Solana mainnet 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_: ``` 0x000100022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef02005333498d5aea4ae009585c43f7b8c30df8e70187d4a713d134f977fc8dfe0b5 ^^^^---------------------------------------------------------------------------------------------------------------------------------------- Version ^^^^------------------------------------------------------------------------------------------------------------------------------------ ChainType ^^---------------------------------------------------------------------------------------------------------------------------------- ChainReferenceLength ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^------------------------------------------------------------------ ChainReference ^^---------------------------------------------------------------- AddressLength ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- Address ``` --- #### Example 3: EVM address without ChainReference **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_: ``` 0x000100000014d8da6bf26964af9d7eed9e03e53415d37aa96045 ^^^^------------------------------------------------ Version ^^^^-------------------------------------------- ChainType ^^------------------------------------------ ChainReferenceLength ^^---------------------------------------- AddressLength ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Address ``` --- #### Example 4: Solana mainnet network, no 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_: ``` 0x000100022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef000 ^^^^------------------------------------------------------------------------ Version ^^^^-------------------------------------------------------------------- ChainType ^^------------------------------------------------------------------ ChainReferenceLength ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-- ChainReference ^^ AddressLength ``` ### Versioning These rules ensure that future standards that build upon this one maintain backwards compatibility. Future versions: - MUST be trivially convertible to the _Interoperable Address_ format defined in this specification - MUST set the most significant bit of the version field to 1 if the _Interoperable Address_ format is not backward-compatible with the parsing rules outlined herein - MUST support defining an address, a chain, or both - MAY add fields but MUST NOT alter or omit any data required to reconstruct the Version 1 _Interoperable Address_ exactly, bit for bit - MAY only be able to represent a subset of the CAIP namespaces ### Text representation 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 as a lowercase hexadecimal string. [ERC-7828] is one example of a human-readable _chain-specific address_ definition that can be displayed in user-facing contexts. The companion standard, CAIP-350, specifies on a per-namespace basis, the rules for converting the `ChainReference` and `Address` components of the _Interoperable Address_ into human readable representations. These MAY be displayed in user-facing contexts. ## Rationale This ERC defines a compact binary format for representing a *chain-specific address*, primarily intended for use within smart contracts. For other contexts—such as display to end users or programmatic use in APIs—alternative *chain-specific addressing* standards may be more appropriate. For example, [ERC-7828] specifies a human-readable *chain-specific address* format. 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: - We chose to allow the `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. - We chose *not* to use alternate encoding formats (e.g., `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. ## Security Considerations 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 Copyright and related rights waived via [CC0](../LICENSE.md). [ERC-55]: ./eip-55.md [ERC-3770]: ./eip-3770.md [ERC-7828]: ./eip-7828.md [CAIP-2]: https://github.com/ChainAgnostic/CAIPs/blob/2a7d42aebaffa42d1017c702974395ff5c1b3636/CAIPs/caip-2.md [CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/2a7d42aebaffa42d1017c702974395ff5c1b3636/CAIPs/caip-10.md [CAIP-50]: https://github.com/ChainAgnostic/CAIPs/blob/2a7d42aebaffa42d1017c702974395ff5c1b3636/CAIPs/caip-50.md [CAIP-350]: https://github.com/ChainAgnostic/CAIPs/blob/29762ef99a6ffea1e07e3f796c0d1a5a95e89b88/CAIPs/caip-350.md