Feat: add chain-specific addresses properties #11

Joxess · 2025-02-11T18:24:23Z

This is the first PR that serves as a conversation starter to discuss properties for chain-specific addresses.

Address #19 too

0xteddybear · 2025-02-11T19:06:51Z

PROPERTIES.md

+3. **User Interface**
+- Clear chain identification
+- Separation of concerns between human readability and machine addresses
+- Error prevention


we could separate this into machine errors (eg: a wallet mis-resolving a name and sending funds to the wrong address/chain), which would not fit into this category, and 'user error' (eg: unicode homoglyph attacks, users not manually validating wallet output because it's too long) which would fit into this category

Added! let me know wdyt

PROPERTIES.md

0xteddybear · 2025-02-11T19:37:28Z

docs/addresses-current-efforts.md

+
+The existing approaches to chain-specific addresses represent an evolution in thinking about cross-chain identification rather than competing solutions. Some standards builds upon lessons learned from previous implementations while other targets other aspects or they could built on top of.
+
+| **Feature** | ERC-3770 | CAIP-10 | ERC-7828 |


should we add a column for ENSIP-11?

0xteddybear · 2025-02-11T19:43:53Z

docs/addresses-current-efforts.md

+| **Human Readability** | Medium | Medium | High |
+| **Technical Compatibility** | EVM only (but extensible) | All chains | EVM focus with non-EVM support |
+| **Implementation Flexibility** | Limited | High | High |
+| **ENS Support** | “No” | “No” | Yes |


should this mean it supports ENS, or it requires ENS? does it make sense to make it two separate rows (coupled to ENS and augmented by ENS)?

I modified that field as "required | optional"

0xteddybear · 2025-02-11T20:21:26Z

docs/addresses-current-efforts.md

+| --- | --- | --- | --- |
+| **Format Example** | `chain:address` | `chain_id:chain_reference:address` | `address:chain.eth` or `[email protected]` |
+| **Human Readability** | Medium | Medium | High |
+| **Technical Compatibility** | EVM only (but extensible) | All chains | EVM focus with non-EVM support |


ERC-7828 as-is does not support non-evm chains, as it does not use CAIP-10 or antyhing similar to represent non-evm chains, and the 'address' field is coupled to evm address' length and valid characters

There is an intention to support non-EVM chains. Since the ERC isn't finalized yet, I think it's better to state their intention to do so rather than claim it as a current feature, will do

0xteddybear · 2025-02-11T20:22:59Z

docs/addresses-current-efforts.md

+| **Feature** | ERC-3770 | CAIP-10 | ERC-7828 |
+| --- | --- | --- | --- |
+| **Format Example** | `chain:address` | `chain_id:chain_reference:address` | `address:chain.eth` or `[email protected]` |
+| **Human Readability** | Medium | Medium | High |


ERC-7828 readability can go from 'high' if human-readable names are used in all fields, to lower than both ERC-3770 and CAIP-10 as it is a longer string with more complex syntax and more info

docs/addresses-current-efforts.md

0xteddybear · 2025-02-11T20:25:38Z

docs/addresses-current-efforts.md

+| **Implementation Flexibility** | Limited | High | High |
+| **ENS Support** | “No” | “No” | Yes |
+| **DID Compatibility** | No | Yes | Optional |
+| **Checksum Support** | Yes | No | Yes |


ERC-3770 does not include any checksum-ing other than ERC-55. Specifically, you could mistype anything in the chain name and have the checksum still be valid. I propose we set it to 'incomplete'

This is great, added

0xteddybear · 2025-02-11T20:44:06Z

docs/addresses-current-efforts.md

+| **ENS Support** | “No” | “No” | Yes |
+| **DID Compatibility** | No | Yes | Optional |
+| **Checksum Support** | Yes | No | Yes |
+| **Relies on centralized lists** | Yes (referencing github.com/ethereum-lists/chains) | No | Yes (requires ERC-7785 aka onchain registry) |


which part of the ERC-7828 would you consider centralized? the EF-to-rollup.eth subdomain handover?

Improved to be more generic on if/what type of list they would relies on

"Support for both user-facing and programmatic formats"

Correct EVM support in ERC-7828

Clarify readability feature

clarify ERC-3770 status

0xteddybear

looking good 😎

other than the minor corrections, I believe there are only two outstanding discussions:

should we define within this document the fact that addresses will have a machine-readable representation and a human-readable one? I find it somewhat constraining, but deciding it at this point also allows us to have more well-defined properties
wether we dive deep into w3c DID as part of this PR or we leave it for later.

PROPERTIES.md

0xteddybear · 2025-02-12T19:15:52Z

docs/addresses-current-efforts.md

+| **Format Example** | `chain:address` | `chain_namespace:chain_reference:address` | `address:chain.eth` or `[email protected]` |
+| **Human Readability (_best-case scenario_)** | Medium | Medium | High |
+| **Technical Compatibility** | EVM only (but extensible) | All chains | EVM only (potential non-EVM support) |
+| **ENS Integration** | Optional | Optional | Required |
 | **DID Compatibility** | No | Yes | Optional |


I don't understand how are the different standards compatible/not compatible with DID, could you elaborate? I suggest we otherwise delete/blank this line and leave it for a later PR on which we would also research the possibility of addresses complying with URL syntax

I agree with going more deeper into DID afterwards

docs/addresses-current-efforts.md

vandan · 2025-02-20T05:38:36Z

Can we separate the problem into "cross-chain naming" and "cross-chain addressing" as suggested? That might allow us to make progress on the simpler foundational addressing aspect which doesn't need to go beyond machine readability as a Must-have.

Joxess added 3 commits February 11, 2025 14:40

add comparison table

3bdec01

add chain-specific addresses properties

d32919b

add comparison as reference

699a1c2

Joxess changed the title ~~Feat: add chain-specific properties~~ Feat: add chain-specific addresses properties Feb 11, 2025

Joxess added task A Project task and removed task A Project task labels Feb 11, 2025

Joxess linked an issue Feb 11, 2025 that may be closed by this pull request

[Task] Define properties #5

Open

4 tasks

0xteddybear reviewed Feb 11, 2025

View reviewed changes

Joxess added 4 commits February 11, 2025 19:01

separate user and machine errors

65f4860

remove a should-have property

e662198

"Support for both user-facing and programmatic formats"

move security properties into must-have

4e8079a

correct caip-10 format

3e4cfe2

skeletor-spaceman requested a review from 0xteddybear February 12, 2025 14:10

Joxess added 7 commits February 12, 2025 11:28

update comparison table

ca34fdc

update table

26235c6

Correct EVM support in ERC-7828

update table

d3ae35d

Clarify readability feature

remove flexibility field

0bb82cc

improve checksum field

e3406e0

clarify ERC-3770 status

improve chain list field

6ad93b5

add status field

730f486

0xteddybear reviewed Feb 12, 2025

View reviewed changes

Joxess added 3 commits February 12, 2025 18:40

improve properties

ff66a6e

update comparison table

abfc251

add ensip-9 and ensip-11

4d2b81d

0xteddybear previously approved these changes Feb 13, 2025

View reviewed changes

add address layers

bf56f4b

Joxess dismissed 0xteddybear’s stale review via bf56f4b February 13, 2025 17:59

add ensip-9 and ensip-11 comparison

5fe1d2f

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat: add chain-specific addresses properties #11

Feat: add chain-specific addresses properties #11

Joxess commented Feb 11, 2025 •

edited

Loading

0xteddybear Feb 11, 2025

Joxess Feb 11, 2025

0xteddybear Feb 11, 2025

0xteddybear Feb 11, 2025

Joxess Feb 12, 2025

0xteddybear Feb 11, 2025

Joxess Feb 12, 2025

0xteddybear Feb 11, 2025

Joxess Feb 12, 2025

0xteddybear Feb 11, 2025

Joxess Feb 12, 2025

0xteddybear Feb 11, 2025

Joxess Feb 12, 2025

0xteddybear left a comment •

edited

Loading

0xteddybear Feb 12, 2025

Joxess Feb 12, 2025

vandan commented Feb 20, 2025


		The existing approaches to chain-specific addresses represent an evolution in thinking about cross-chain identification rather than competing solutions. Some standards builds upon lessons learned from previous implementations while other targets other aspects or they could built on top of.

		\| Feature \| ERC-3770 \| CAIP-10 \| ERC-7828 \|

Feat: add chain-specific addresses properties #11

Are you sure you want to change the base?

Feat: add chain-specific addresses properties #11

Conversation

Joxess commented Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xteddybear left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vandan commented Feb 20, 2025

Joxess commented Feb 11, 2025 •

edited

Loading

0xteddybear left a comment •

edited

Loading