eip155 Namespace - Interoperable Address

Author Teddy, Joxes, Skeletor Spaceman, Racu, TiTi, Gori, Ardy, Onizuka
Discussions-To https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365
Status Draft
Type Standard
Created 2025-04-23
Requires CAIP-2

Table of Contents

Namespace Reference

ChainType binary key: 0x0000 CAIP-104 namespace: eip155

Chain reference

See EIP-155 and EIP-2294.

Text representation 

eip155:<number>

Where <number> is the decimal representation of the chain’s chainId, without leading zeroes.

Text representation -> CAIP-2 conversion

In the case where the chainId is larger than what can be represented in 32 decimal characters, the leading 32 characters should be used.

CAIP-2 - text representation conversion

This transformation would not be fully deterministic in the case where chainIds larger than 10^32 are used. It is assumed wallets and other software will be able to differentiate between chains from just the leading 32 decimal characters, and use a lookup table of popular chains to complete the missing information to convert CAIP-2 identifiers to this standard.

Binary representation

The bare chainId encoded as a big-endian unsigned integer of the minimum necessary amount of bytes will be used 1, and leading zeroes will be prohibited.

Text -> binary conversion

Encode the decimal integer as a big-endian unsigned integer using the minimum necessary amount of bytes.

Binary -> text conversion

Compute the decimal representation of the stored big-endian unsigned integer.

Examples

Ethereum Mainnet: 0x01 (integer 1, encoded as uint8)

Optimism Mainnet: 0x0A (integer 10, encoded as uint8)

Ethereum Sepolia: 0xaa36a7 (integer 11155111, encoded as uint24)

Addresses

Bytes of EVM addresses are trivially stored as the payload. It’s worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes 2

Text representation

For text representation, the 20 bytes of EVM addresses should be hexadecimal-encoded according to EIP-55. This standard deliberately does not define the text representation of EVM addresses if they are extended in the future, since it’s not possible to know which human-readable representation will be more familiar to users in such hypothetical scenario. This profile should be amended in the future to reflect it in such a case.

Text representation -> customary text address formats conversion

See EIP-55.

Customary text addresses -> text representation conversion

See EIP-55.

Binary representation

Bytes of EVM addresses are trivially stored as the payload. It’s worth noting that addresses are currently 20 bytes, but that might change in the future, most likely to 32 bytes 2.

Text -> binary conversion

Specified in EIP-55.

Binary -> text conversion

Specified in EIP-55.

Examples

See EIP-55.

Extra considerations

Wallets and other software are expected to be able to fetch the extra information needed to convert from CAIP-2 to this standard.

References

  1. This makes it possible to represent some chains using the full word as their chainid, which CAIP-2 does not support since the set of values representable with 32 a-zA-Z0-9 characters has less than type(uint256).max elements. This is done in an effort to support chains whose ID is the output of keccak256, as proposed in [ERC-7785]. ↩

  2. With EVM Object Format as a prerequisite, Address Space Expansion could be implemented. If that happens, expanded addresses may be represented in 32 bytes, but pre-expansion addresses must remain 20 bytes in order to preserve a consistent address. ↩ ↩2

Citation

Please cite this document as:

Teddy, Joxes, Skeletor Spaceman, Racu, TiTi, Gori, Ardy, Onizuka, "namespaces/eip155-caip350: eip155 Namespace - Interoperable Address [DRAFT]," Chain Agnostic Namespaces, eip155-caip350, April 2025 / . [Online serial]. Available: https://github.com/ChainAgnostic/namespaces/eip155-caip350.md