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
5

I posted my feedback here: New CAIP profile: interoperable address binary specification by 0xteddybear · Pull Request #350 · ChainAgnostic/CAIPs · GitHub

1 Like
8

Pasting some discussions Lumi started on the PR, regarding checksums:

could checksums fail or be improperly validated?

I refrained from writing UX guidelines in this document given that it’s mostly concerned with binary addresses, but imagine wallets not giving enough prominence to checksums so they are missed by users could be a possible failure mode.
I didn’t add them on ERC-7828 either, since:

  • Wallet’s UX developers will probably be better at choosing how to display information than what I can come up with (@skeletor-spaceman came up with the example of using blockies instead of text checksums, for example)
  • There’s not an adversarial relationship between a given wallet’s UX designer and anybody else which could be mitigated by a standard’s normative.

Collisions on 4-byte checksums are feasible to mine, but it’s unlikely the impersonator’s address (or in the case of ERC-7828, name) is also a lookalike of the intended recipient’s

…well, that hinges on the wallet displaying the name also having sane warnings around unicode glyph collisions, in the case if 7828. Will add it as a security consideration of that standard.

I also considered the possibility of hash collisions happening because of there not being a delimiter between address and chainid, but that seems harder to exploit than the fact that checksums are only 4`bytes long

Could misinterpreted chain identifiers lead to funds loss?

Most definetely, but for non-malicious usecases (such as an attacker mining an address so that (minedAddres, badChain) has a 4-byte collision with (whateverAddress, intendedChain)) the checksum should be a good mitigation.

Are there upgrade or compatibility risks introduced by the versioning scheme?

I tried to lay them out in the ‘Restrictions for all Interoperable Address versions’ section, basically we define version bit to mean the Interoperable Address is backwards-compatible with v1, and parseable with the same algorithm.

The main risk would be for a future Interoperable Address to define an associated Interoperable Name which can cause collisions with previous versions, e.g. having a v3 name be equivalent to a v2 name while representing a different (address, chain) pair.

In the past we explored including the address’ version in the Interoperable Name, but that felt like a lazy (albeit robust) solution, which unnecessarily leaked implementation details onto users. The way we actually intend to avoid such a scenario is:

  • Review of other ERCs defining further Interoperable Address versions
  • Implementing ERC-7828 in a flexible enough way (by coupling the resolution method to a TLD) that lowers the need to define new versions in the near future.
9

Great! I agree that ux guidance is out of the scope of the ERC itself. Still, it seems important that the security considerations section explicitly acknowledges the following points:

  • The 4-byte checksum provides only probabilistic collision resistance and should not be treated as a strong authenticity guarantee.
  • Collision risks are accepted within the intended (non-adversarial) use context but could become exploitable if implementers assume stronger guarantees.
  • The burden of meaningfully presenting checksums (example: avoiding glyph or display-based confusion) shifts to wallet and dApp implementers.

On the versioning side, the design to keep interoperable names abstracted away from the version bit makes sense, but it would be worth clarifying that cross-version equivalence assumptions should only be made when formally defined. Implementers should not assume, for example, that a v3 name and a v2 name are interchangeable without explicit guarantees