[DRAFT] Introduce Chain Id 0 (EOA Chain Id) by lucemans · Pull Request #7 · ensdomains/ensips

lucemans · 2024-09-23T09:48:49Z

TLDR; https://namespaces.chainagnostic.org/eip155/caip10#caip-10 assumes evm chain id 0 is "EOA" chain id.

We would like to extend this functionality into ENS leveraging the already existing ENSIP-9.

Still looking for feedback on:

naming choice: EOA vs ChainID-0 vs Fallback Address
client-side vs public resolver implementation

cloudflare-workers-and-pages · 2024-09-23T10:09:41Z

Deploying ensips with Cloudflare Pages

Latest commit:	`c325c9f`
Status:	✅ Deploy successful!
Preview URL:	https://f36242eb.ensips.pages.dev
Branch Preview URL:	https://ensip-chain-id-0.ensips.pages.dev

View logs

GriffGreen · 2024-10-24T03:37:39Z

YAY!!! THIS IS GREAT! So glad it's moving forward.

makoto · 2024-10-29T00:47:14Z

+
+There are multiple routes around implementing this;
+
+For the short-term; we can already use this specification in our apps today (see Appendix A).


Does out apps mean https://app.ens.domains/ or you mean anyone's app? Probably better to rephrase to be more explicit

makoto · 2024-10-29T00:49:22Z

+
+## Specification
+
+This ENSIP aims to extend the functionality introduced in [ENSIP-9](./9) and [ENSIP-11](./11) and simply relies on the same functionality.


Probably it should mention https://docs.ens.domains/ensip/19 as step 9 also incorporates chainid 0 as a fallback mechanism.

Per the draft fixes to ENSIP-19, it looks like the fallback mechanism is being cut. #13

makoto · 2024-10-29T00:52:11Z

+
+### Public Resolver
+
+The public resolver could choose to implement a fallback mechanism for EOA addresses.


Can UniversalResolver also implement the logic?

stevieraykatz · 2025-05-01T17:42:37Z

I am VERY excited about this spec and would be happy to become its champion if you're not actively pursuing it @lucemans .

I'm partial to this being a client-side spec for ENSIP-11 address queries. The reason being:

Data for fallback wallets can be written to modern address resolvers without contract changes
Implementing the fallback logic at the contract level would require redeploying resolver contracts
Client-side implementations are in the critical path for ENSIP-11 and ENSIP-19 already; I think an additional check for fallback address is reasonable additional overhead

adraffy · 2025-05-01T22:23:32Z

I was under this assumption this is implied by ENSIP-11, although maybe we should give this default/fallback/EoA-thing a proper name?

I plan on codifying this in ENSIP19.sol.

Name	CoinType	`chainFromCoinType()`	`isEVMCoinType()`	`reverseName()`
Bitcoin	`0`	`0`	`false`	`"0.reverse"`
Ethereum	`60`	`1`	`true`	`"addr.reverse"`
default	`0x8000_0000`	`0`	`true`	`"default.reverse"`
Base	`0x8000_2105`	`8453`	`true`	`"80002105.reverse"`

parse() handles the edge cases: 80000000.reverse, 80000001.reverse, and 3c.reverse.

L1ReverseDefaultResolver.sol will sit on reverse and route any EVM coin type to the default registrar.

I think ENSIP-19 had a mistake (coinType = 0 should be chain = 0) but that's fixed in the latest draft.

I think ENSIP-19 is the correct place for the content of this ENSIP.

stevieraykatz · 2025-05-02T18:21:34Z

@adraffy Totally agree that this can live in the scope of ENSIP-19.

One thing I'd like to ensure is captured though is the following flow:

A basename user sets their name for Address A on the L2ReverseRegistrar on Base
The user sets their default forward resolution address to Address A and DOES NOT set the ENSIP-11 network-specific forward resolution address
The user connects to an app which complies with ENSIP-19
That app is able to fallback to using the default chainId to close the loop and complete the primary name lookup

From what you have written above, it sounds like the user would have to have some default reverse record set on L1 which is definitely less desirable than what I laid out above.

adraffy · 2025-05-02T19:55:11Z

Unfortunately, A.default.reverse has to be on L1 since it doesn't know where to look for the default name().

reverse(0x5105, 0x8000_0000 | 8453)
resolve("5105.80002105.reverse", name()) → ""
- Since unset, try the default name:
  - resolve("5105.default.reverse", name()) → "raffy.base.eth"
- Under the current design, the "fallback logic" is internal to the L1ReverseResolver so we don't know which coin type (Base or default) resulted in the supplied name() so the forward check uses the original coin type (Base).
  - There was a version where the UR did the fallback logic instead of the L1ReverseResolver but that required all non-UR users to implement the fallback logic in ENSIP-19.
  - There was also a version where both addr(0x8000_0000 | 8453) and addr(0x8000_0000) were called and the first one to exist was returned.
resolve("raffy.base.eth", addr(0x8000_0000 | 8453)) → 0x5105
0x5105 == 0x5105 ✔️ → primary = "raffy.base.eth"

Coin type 0x8000_0000 is only queried from the forward resolver if the original call is resolve(0x5105, 0x8000_0000).

I am open to using the fallback when checking forward resolution, but it does add some complexity. At the moment, you'll have to set an address for every EVM chain if you set a default.reverse name.

adraffy · 2025-05-06T19:10:13Z

I have a PR where the UR is modified to query (2) forward addresses if the coin type was a non-zero EVM chain.

reverseNameCallback() resolves name() with [addr(coinType), addr(EVM_BIT)]
- The resolutions happen in parallel via batch gateway as we haven't decided on resolve(multicall) feature detection, although it's only 2 calls.
reverseAddrCallback() uses the first non-null address that exists, with a special case so address(0) falls through.

With this change:

EoA-like users only need to set addr(EVM_BIT) instead of addr(x) ∀ chains
Clients not using the UR need to perform this additional logic (see ENSIP-19 and below.)

The open question is how does this get documented:

ENSIP-11 establishes chain 0 but doesn't remark about it.
ENSIP-19 needs modified to state that forward resolution has an additional check if the coin type is EVM.
Should we use this ENSIP to codify: chain 0 == coinType 0x8000_0000 == EoA/Default

stevieraykatz · 2025-05-06T19:32:40Z

Great news @adraffy! This is a huge ux win for our users <3

My preference would be for us to codify this here in its own ENSIP primarily because it makes this chain id a "first class" spec that is imminently visible and not buried in the ENSIP-19 fallback logic. That being said, I think that ENSIP-19 should reference the fallback logic and use case.

stevieraykatz · 2025-05-06T19:33:35Z

+
+## Abstract
+
+This ENSIP specifies a way to set an EOA/Fallback address for a name. This allows for users to set one address to be used for all chains, or as a fallback for when a chain-specific address record is not set.


Suggested change

This ENSIP specifies a way to set an EOA/Fallback address for a name. This allows for users to set one address to be used for all chains, or as a fallback for when a chain-specific address record is not set.

This ENSIP specifies a way to set an EOA/Fallback address for a name. This allows for users to set one address to be used for all EVM-compatible chains, or as a fallback for when a chain-specific address record is not set.

stevieraykatz · 2025-05-06T19:34:37Z

+
+With the rising interest and research around account abstraction, in addition to the maturation of the multi-chain ecosystem, there is a need for users to be able to set a single address to be used across all chains.
+
+For a simple Externally Owned Account (EOA) user, this means setting their address once, and never having to worry about it again.


Suggested change

For a simple Externally Owned Account (EOA) user, this means setting their address once, and never having to worry about it again.

For a simple Externally Owned Account (EOA) user or a counterfactually deployed smart contract wallet, this means setting their address once, and never having to worry about it again.

stevieraykatz · 2025-05-06T19:35:04Z

+With the rising interest and research around account abstraction, in addition to the maturation of the multi-chain ecosystem, there is a need for users to be able to set a single address to be used across all chains.
+
+For a simple Externally Owned Account (EOA) user, this means setting their address once, and never having to worry about it again.
+For more advanced users, this means that chain-specific records can be used for smart-contract wallets, and an EOA can be specified as fallback.


Suggested change

For more advanced users, this means that chain-specific records can be used for smart-contract wallets, and an EOA can be specified as fallback.

For more advanced users, this means that chain-specific records can be used for smart-contract wallets, and a default address can be specified as fallback.

adraffy · 2025-09-17T20:47:06Z

Covered by ENSIP-19.

lucemans marked this pull request as draft September 23, 2024 09:48

lucemans marked this pull request as ready for review September 23, 2024 09:52

lucemans changed the title ~~Introduce Chain Id 0 (EOA Chain Id)~~ [DRAFT] Introduce Chain Id 0 (EOA Chain Id) Sep 23, 2024

lucemans force-pushed the ensip/chain-id-0 branch from c104d5f to b063d9e Compare September 23, 2024 10:09

lucemans added 3 commits October 1, 2024 10:47

Introduce template

1e93ea0

Update

9b2dd44

Introduce examples

2329134

lucemans force-pushed the ensip/chain-id-0 branch from 1183a0c to 2329134 Compare October 1, 2024 10:47

lucemans added 3 commits October 1, 2024 11:06

Update content

602baa6

Update x.md

f1e2148

Update x.md

293cd49

lucemans added 2 commits October 24, 2024 19:01

Expand on language & introduce public resolver modifications

1aa7462

Improve resolution order

6042bf5

makoto reviewed Oct 29, 2024

View reviewed changes

Update to remove client-side implementation

c325c9f

stevieraykatz mentioned this pull request May 1, 2025

edit: EVM-chain reverse resolution #13

Draft

stevieraykatz reviewed May 6, 2025

View reviewed changes

stevieraykatz mentioned this pull request May 9, 2025

Add "default" chain id 0 to ENSIP-11 #32

Closed

adraffy mentioned this pull request May 12, 2025

Relax HexUtils to support unpadded, add ENSIP19.parse() ensdomains/ens-contracts#436

Merged

adraffy closed this Sep 17, 2025


		There are multiple routes around implementing this;

		For the short-term; we can already use this specification in our apps today (see Appendix A).


		## Specification

		This ENSIP aims to extend the functionality introduced in [ENSIP-9](./9) and [ENSIP-11](./11) and simply relies on the same functionality.


		### Public Resolver

		The public resolver could choose to implement a fallback mechanism for EOA addresses.


		## Abstract

		This ENSIP specifies a way to set an EOA/Fallback address for a name. This allows for users to set one address to be used for all chains, or as a fallback for when a chain-specific address record is not set.


		With the rising interest and research around account abstraction, in addition to the maturation of the multi-chain ecosystem, there is a need for users to be able to set a single address to be used across all chains.

		For a simple Externally Owned Account (EOA) user, this means setting their address once, and never having to worry about it again.

	For more advanced users, this means that chain-specific records can be used for smart-contract wallets, and an EOA can be specified as fallback.
	For more advanced users, this means that chain-specific records can be used for smart-contract wallets, and a default address can be specified as fallback.

Conversation

lucemans commented Sep 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cloudflare-workers-and-pages Bot commented Sep 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Deploying ensips with Cloudflare Pages

Uh oh!

GriffGreen commented Oct 24, 2024

Uh oh!

makoto Oct 29, 2024 • 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!

makoto Oct 29, 2024

Choose a reason for hiding this comment

Uh oh!

stevieraykatz May 1, 2025

Choose a reason for hiding this comment

Uh oh!

makoto Oct 29, 2024

Choose a reason for hiding this comment

Uh oh!

stevieraykatz commented May 1, 2025

Uh oh!

adraffy commented May 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stevieraykatz commented May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adraffy commented May 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adraffy commented May 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stevieraykatz commented May 6, 2025

Uh oh!

stevieraykatz May 6, 2025

Choose a reason for hiding this comment

Uh oh!

stevieraykatz May 6, 2025

Choose a reason for hiding this comment

Uh oh!

stevieraykatz May 6, 2025

Choose a reason for hiding this comment

Uh oh!

adraffy commented Sep 17, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

lucemans commented Sep 23, 2024 •

edited

Loading

cloudflare-workers-and-pages Bot commented Sep 23, 2024 •

edited

Loading

makoto Oct 29, 2024 •

edited

Loading

adraffy commented May 1, 2025 •

edited

Loading

stevieraykatz commented May 2, 2025 •

edited

Loading

adraffy commented May 2, 2025 •

edited

Loading

adraffy commented May 6, 2025 •

edited

Loading