diff --git a/ERCS/erc-7930.md b/ERCS/erc-7930.md index 63e23f08b1f..d1c922be8d9 100644 --- a/ERCS/erc-7930.md +++ b/ERCS/erc-7930.md @@ -4,7 +4,8 @@ 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) discussions-to: https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365 -status: Draft +status: Last Call +last-call-deadline: 2025-10-20 type: Standards Track category: ERC created: 2025-02-02 @@ -22,7 +23,7 @@ Current Ethereum addresses ([ERC-55]) lack chain specificity and have optional c - Addresses do not include any indication of the chain to which the address applies. This means chain information must be expressed out of band, and introduces the risk of an address being mistakenly used on a chain it is not valid for. This risk is particularly pronounced for addresses that represent smart contracts. - The existing address format provides no mechanism for extension, meaning that there is no natural method to add these features to the existing address format. -Interoperable Addresses build on insights from , [CAIP-10] and [CAIP-50], offering a unified format which combines: +Interoperable Addresses build on insights from [ERC-7828], [CAIP-10] and [CAIP-50], offering a unified format which combines: - Binding chain specificity (via explicit chain identifiers) to the raw address. - Compact & canonical binary format for use on cross-chain message passing and intent declaration. - Checksums for name collision mitigation & user error prevention. @@ -46,12 +47,18 @@ Also, the text format is of little use for smart contracts involved with cross-c Interoperable Names are convertible to [CAIP-10] without even going through the binary representation, so backwards-compatibility with actors expecting [CAIP-10] identifiers should not be an issue. +CAIP-10 also depends on CAIP-2, which limits the chain reference to 32 characters. The binary format of this standard natively supports chain identifiers of arbitrary length, removing this bottleneck and making the standard more future-proof. + The interop roadmap is better served by having a standardized binary format for addresses first, which allows the message passing and intents verticals to move forward on a common interface, with a good-enough text representation which is familiar to users and useful for developers, and as a next step develop a chain & address name resolving standard on top of it, leveraging its uniformity and extensibility. ## 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. +### Scope and Delegation to CAIP-350 + +A versioned, length-prefixed binary envelope for interoperable addresses. The interpretation and serialization of the payload inside that envelope are not standardized here; they are intentionally delegated to chain-specific profiles maintained by the Chain-Agnostic Standards Alliance (CASA), notably [CAIP-350]. Implementations MUST consult the relevant [CAIP-350] profile for a target namespace/chain to obtain the authoritative rules for binary serialization, display, and round-tripping of addresses. + ### Concepts Interoperable Address : A binary payload which unambiguously identifies a target address and allows conversion to a human-readable name. @@ -208,6 +215,10 @@ Interoperable Address: keccak256 input for checksum: `0x00022045296998a6f8e2a784db5d9f95e18fc23f70441a1039446801089879b08c7ef000`. Note the version field is removed before hashing. + +## Reference Implementation +You can check the latest status on [this comment](https://ethereum-magicians.org/t/erc-7930-interoperable-addresses/23365/13). + ## 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. @@ -216,14 +227,11 @@ It is therefore advised for implementers requiring canonicity of addresses (e.g ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). - [ERC-55]: ./eip-55.md -[ERC-7785]: ./eip-7785.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