Update ERC-7828: Updates to ERC-7828 to make it more clear and accessible. #1267

clowestab · 2025-10-16T17:06:30Z

Updates to ERC-7828 to make it more clear and accessible based on community feedback and discussions within the Interop working group.

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

The PR edits only existing draft PRs.
The build passes.
Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
If matching on email address, the email address is the one publicly listed on your GitHub profile.

…munity feedback and discussions within the Interop working group.

eip-review-bot · 2025-10-16T17:06:56Z

File `ERCS/erc-7828.md`

Requires 1 more reviewers from @0xArdy, @0xGorilla, @0xmoebius, @0xracoon, @0xskeletor-spaceman, @0xteddybear, @0xtiti, @jefflau, @Joxess, @Onizuka-wl, @oxlumi, @paracetamolo, @sampkaML, @SamWilsn, @vbuterin, @yuliyaalexiev

…7828 Interoperable Name

github-actions · 2025-10-17T15:31:09Z

The commit bd717b6 (as a parent of 5ed4050) contains errors.
Please inspect the Run Summary for details.

ndeto · 2025-10-19T21:56:55Z

ERCS/erc-7828.md

+
+#### Step 4: Resolve alice.eth **for** the specified chain
+5. Extract the CAIP-2 `ChainReference` from the [ERC-7930] identifier returned in the previous step.
+6. Convert the `ChainReference` into an ENS `coinType` (see ENSIP-11).


For non-EVM chains, ENSIP-11 does not apply.

We could define how both EVM and non-EVM chains can expose their coin type/SLIP-44 constant through the chain registry for consistency.

Quick idea would be specifying a coin-type text key that returns the value?

This would be equivalent to slip-44 in https://chainid.network/chains.json? It doesn't seem to be there for all chains in that list, so there would need to be some kind of fallback?

ENSIP-11 can derive the coin type for EVM chains using their chain ID. For non-EVM chains, we use the SLIP-44 constant

The idea is to abstract that complexity away and surface the appropriate value for each chain using a coin-type text record. i.e resolving the text record coin-type for optimism.<namespace>.eth returns the ENSIP-11 coin type / SLIP-44 value

The original spec had the following: "For addresses on chains that are both supported by BIP-44 registered coin type identifiers and the special scheme for the eip155 namespace defined in ENSIP-11, the latter should be used.".

I will readd this for clarity, and add additional commentary to outline what @ndeto has mentioned, namely:

"The idea is to abstract that complexity away and surface the appropriate value for each chain using a coin-type text record. i.e resolving the text record coin-type for optimism..eth returns the ENSIP-11 coin type / SLIP-44 value"

0xteddybear

let's keep the formal grammar definition (although I'm open to modify it), rely on the things already defined in ERC-7930, and clear out the confusion on using CAIP-2 directly
After that we can focus on what should be defined in this ERC vs the relevant ENSIP

0xteddybear · 2025-10-22T19:53:41Z

ERCS/erc-7828.md

-This proposal extends [ERC-7930](./eip-7930.md) (Interoperable Addresses & Names) by standardizing a human-readable format for chain-specific addresses in the form `<address>@<chain>#<checksum>`. It introduces:
+This proposal extends the definition of an _Interoperable Name_ outlined in [ERC-7930](./eip-7930.md). 
+
+The `<chain>` component definition is extended to allow for a human-readable chain name to be used. This identifier is resolved to an [ERC-7930] _Interoperable Address_ using the Ethereum Name Service (ENS). This moves chain metadata discovery on-chain.


let's keep at least a mention of 7930's <address>@<chain>#<checksum> format

OK. Re-added.

0xteddybear · 2025-10-22T20:00:23Z

ERCS/erc-7828.md

-Moreover, the above can be leveraged to allow for a name to represent the same entity corresponding to different addresses on different chains, mitigating the risk of sending funds to an address the intended recipient doesn't actually control.
+The flexibility of this specification and the underlying naming systems can be leveraged to allow for different addresses on different chains to be represented by the same human-readable string. This mitigates the risk of sending funds to an address the intended recipient doesn't actually control.
+
+The usage of human-readable names provides additional clarity and confidence to users.


this is vague and redundant

Fair. Removed.

0xteddybear · 2025-10-22T20:05:23Z

ERCS/erc-7828.md

+These components now have the following extended definitions:
+
+```bnf
+<address>     := <raw-address> | <name-service-domain>


this is significantly more vague and relies on prose instead of standard BNF notation

Are you requesting the definitions of <raw-address> and <name-service-domain> be in the bnf block too?

0xteddybear · 2025-10-22T20:06:09Z

ERCS/erc-7828.md

-<ens-name>:            := (<label> .)+ <label>
+Recall that [ERC-7930] defines an _Interoperable Name_ as a human readable representation of an underlying _Interoperable Address_.
+
+It's format is `<address> @ <chain> # <checksum>`


I believe it should be 'its'
also, having this in the prose is good but let's please also keep it in the formal definition as well

Correct. Fixed.

0xteddybear · 2025-10-22T20:18:54Z

ERCS/erc-7828.md

+`<name-service-domain>` is a domain name from a known, and supported naming service. For example an Ethereum Name Service (ENS) name like `example.eth`. These names should be resolved to a `<raw-address>` subject to the resolution specifications of the name service in question.

-A few examples below:
+`<caip-2-chain-id>` is the string representation of the [CAIP-2] blockchain identifier. For example, `eip155:1` or `bip122:000000000019d6689c085ae165831e93`. An ERC-7828 _Interoperable Name_ MUST specify both the namespace and reference elements of the CAIP-2 identifier as ENS resolves addresses on a chain specific basis.


this is contradictory with 7930, why are you defining it like this?

I think this only applies in the case where the address is an ENS name (i.e. vitalik.eth@eip155 is underspecified because vitalik.eth could resolve to different addresses on different chains). 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045@eip155 is valid but that isn't a 7828 name (it's readable 7930)

Yes, as outlined by @0xrcinus , this was discussed with @skeletor-spaceman - the problem is that ENS name resolution is chain specific NOT namespace specific. I wouldn't say this contradicts, but rather modifies the syntactic restrictions outlined in ERC-7930

0xMonoAx

Add some comments and corrections to make the ERC clearer.

0xMonoAx · 2025-10-29T02:39:41Z

ERCS/erc-7828.md

+```

-Wallets MAY display the checksum when formatting addresses, and MAY accept inputs without a checksum by computing it internally.
+The checksum is optional and is calculated as outlined in [ERC-7930].


To maintain consistency with ERC-7930, I would keep the previous sentence: "Clients MAY accept Interoperable Name inputs without a checksum."

0xMonoAx · 2025-10-29T02:43:29Z

ERCS/erc-7828.md

+This specification proposes that the `<chain>` component of the _Interoperable Name_ definition outlined in [ERC-7930] be extended to allow for a human-readable chain name resolved on-chain via ENS. This registry would provide a single source of truth for mapping a chain name to an [ERC-7930] _Interoperable Address_ and associated chain metadata.

-In the same spirit, the address could be a human-readable name as well, which is already a use case for ENS. By coupling the TLD to the resolving method used, this standard could leverage current and future features of ENS as well as other naming registries.
+In the same spirit, we propose that the `<address>` component of the definition allow for a human-readable name to be utilized. By coupling the TLD to the resolution method used, this standard could leverage current and future features of ENS as well as other naming systems.


In the same spirit, we propose...

Change to:

“This specification proposes…”

(EIPs prefer an impersonal tone)

0xMonoAx · 2025-10-29T02:47:01Z

ERCS/erc-7828.md


-> [!NOTE]
-> This standard explicitly defines the use of an agreed <namespace>.eth second-level domain for chain names. Beyond this, hierarchical name structures continue to be inherited from ENS, as exemplified in the ENS-in-rollup example.
+When checksum validation fails clients MUST alert the user and require explicit user input to continue with the operation.


..and require explicit user input to continue with the operation.

This is not specified in ERC-7930. Should we add it?

A similar statement is included in 7930. I've added to it for completeness: "If a user-provided Interoperable Name includes a checksum, clients MUST derive the underlying Interoperable Address, recalculate the checksum, and compare it to the provided value. In case of a mismatch, clients MUST warn the user and require explicit user input to continue with the operation."

0xMonoAx · 2025-10-29T02:51:46Z

ERCS/erc-7828.md


-> [!NOTE]
-> This standard explicitly defines the use of an agreed <namespace>.eth second-level domain for chain names. Beyond this, hierarchical name structures continue to be inherited from ENS, as exemplified in the ENS-in-rollup example.
+When checksum validation fails clients MUST alert the user and require explicit user input to continue with the operation.


Since ERC- 7930 delegates parsing to CAIP-350, it would be ideal to repeat a line here that reinforces that requirement.

Similar: #1265 (comment)

I've added a block about this in the context of 7828.

0xMonoAx · 2025-10-29T02:55:59Z

ERCS/erc-7828.md

-5.  Query the Universal Resolver: `result = UniversalResolver.resolve(dnsEncode(full), callData)`.
-6.  ABI-decode `result` as `(bytes chainBytes)`.
-    • If `chainBytes` is empty → no mapping exists; treat the label as unknown.
+If the `<chain>` is `ethereum`, you would resolve the `chain-id` data record for `ethereum.<namespace>.eth` subject to ENSIP-24: Arbitrary Data Resolution.


If the <chain> is ethereum, you would..

“You” is not used in standards. I propose:

If the <chain> component is ethereum, implementations MUST resolve the chain-id data record for ethereum.<namespace>.eth according to [ENSIP-24: Arbitrary Data Resolution].

Updated. I havn't linked to ENSIP-24 as ENSIPs are not in the allowed external links..

0xMonoAx · 2025-10-29T03:05:32Z

ERCS/erc-7828.md

+### Reverse resolution

-### Resolving address names
+In the context of this specification 'Reverse Resolution' refers to the process of discerning the `<chain-label>` of a chain from its _Interoperable Address_.


'Reverse Resolution'

change to:

Reverse Resolution

0xMonoAx · 2025-10-29T03:12:33Z

ERCS/erc-7828.md

+3. The underlying label for 'Optimism' is 'optimism'. Append `<namespace.eth>` to that label => `optimism.<namespace>.eth`
+
+#### Step 3: Resolve the [ERC-7930] _Interoperable Address_
+4. Discern the resolver for `optimism.<namespace>.eth` and resolve `data(bytes32 namehash, string key)` (ENSIP-24: Arbitrary Data Resolution) passing in the `namehash` (see ENSIP-1) of `optimism.<namespace>.eth` and the key, `chain-id`. 


“Dicern” is ambiguous; I recommend using “Determine.”

0xMonoAx · 2025-10-29T03:16:20Z

ERCS/erc-7828.md

+Consideration should be given to ENSIP-15: Name Normalization so as to avoid homograph attacks. 

-    Wallets MUST surface whether reverse resolution was trust-minimized or trusted.
+Wherever possible clients should utilize the optional checksum outlined in [ERC-7930]. It should be verified when a raw _Interoperable Name_ is pasted, and it should be appended when an _Interoperable Name_ is being generated based on user input.


Should you define what happens when the resolver returns invalid data?

Which aspect are you referring to here? Are you suggesting documenting that if (for example) a non existent chain name is resolved 0x will be returned?

Updates to ERC-7828 to make it more clear and accessible based on com…

be9adb9

…munity feedback and discussions within the Interop working group.

clowestab requested a review from eip-review-bot as a code owner October 16, 2025 17:06

github-actions bot added c-update t-erc labels Oct 16, 2025

eip-review-bot added the a-review label Oct 16, 2025

eip-review-bot changed the title ~~Updates to ERC-7828 to make it more clear and accessible.~~ Update ERC-7828: Updates to ERC-7828 to make it more clear and accessible. Oct 16, 2025

github-actions bot added the w-ci label Oct 16, 2025

clowestab added 2 commits October 17, 2025 16:17

Clarify requirement for CAIP-2 reference within <chain> component of …

9a9dcae

…7828 Interoperable Name

Update references to Arbitrary Data Resolution ENSIP

bd717b6

github-actions bot removed the w-ci label Oct 17, 2025

github-actions bot added the w-ci label Oct 17, 2025

ndeto reviewed Oct 20, 2025

View reviewed changes

clowestab mentioned this pull request Oct 20, 2025

ENSIP-24: Arbitrary Data Storage ensdomains/ensips#53

Open

0xteddybear suggested changes Oct 22, 2025

View reviewed changes

Updates based on review

e8317a1

github-actions bot added c-status and removed c-update labels Oct 25, 2025

Updates based on review

301c355

0xMonoAx reviewed Oct 29, 2025

View reviewed changes

clowestab added 2 commits October 30, 2025 10:30

Changes based on review

c0b0f11

Updates based on review.

31041f9

Update ERC-7828: Updates to ERC-7828 to make it more clear and accessible. #1267

Are you sure you want to change the base?

Update ERC-7828: Updates to ERC-7828 to make it more clear and accessible. #1267

Uh oh!

Conversation

clowestab commented Oct 16, 2025

Uh oh!

eip-review-bot commented Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

File ERCS/erc-7828.md

Uh oh!

github-actions bot commented Oct 17, 2025

Uh oh!

ndeto Oct 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ndeto Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xteddybear left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xMonoAx left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

eip-review-bot commented Oct 16, 2025 •

edited

Loading

File `ERCS/erc-7828.md`

ndeto Oct 19, 2025 •

edited

Loading

ndeto Oct 23, 2025 •

edited

Loading