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?