Interoperable address spec #14
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Joxess
reviewed
Feb 13, 2025
specs/address-types.md
Outdated
| An extensible way to describe an address specific to one chain which includes the information to condense it into a human-readable name in a secure way. | ||
|
|
||
| ## Out of scope concerns | ||
| Similarly to CAIP-10, this specification is not concerned with the mapping from a chain id to a network name, which might not be surjective (eg: the case where if there are multiple EIP-155 chains with chain id 8453, which one should we call Base?), regarding that resolution a social-layer problem until a future ERC decides to tackle it. |
There was a problem hiding this comment.
We could reference docs/chain-registries.md here
0xteddybear
commented
Feb 19, 2025
|
|
||
| This document, in its current state, aims to be the starting point for a future address format called 'Interoperable Address' whose aims & properties are fully described in [a separate document](../PROPERTIES.md) | ||
|
|
||
| Requires: CAIP-10 |
There was a problem hiding this comment.
should I list the standards required for the various resolvers as well? only CAIP-10 is required for the 'core' spec
| ``` | ||
|
|
||
| ## Rationale | ||
| - In order to guarantee future resolvers don't share prefixes with existing resolvers in an ambiguous way, and therefore human-readable names are always mappable to a single machine address, this standard defines the human-readable names to start with the resolver version. (TODO: ideally we should be smarter about this and resolve it in a way that doesnt expose this implementation quirk to users) |
There was a problem hiding this comment.
I do not like this, we should craft them in a way which allows users to not know they are using a particular schema (for which the version:: is almost a prompt) but is secretly unambiguous.
| - The rules for wether to parse URL escaping in a resolver payload are specific to the resolver version | ||
| - The rules for wether to parse URL escaping in a CAIP-10 account address are specific to its CAIP-2 chain namespace | ||
| - To maintain the bijectivity of account ids and therefore interoperable addresses to on-chain addresses: | ||
| - In CAIP-2 namespaces where there is a canonicalization scheme (such as EIP-55 in EIP-155 chains) it SHOULD be used. |
There was a problem hiding this comment.
Ideally I'd like to say MUST, but there would be no way to resolve it on chains with competing capitalization schemes. I sort of get now why many existing schemes (DID-pkh, ENSIP-11) resort to using raw public keys
| - In CAIP-2 namespaces where addresses have an *optional* checksum field, it MUST be omitted and the checksum defined in the standard be used without redundancy | ||
| - In CAIP-2 namespaces where addresses are raw hexadecimal data without an EIP-55-equivalent capitalization scheme, the lowercase `a-f` characters MUST be used instead of uppercase ones. | ||
| - In the case of EIP-155 chains, EIP-55 canonicalization MUST be used | ||
| - The checksum MUST be the hexadecimal representation first four bytes of the keccak-256 hash of UTF-8 representation of the interoperable address from it's beginning up to and including the hash `#` character separating the checksum from the rest of the address. |
There was a problem hiding this comment.
I don't have any good reason for choosing this, just chose something.
|
Raising awareness this is aligned to tackle #22 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I believe this is at a state where we can start a discussion. It is by no means final.
While resolver with id 3 is a good stopgap solution in my opinion, I believe we should iterate on this to:
There are several lower-level items where I would greatly appreciate your ideas and feedback, see my own comments in the diff