ERC-7785: Onchain registration of chain identifiers

[ndeto]

We’ve been working on a POC for the ERC-7785 registry at unruggable.com and a few points have come up for broader discussion.

1. Interop Between Standards

The registry is meant to support two interop standards: ERC-7930 and ERC-7828.

• ERC-7828: human-friendly names resolve to the 7785 identifier.
• ERC-7930: binary format.

Suggestion: Incorporate the CAIP-2 attributes already present in a 7930 address into the derivation of a 7785 identifier.

ERC-7930 address format:

┌─────────┬───────────┬──────────────────────┬────────────────┬───────────────┬─────────┐
│ Version │ ChainType │ ChainReferenceLength │ ChainReference │ AddressLength │ Address │
└─────────┴───────────┴──────────────────────┴────────────────┴───────────────┴─────────┘

• A 7930 address already includes the CAIP-2 namespace as chainType and chainReference (with the EVM chain Id encoded in chainReference). The proposal is that these can be carried into the derivation of the 7785 chain identifier.

• Benefits:

  1. A binary address can be mapped directly to the registry via its CAIP-2 attributes.
  2. The approach extends naturally to non-EVM chains, since CAIP-2 is not EVM-specific.

2. ENS-Specific Logic

On the ENS side, we will be proposing an ENSIP for resolving chain-id text records. This allows human-friendly names like base.l2.eth to resolve deterministically to a 7785 chain identifier.

• Draft ENSIP: https://github.com/nxt3d/ensips/blob/ensip-ideas/ensips/ensip-TBD-18.md

3. POC Update

• We have built a POC registry that resolves human-friendly chain names (base.l2.eth) to 7785 chain identifiers.
• This POC already incorporates CAIP-2 attributes into the derivation.
• The chain-id text-record ENSIP is also implemented.

POC Repo: https://github.com/unruggable-labs/erc-7785-registry

Future Use cases:

@adraffy

I can see the following options assuming 160 bits:

1. <96 zeros><upper [32, 160) bits of chain id>1<lower [0, 31) bits of chain id>
   (eg. keccak256(...)[:20] | EVM_BIT w/bit 31 ignored)
2. <64 zeros><160 bits of chain id>1<31 zeros>
   (keep EVM_BIT logic, shift right by 32 to extract chain id)
3. <95 zeros>1<160 bits of chain id>
   (new WIDE_EVM_BIT = 1 << 160)

In all cases, the upper 64-96 bits are available for future use.

Regarding this point about using a 160-bit truncated hash, an equally important question is: Which derivation attributes should be used to standardize the interplay between 7828, 7930, and ENS. On our side (Unruggable), we’ll also be pursuing the ENSIP since that is directly within the ENS domain.