ERC 7930: Interoperable Addresses

ERCs
1

Abstract

Interoperable Addresses is a binary format to describe an address specific to one chain with an optional human-readable name representation.
It is designed in a manner that allows the community extend it to support naming schemes (or other not-yet-imagined features) in the future, as well as to support arbitrary-length addresses and chainids.

ERC pull request: Add ERC 7930: Interoperable Addresses by 0xteddybear · Pull Request #1002 · ethereum/ERCs · GitHub

Context

After extensive discussions on the various interop groups and an attempt to push this as a rewrite of ERC-7828, we are pushing a binary-first Interoperable Addresses format, and would like your feedback on the subject.

While we’ve made an effort to list related cross-chain naming & addressing efforts in the ERC itself, I believe some extra content is warranted here:

Initially we tried to push for a single standard to both take care of cross-chain addressing and cross-chain naming, normatively defining both binary and human-readable (in string form) representations for addresses, with varying levels of resolution into more condensed names with the help of ENS and similar resolvers.

We then realized that kind of standard would have two disjoint sets of users:

  • Wallet developers, which cared mostly about naming and only tangentially about canonicity or binary encoding.
  • On-chain infrastructure (such as cross-chain messaging and liquidity bridging) developers, who have strict requirements on binary payload compactness and canonicity but do not care about naming registries or human-readable representations.

This is a standard aiming to meet the needs of the latter, while hopefully being a building block in achieving the former as well.

Feedback wanted on:

  • How should we coordinate with CASA for it to be the registry where future chain/address types are appended? Ideally I’d like to end up with something resembling BIP-0044/SLIP-0044, where this standard reaches finality with support for a small set of highly-desired chains, and specifications required to support other chains in the future is maintained down the line in the respective chain namespaces
  • What should we do about the CAIP-2 limitation on the chain reference’s length? Frangio mentions this standard is actually something different from CAIP-2, as it would be quite hard to convert actual CAIP-2 identifiers to this format, since it’d require extra data not available in the name itself. Also, it would not be possible to define a clear truncation scheme, since CAIP-2 identifiers are text which will have different bounds on what can it store based on the encoding used (eg 16 bytes for base16, or a bit more for base58).
  • Should we be more normative with the string representation? less? remove it altogether?
2 Likes
2

teddy’s devlog:

  • Changed how Solana chain reference serialization works so it’s more easily convertible to CAIP-2. Note that I’m not trying to push for standarization of Solana addresses for any other reason than to provide an example of how the standard is extensible to other domains.
  • Defined the case where an address/chain field has a length of zero, which also allows interfaces to consistently use Interoperable Address types when they want to represent (a) a chain, (b) an address, where the chain information is not important or can be assumed, and (c) representing a target address as was the initial scope for the ERC. Had to move the chain reference information outside of the ‘chain’ field, in order for users to know how to interpret the address when the chain reference is not present.
  • Will work on (yet another) revamp of 7828 which will leverage the definitions on this document to define better human-readable names by using registries
  • I made references to a ‘relevant CASA profile’ which I haven’t defined yet, but I guess it’s not that crucial for the immediate future. Will tackle that next.
3

Question: Would this be compatible with UTXO-based chains like Bitcoin or does it assume an Ethereum-style account-based model? IMO an interoperability scheme like this should try to be open in terms of not being locked in to EVM semantics and at least describing how it would work with Bitcoin would be a good signal that this has been properly considered.

4

Would this be compatible with UTXO-based chains like Bitcoin or does it assume an Ethereum-style account-based model?

Yes! It would be compatible with UTXO-based chains. The reason I didn’t include Bitcoin into the first draft is that it’s address serialization scheme is not as trivial as Solana’s (or most account-based chains tbh), and wanted to avoid specifying how to reliably serialize all the kinds of Bitcoin addresses and then realizing the community wanted something else entirely.

It’s worth noting that, since the serialization scheme is going to be defined as a CASA profile, it does not need to be hard-coded into this spec, and can be added after this ERC is finalized. It’s not very likely this will be tha case for Bitcoin, but is the expected path for other chains to be part of the standard.

2 Likes