ERC-7930 - Interoperable Addresses

Abstract

This proposal introduces a binary format to describe a chain specific address. Additionally, it defines a human-readable version of that identifier, which improves the user experience in user-facing interactions.

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.

Motivation

The address format utilized on Ethereum mainnet (ERC-55) is shared by a large number of other blockchains. The format does not include details of the chain on which an interaction should occur. This introduces risk if, for example, a transaction is mistakenly executed on a chain where the address is inaccesible. This risk is particularly pronounced for addresses that represent smart contracts or smart accounts.

This proposal builds on insights from CAIP-10 and CAIP-50. It offers both a binary canonical Interoperable Address format and a human readable Interoperable Name format which:

• Binds together chain identification and the raw address.
• Is compact for usage with cross-chain message passing and intent declaration.
• Includes short, easily verififiable checksums to protect users.
• 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.

An Interoperable Name contains all of the components of the CAIP-10 identifier. It is therefore easy to convert between the two in cases where the CAIP-10 standard is still in use.

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 context of the Interoperable Name and Interoperable Address 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 Interoperable Name definition outlined in this specification
• The addressing format outlined in ERC-3770, e.g. arb:0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045

Interoperable Address : A binary payload which unambiguously identifies a target address on a target chain. e.g. 0x00010000010114D8DA6BF26964AF9D7EED9E03E53415D37AA96045

Interoperable Name : A string representation of an Interoperable Address, meant to be used by humans. e.g. 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155:1#4CA88C9C

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.

Interoperable Name Definition

Recall that an Interoperable Name is a human readable representation of an underlying Interoperable Address.

Its format is <address> @ <chain> # <checksum> where the components match the following regular expressions:

Syntax

<address>             ::= [.-:_%a-zA-Z0-9]*
<chain>               ::= [.-:_a-zA-Z0-9]*
<checksum>            ::= [0-9A-F]{8}

These components have the following meanings:

<address> is the target address. If you are targeting all addresses within a CASA namespace (i.e., when AddressLength is zero), use an empty string.

<chain> is the string representation of a specific blockchain as defined in CAIP-350. For example eip155:1 for Ethereum Mainnet, or solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d for Solana Mainnet.

If you are representing a specific address namespace without intending to refer to a particular chain (i.e., when ChainReferenceLength is zero), use the CASA namespace alone, with no trailing colon - for example, eip155 or solana. It is not possible to specify a reference without a namespace.

The 4-byte <checksum> is the first 4 bytes of the hexadecimal (RFC 4648) string representation of a keccak256 hash. This hash is computed over the concatenation of the Interoperable Address's binary fields: ChainType, ChainReferenceLength, ChainReference, AddressLength, and Address. The Version field MUST NOT be included in the hashed data.

Checksums

A 4-byte checksum MUST be computed and included when sharing an Interoperable Name.

If a user-provided Interoperable Name includes a checksum, clients MUST derive the underlying Interoperable Address, recalculate the checksum, and compare it to the provided value. In case of a mismatch, clients MUST warn the user and require explicit user input to continue with the operation.

Clients MAY include the checksum when displaying an Interoperable Name within their interface. Clients MAY accept Interoperable Name inputs without a checksum.

When displayed the checksum MUST be displayed using the 'Base 16 Alphabet', [0-9A-Z] as defined in RFC 4648.

Parsing and Serialization:

When parsing an Interoperable Name to generate its binary Interoperable Address, clients MUST follow the normalization and serialization rules defined in the relevant CAIP-350 profile for the given <chain> and <address>. This ensures that different valid text representations (e.g., case variations in an address) resolve to a single, canonical binary form, which is essential for consistent checksum calculation and data integrity.

Examples

Example 1: Ethereum mainnet address

Components

Interoperable Address

These components produce the following Interoperable Address:

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

Interoperable Name

The Interoperable Name representation is:

Example 2: Solana mainnet address

Components

Interoperable Address

These components produce the following Interoperable Address:

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

Interoperable Name

The Interoperable Name representation is:

Example 3: EVM address without ChainReference

Components

Interoperable Address

These components produce the following Interoperable Address:

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

Interoperable Name

The Interoperable Name representation is:

Example 4: Solana mainnet network, no address

Components

Interoperable Address

These components produce the following Interoperable Address:

0x000100022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef000
  ^^^^------------------------------------------------------------------------ Version
      ^^^^-------------------------------------------------------------------- ChainType
          ^^------------------------------------------------------------------ ChainReferenceLength
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-- ChainReference
                                                                            ^^ AddressLength

Interoperable Name

The Interoperable Name representation is:

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
• MUST use the checksum algorithm outlined in this standard
• MAY only be able to represent a subset of the CAIP namespaces
• MAY introduce stricter syntactic rules for the Interoperable Name (thereby narrowing the set of valid strings), but MUST NOT introduce new syntactic forms that enlarge the grammar.
• MUST allow for the appropriate binary data to be derived from the Interoperable Name to allow for the construction of an Interoperable Address encoded as defined in this specification

Rationale

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:

• The @ symbol is used as a separator as it provides visual clarity to humans, is easy for software to parse, and avoids confusion with the colon (:) symbol utilized in CAIP-2, and CAIP-10 identifiers.
• No length restriction is placed on addresses, allowing for chains with longer address formats to be represented.
• The address field includes % as a valid character to allow for URL-encoding of any other characters that are not explicitly allowed. This allows backward compatibility with CAIP-10.
• We chose to support zero-length addresses and chain IDs 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. Whilst utilizing alternate formats could have reduced the size of the Interoperable Name we decided that user and developer experience should be prioritized.
• Checksums are short enough to be visually comparable by the human eye, allowing for easy differentiation.

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.