Update ERC-7828: Update resolution flow with high level specifications #1481

clowestab · 2026-01-21T13:18:41Z

This PR removes the bloated and inaccurate outline of full end-to-end resolution flow for the on-chain registry-resolver, replacing it with a high level overview of the way that Interoperable Name's are parsed and processed. We point to the appropriate ENS specifications where appropriate.

This PR is to get 7828 to a position of high level of completeness whilst discussions are ongoing relating to checksums and the breadth/focus of the standard.

Additionally fixed a few small grammar/parsing errors.

eip-review-bot · 2026-01-21T13:19:04Z

✅ All reviewers have approved.

0xrcinus

Thanks! I left some comments

0xrcinus · 2026-01-21T13:58:39Z

ERCS/erc-7828.md

 Additionally, the target chain component of an _Interoperable Name_ may be expressed as a human-readable label. This specification defines how such labels can be resolved, via the Ethereum Name Service (ENS), to chain-specific metadata.

-The result is _chain-specific addresses_ such as `wallet.ensdao.eth@eip155:1`, `0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@eip155:1` or the maximally readable `example.eth@base`.
+The result is _chain-specific addresses_ such as `wallet.ensdao.eth@eip155:1`, `0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@eip155:1` or the maximally readable `wallet.ensdao.eth@ethereum`.


Should we update the other examples below (which reference example.eth) to use wallet.ensdao.eth

I have done this. wallet.ensdao.eth DOES resolve to 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7 on Ethereum mainnet (at least for now). The only confusion is with the bitcoin example - wallet.ensdao.eth doesn't actually resolve to anything on the Bitcoin network. I'm unsure if this is unclear/confusing. Thoughts?

0xrcinus · 2026-01-21T14:02:04Z

ERCS/erc-7828.md

-5.  Verify `fullName` ends with `.l2.eth`.
-6.  Strip the suffix and apply UTS #46 lower-case normalisation.
-    • Use the remaining label (e.g. **“arbitrum”** instead of **“arbitrum.l2.eth”**).
+The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.


Maybe it is because I am less familiar with the internals of ENS resolution, but I think it would be good for the example to include the actual function call to get the data record

Fair enough. Added.

0xrcinus · 2026-01-21T14:02:15Z

ERCS/erc-7828.md

+The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.

-To obtain the **chain identifier** corresponding to a human-readable chain name, clients SHALL:
+The resolver for `on.eth` MUST implement ENSIP-5 - Text Records, and allow for the resolution of text records for the `reverse.on.eth` namespace of the form `chain-label:` followed by the [ERC-7930] _Interoperable Address_ you are trying to discern the label for. For example, the _Interoperable Address_ representing Ethereum Mainnet is `0x000100000101`. Resolution of the text record `chain-label:0x000100000101` for the `reverse.on.eth` namespace SHOULD return `ethereum`.


As above, I think a slightly more detailed example would be helpful here

0xrcinus · 2026-01-21T14:03:42Z

ERCS/erc-7828.md

-5.  Verify `fullName` ends with `.l2.eth`.
-6.  Strip the suffix and apply UTS #46 lower-case normalisation.
-    • Use the remaining label (e.g. **“arbitrum”** instead of **“arbitrum.l2.eth”**).
+The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.


Suggested change

The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.

The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ for the chain using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.

0xrcinus · 2026-01-21T14:04:52Z

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.
+Additional implementation details about the registry-resolver contract implementation can be discerned by referencing the ENS documentation, and viewing the verified source code of the contract set as the resolver for `on.eth`.


I think it is worth mentioning aliasing, i.e. that multiple labels may resolve to the same Interoperable Address (but an Interoperable Address will only resolve to one label)

Good point. I've added a sentence to each of the forward resolution and reverse resolution sections to mention this.

0xrcinus · 2026-01-21T14:05:18Z

ERCS/erc-7828.md

+If an ENS address is used within the `<address>` component, it MUST be resolved subject to the ENS resolution specifications, giving consideration to the target chain specified in the `<chain>` component.

-### Resolving address names
+The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specification outline how one resolves an ENS name to discern the address **for a specific chain**.Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.


Suggested change

The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specification outline how one resolves an ENS name to discern the address **for a specific chain**.Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.

The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specification outline how one resolves an ENS name to discern the address **for a specific chain**. Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.

0xrcinus · 2026-01-21T14:06:17Z

ERCS/erc-7828.md

+### Resolving the `<address>` component

-While currently only `eip155` chains are supported, the on-chain registry could start listing other chains in order to make human-readable names for non-evm chains possible.
+If an ENS address is used within the `<address>` component, it MUST be resolved subject to the ENS resolution specifications, giving consideration to the target chain specified in the `<chain>` component.


Is it worth being specific about how to identify whether it's an ENS address (i.e. is it assuming that anything with a . is?)

Yes. Added.

0xrcinus · 2026-01-21T14:09:56Z

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.
+Additional implementation details about the registry-resolver contract implementation can be discerned by referencing the ENS documentation, and viewing the verified source code of the contract set as the resolver for `on.eth`.


We also don't mention anything about the "chains taking ownership of their metadata" thing which is in the rationale.. I agree that this isn't necessary for the naming standard, but I think if it isn't covered we shouldn't mention it in the motivation - but it may be worth mentioning at least the expected mechanic?

I've added a section 'The Canonical Resolver` that addresses this.

0xMonoAx

I left a few comments, but I also wanted to share some broader feedback.

I appreciate the goal of keeping the ERC as simple as possible. That said, I think the Specification section could benefit from a bit more technical detail, and from avoiding governance or operational aspects, since those may evolve over time or sit outside the scope of the spec itself. I also think it’s important to keep the usage of Interoperable Addresses consistent and aligned with what’s defined in ERC-7930. Regarding, on Security Considerations: the current text mentions that ENSIP-1 and ENSIP-15 help to “avoid homoglyph or spoofing attacks.” However, ENSIP-15’s own security considerations note that normalization alone is not a complete solution, so it may be worth reflecting that nuance more clearly in the text.

0xMonoAx · 2026-01-22T00:12:17Z

ERCS/erc-7828.md

@@ -17,17 +17,17 @@ This proposal defines an _Interoperable Name_, a human-readable _chain-specific

 Additionally, the target chain component of an _Interoperable Name_ may be expressed as a human-readable label. This specification defines how such labels can be resolved, via the Ethereum Name Service (ENS), to chain-specific metadata.


I think the abstract does not clearly convey what a developer will encounter. I believe it would be more beneficial for the ERC to be more direct, so I propose the following new abstract:

This proposal defines an Interoperable Name, a human-readable, chain-specific address format of the form <address>@<chain>#<checksum>, where both the <address> and <chain> components MAY be expressed as human-readable names and resolved via ENS.
An on-chain registry enables decentralized resolution of chain labels to their canonical identifiers, while address resolution leverages the existing ENS infrastructure.
The result is chain-specific addresses such as:
• 0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7@eip155:1#80B12379
• alice.eth@eip155:1#80B12379
• or the most human-readable version, alice.eth@base#80B12379

The checksum is optional, and this is explained in the Checksum section

As suggested by @0xrcinus externally, this should probably be a separate PR if you want to come back to these sections.

0xMonoAx · 2026-01-22T00:42:53Z

ERCS/erc-7828.md


 ## Motivation

 The core motivation for introducing the _Interoperable Name_ standard is to provide maximally readable, _chain-specific addresses_ for user-facing interactions.


I think this section is missing important context about the underlying problem: addresses alone are no longer sufficient when the same format is reused across hundreds of L2s. Adding the following paragraph would make the section more complete:

The current Ethereum address landscape is leading to an ecosystem that will have hundreds and eventually thousands of L2s that use the same address format as Ethereum mainnet. This means an address by itself is not enough information to know which chain the address is related to. This can be problematic if funds are sent to an unreachable address on the incorrect chain. From the user account it should be possible to obtain the right chain identifier (chainID) to include in a transaction.

As suggested by @0xrcinus externally, this should probably be a separate PR if you want to come back to these sections.

0xMonoAx · 2026-01-22T01:03:56Z

ERCS/erc-7828.md

+wallet.ensdao.eth@bitcoin#597D21A1
+```
+
+### The Canonical Resolver


This paragraph mentions some governance/operational details (like the "5/7 multisig", "reputable industry participants", future transfers, etc.) that might not fit well in the Specification section since they could change over time. Per EIP-1, specs should focus on technical details that allow interoperable implementations. Maybe these details would work better in Rationale or Security Considerations?

Fair. Fixed. Will add longer general comment.

0xMonoAx · 2026-01-22T02:07:27Z

ERCS/erc-7828.md

+
+If the `<chain>` component of an _Interoperable Address_ does not contain a colon (`:`) it is interpreted as being label under the `on.eth` ENS namespace.
+
+The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ for the specified chain label using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.


I feel that we are misusing not only the term but also the implementation of the Interoperable Address.

ERC-7930 defines it as follows:

Interoperable Address : A binary payload which unambiguously identifies a target address on a target chain. e.g. 0x00010000010114d8da6bf26964af9d7eed9e03e53415d37aa96045

I think we should explain in more detail how to extract the component, not just in this section but also in the next one

I think this is one slightly unintuitive thing about Interoperable Addresses, in that they can refer to just a chain (as they do in this case) - that definition in 7930 is maybe misleading

Interestingly, I got the 'chain only' Interoperable Addresses wrong, and we all missed it :| Oops. Fixed. But yes, these take advantage of the flexibility of 7930 to represent a chain only.

0xMonoAx · 2026-01-22T02:11:48Z

ERCS/erc-7828.md

+If an ENS address is used within the `<address>` component, it MUST be resolved subject to the ENS resolution specifications, giving consideration to the target chain specified in the `<chain>` component.

-Forward resolution (Interoperable Address -> Interoperable Name): Supported via the multichain address resolution standard defined in [ERC-2304], which uses [BIP 44] registered coin type identifiers to resolve names for various chains, including the `eip155` namespace.
+The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specification outline how one resolves an ENS name to discern the address **for a specific chain**. Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.


Consideration MUST be given to both current and future ENSIPs pertaining to address resolution

This should be in the Security Considerations section

I put it here because whilst it is a security consideration it is also necessarily part of the spec because if ENS changes how resolution works, and thats not noted here the logical conclusion would be that this spec is essentially hard-coding old resolution standards..

0xMonoAx · 2026-01-22T02:27:02Z

ERCS/erc-7828.md

-    - Sidechains may rely on centralized CCIP-read gateways or signature authorities.
-
-    Wallets MUST surface whether reverse resolution was trust-minimized or trusted.
+- Implementers MUST give consideration to the name normalization specifications of the Ethereum Name Service so as to avoid homoglyph or spoofing attacks. These are outlined in ENSIP-1 and ENSIP-15.


I think we should be clearer here: while ENSIP-15 provides normalization against the most common homoglyph attacks, it's not a complete solution. Applications displaying ENS names should implement additional protection layers (e.g., checksum verification).

Thats referenced explicitly in the Checksum section which maintaining the previous state of affairs requires checksum verification if provided, and requires them when sharing. I don't agree that this is the right approach but to get to a base from where to have these conversations we were just keeping things as is for now.

0xMonoAx · 2026-01-22T02:28:36Z

ERCS/erc-7828.md

-
-    Wallets MUST surface whether reverse resolution was trust-minimized or trusted.
+- Implementers MUST give consideration to the name normalization specifications of the Ethereum Name Service so as to avoid homoglyph or spoofing attacks. These are outlined in ENSIP-1 and ENSIP-15.
+- Users should stay vigilant of address poisoning attacks when using a raw _target address_ in the `<address>` component.


I would also clarify that they can use the checksum

clowestab · 2026-01-26T17:01:10Z

So, I reflected on this over the weekend having spoken to Josh and Barnabe.

I agree, governance should not be included in this spec. I have removed it.

Noting that the on-chain registry-resolver is an incredible powerful standalone product I have opted to build out documentation for it on the ENS documentation site. Governance stuff can be housed there, and that is an appropriate living location if we ever choose to upgrade the implementation down the line. A pull request can be found here: ensdomains/docs#508

0xrcinus

Thanks, these changes give an up-to-date foundation with regard to the reference implementation, open questions can be addressed in subsequent PRs

eip-review-bot

All Reviewers Have Approved; Performing Automatic Merge...

docs: update resolution flow with high level specifications

c2a0b38

github-actions bot added c-update s-draft t-erc labels Jan 21, 2026

0xrcinus suggested changes Jan 21, 2026

View reviewed changes

docs: updates based on feedback

2068fc5

0xMonoAx suggested changes Jan 22, 2026

View reviewed changes

docs: changes based on feedback

a89827e

0xrcinus approved these changes Jan 27, 2026

View reviewed changes

Merge branch 'master' into 7828-ens-resolution

01c47c3

clowestab marked this pull request as ready for review January 28, 2026 12:17

clowestab requested a review from eip-review-bot as a code owner January 28, 2026 12:17

eip-review-bot enabled auto-merge (squash) January 28, 2026 12:18

eip-review-bot approved these changes Jan 28, 2026

View reviewed changes

eip-review-bot merged commit a368178 into ethereum:master Jan 28, 2026
10 of 16 checks passed

clowestab deleted the 7828-ens-resolution branch January 28, 2026 13:33

	The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.
	The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ for the chain using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.

	The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specification outline how one resolves an ENS name to discern the address for a specific chain.Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.
	The specifications of note are ENSIP-9: Multichain address resolution, ENSIP-10: Wildcard resolution, and ENSIP-11: EVM compatible Chain Address Resolution. These specification outline how one resolves an ENS name to discern the address for a specific chain. Consideration MUST be given to both current and future ENSIPs pertaining to address resolution.

		@@ -17,17 +17,17 @@ This proposal defines an _Interoperable Name_, a human-readable _chain-specific

		Additionally, the target chain component of an _Interoperable Name_ may be expressed as a human-readable label. This specification defines how such labels can be resolved, via the Ethereum Name Service (ENS), to chain-specific metadata.


		## Motivation

		The core motivation for introducing the _Interoperable Name_ standard is to provide maximally readable, _chain-specific addresses_ for user-facing interactions.


		If the `<chain>` component of an _Interoperable Address_ does not contain a colon (`:`) it is interpreted as being label under the `on.eth` ENS namespace.

		The resolver for `on.eth` MUST implement ENSIP-24 - Arbitrary Data Resolution, and allow for the resolution of the [ERC-7930] _Interoperable Address_ for the specified chain label using the key, `interoperable-address`. For example if you resolve the `interoperable-address` data record for `ethereum.on.eth` the _Interoperable Address_ `0x000100000101` SHOULD be returned.

Update ERC-7828: Update resolution flow with high level specifications #1481

Update ERC-7828: Update resolution flow with high level specifications #1481

Uh oh!

Conversation

clowestab commented Jan 21, 2026

Uh oh!

eip-review-bot commented Jan 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xrcinus 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

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

Uh oh!

Choose a reason for hiding this comment

Uh oh!

clowestab commented Jan 26, 2026

Uh oh!

0xrcinus left a comment

Choose a reason for hiding this comment

Uh oh!

eip-review-bot commented Jan 21, 2026 •

edited

Loading