ERC-7930: Interoperable Addresses

An extensible binary format to refer to an address specific to one chain.

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

Interoperable Address

These components produce the following Interoperable Address:

0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045
  ^^^^-------------------------------------------------- Version              
      ^^^^---------------------------------------------- ChainType            
          ^^-------------------------------------------- ChainReferenceLength
            ^^------------------------------------------ ChainReference       
              ^^---------------------------------------- AddressLength       
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Address             

Example 2: Solana mainnet address

Components

Interoperable Address

These components produce the following Interoperable Address:

0x000100022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef02005333498d5aea4ae009585c43f7b8c30df8e70187d4a713d134f977fc8dfe0b5
  ^^^^---------------------------------------------------------------------------------------------------------------------------------------- Version
      ^^^^------------------------------------------------------------------------------------------------------------------------------------ ChainType
          ^^---------------------------------------------------------------------------------------------------------------------------------- ChainReferenceLength
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^------------------------------------------------------------------ ChainReference
                                                                            ^^---------------------------------------------------------------- AddressLength
                                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^--- Address

Example 3: EVM address without ChainReference

Components

Interoperable Address

These components produce the following Interoperable Address:

0x000100000014d8da6bf26964af9d7eed9e03e53415d37aa96045
  ^^^^------------------------------------------------ Version
      ^^^^-------------------------------------------- ChainType
          ^^------------------------------------------ ChainReferenceLength
            ^^---------------------------------------- AddressLength
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Address

Example 4: Solana mainnet network, no address

Components

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.

Citation

Please cite this document as:

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), "ERC-7930: Interoperable Addresses [DRAFT]," Ethereum Improvement Proposals, no. 7930, February 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7930.