Add ERC: Onchain registration of chain identifiers

[yuliyaalexiev]

This ERC proposes deriving chain identifiers by hashing their chain name (along with other relevant information) and using ENS to map chain names to these identifiers, replacing the centralized list currently maintained on GitHub.

[eip-review-bot]

File ERCS/erc-7785.md

Requires 1 more reviewers from @g11tech, @SamWilsn, @xinbenlv

[github-actions]

The commit 2dc2b85 (as a parent of 37d6b72) contains errors.
Please inspect the Run Summary for details.

[bumblefudge]

Are there any chain_ids registered in eth-lists/chains of this size already? if all keccak chain_id's generated this way have the same length, should eth-lists/chains STOP allowing registrations of that length to prevent [malicious] collisions?

[bumblefudge]

i like the idea of L2s and L3s using this mechanism and reducing traffic/burden on eth-lists/chains, but eth-lists/chains will still be needed for lots of non-L2 use-cases, so I think the smooth continued operation of eth-lists/chains should be in-scope for this ERC!

[yuliyaalexiev]

@sampkaML - what are your thoughts on this?

[sampkaML]

I agree with preventing eth-lists/chains from allowing registrations of this length due to your stated reason of avoiding [malicious] collisions.

However, regarding the continued use of existing eth-lists/chains and their inclusion within the scope of this ERC, I'm not sure I agree. What would be the downside of allowing the current ones to continue but stopping new registrations unless they follow this new format?

[bumblefudge]

Simple: not every Eth transaction that needs replay protection is settling on an L2 anchored to mainnet (or to any other EVM chain), and those chains can't use this new registry. Private networks, permissioned networks, EVM-mode L2s of other L1s, all need chainIds (and can't be accessed via a contract that they anchor to on mainnet).

[sampkaML]

While I understand the concerns about private networks and other unique use cases, these issues aren't addressed by the current ENS implementation either. Our goal with this ERC isn't to solve every possible problem but to apply the 80/20 rule—improving the system for the vast majority of users. By focusing on the common scenarios where this solution will have the most impact, we can make meaningful progress now and address the remaining specialized cases with tailored solutions in the future.

[yuliyaalexiev]

@bumblefudge, which chains specifically will be adversely impacted by this change now?

[iJaack]

Hi, I would suggest to think about this EIP as a solution for any EVM, even outside the L1+L2s ecosystem. Some reasons:

• chain teams already submit their info (name, chainID, etc.) to ethereum-lists/chains because that’s the ultimate source of truth for the list of all EVMs, so asking them to submit a transaction in order to do the same thing they would do already seems like a reasonable compromise
• From our research (I work at routescan.io) there are currently roughly 1200 chains live at the moment, of which roughly 85% is EVM, and even though the pace of growth has increased, we don’t forecast millions of chains within the foreseeable future, so increasing the size of the identifiers to 32 bytes may not be needed.

[sampkaML]

I hear the point that 32-byte identifiers might seem like an overcorrection at the moment, especially if the current chain ecosystem isn’t scaling into the millions anytime soon. But I believe that making room for robust, collision-resistant identifiers now—even if it adds a small hurdle in the short term—ultimately sets us up for long-term success. By implementing larger identifiers early, we ensure that we won’t need multiple incremental expansions down the line as the ecosystem evolves and potentially grows beyond today’s forecasts.

In other words, taking this step now creates a durable standard that can accommodate future growth without repeated adjustments or migration pains. It’s about thinking ahead and choosing a solution that positions us for scalability and reliability in the years to come.

[yoavw]

I think eth-lists/chains should stop accepting new entries as soon as we populate the chainid.reverse domain during bootstrap. We won't be able to add any additional entries to the domain afterwards, so new chains that inadvertently register new eth-lists/chains entries won't be resolvable by wallets later when chain-specific addresses are adopted.

New chains that for whatever reason prefer not to register their names on Ethereum L1 should register it in a new alt repo, so it'll be explicit that they opt out of chain-specific address resolution.

[iJaack]

I would suggest allowing null or 0 input for the SETTLEMENT_CHAIN_ID and DEPLOYER_CONTRACT_ADDRESS, so as to allow non-L2 use cases as well.

Also, I believe another input should be the chainID of the DA its posting data to, since it’s becoming very frequent to see chains not posting data to blobs on L1 but to DAs on other EVMs or even on other VMs (see NEAR or Avail).

This new onchain registry could help a lot block explorer providers like us because it tells us immediately how to index the chain, and if there’s some extra indexing to add to scan the chain properly.

Another useful field could be the ‘stack’ the chain is using: OP Stack, ZK Stack, etc. Again, it helps with identification and categorization. These may be a lot of fields, but as we saw in some cases, chains change their nature: changing stack, posting to a different DA layer, etc. If the chain changes his nature, it needs to change chainID.

We found out that a lot of our customers often re-deploy their testnet chains multiple times under the same chainID, and they have no clue that this is actually a bad idea: a lot of tools use the chainID as the unique identifier for a chain, so if a chain has changed significantly (not referring to an upgrade, but a significant shift like, for example Lisk or Celo moving from L1 to L2), this can lead to tools having to reset their data about that specific chain, when they could simply add a new database / bucket / collection for the new chain, if the chainID were changed.

Some of these fields need to be in the input, so that changing those will change the chainID directly, but some can just be linked to attestations that provide useful information for all infra providers.

[sampkaML]

Thank you for your insightful suggestions. I agree that allowing null or zero inputs for SETTLEMENT_CHAIN_ID and DEPLOYER_CONTRACT_ADDRESS would accommodate non-L2 use cases and enhance the versatility of the registry.

However, my main concern is that I prefer not to dictate which inputs are required or optional within this ERC itself. I believe our primary goal should be to offer a flexible framework that includes all these options, allowing future ERCs—such as those focusing on interoperability—to specify the requirements for these variables, including which can be null or zero. This approach ensures that the ERC remains adaptable to a variety of use cases and can evolve with the ecosystem's needs.

[iJaack]

I understand, and I believe this needs to become an ERC as quick as possible so that the conversation with the wide community can start. Let's make it as flexible as possible so that future work can address extensions for interoperability.

@sampkaML So you think other info, like DA layer, tech stack and others could be part of a new attestation-based spec / ERC?

[sampkaML]

Yes, I believe that incorporating additional information like the DA layer, tech stack, and other relevant details could be part of a new attestation-based specification or ERC. This will require further discussions and decisions on the optimal way to implement where this information is stored and how it's accessed. I strongly believe that these aspects are closely tied to how interoperability will function, and addressing them will be crucial for developing effective interop solutions.

[yoavw]

If the chain changes his nature, it needs to change chainID.

If we included tech-stack, wouldn't it mean that tech changes cause unneeded service interruption? E.g. if Optimism switches from Optimistic to ZK validity proofs, should it require switching to a new chainid and refreshing it in every user's wallet?

[mds1]

Thanks for putting this together! I am very supportive of this idea in general and have some questions regarding the details :)

[mds1]

When will the rationale section be filled in? I have some questions around the rationale (see other comments) for certain decisions that I suspect would be covered here

[mds1]

How are testnets handed, are they also registed as e.g. rollup-sepolia.eth on mainnet, or are they be registered in the Sepolia or Holesky ENS deployments?

[sampkaML]

If they are live testnets i think they should be treated same way as a mainnet is.

[yoavw]

ERC-7828 indicates that they're resolved in the chain specified as the TLD. E.g. rollup.sepolia.

[mds1]

What is DEPLOYER_CONTRACT_ADDRESS? It's not defined below

[iJaack]

I believe this is equal to the genesis contract address, it's for L2s/L3s. If it's not intended like this, then further specifications are needed.

[clowestab]

It says

DEPLOYER_CONTRACT_ADDRESS is the address of the L2 on the L1

As in the Rollup Contract? Its not beyond the realms of possibility that this could change. As could SETTLEMENT_CHAIN_ID in principle. Is that the intention?

[iJaack]

Then here’s the principle again, as I stated in another comment: if the DEPLOYER_CONTRACT_ADDRESS, does it mean that the Rollup changes, relative to the L1? In the same way, if the SETTLEMENT_CHAIN_ID changes, the chain is changing nature, so it’s another chain.

That’s because if the user deposits on the Rollup, they do it knowing that there’s a specific configuration (at a high level), for example that the X L2 settles on Ethereum.

If the settlement chain changes to another L1, maybe the users or developers don’t trust it anymore because they trusted Ethereum better. The same could be said about changing the DA layer, and similarly the tech stack (OP, ZK, SN, etc.)

Maybe the alias can be the same, but there’s got to be a way to differentiate the chains when they change their fundamental nature. This is about trust assumption as much as it is about versioning chain releases for the community.

[mds1]

Is VERSION arbitrarily specified by the rollup, i.e. it refers to the rollup's version, or does it refer to the version of this ERC to support updates to the scheme defined here?

[sampkaML]

I would say this is the version of the ERC.

[mds1]

A few questions here:

1. What does "settle" mean? Is this where calldata / state diffs are posted, or where withdrawal proofs are, etc?
2. Is this ERC intended to cover rollups only (seems like yes based on SETTLEMENT_CHAIN_ID) or any chain (implied by the abstract and motivation)?
3. What if a chain only posts calldata to an alt-DA layer and has no settlement chain ID? This DA layer could be a centralized server that has no chain ID
4. What if a chain has two bridges it accepts deposits from? Or no bridges? See https://youtu.be/Aey1_acXL0k?si=cNdwikh15P6EFNIi

To sidestep these questions, perhaps we simplify this to the approach to unique identification here to just be the chain name, and some type of version identifier. Does adding everything else to the hash add any value? All other metadata can still live onchain in an ENS record of myRollup.eth, but doesn't have to be used to derive the chain ID

[iJaack]

Completely agree here on 3. and 4., but it seems this is a first implementation, hence needs to be as general and flexible as possible.

As I was describing in another comment, the fields could be reduced to three or four and the rest of the information can be posted as metadata included in an attestation, so that this registry truly becomes the ultimate source of truth and hub for all EVM chains.

[mds1]

How does resolution work? I have not used ENS for resolving anything other than addresses. Do we need to specify custom resolvers, or certain records to store data in?

[mds1]

What stops a chain from always using the legacy process and getting whatever chain ID they want? Is this a one time migration somehow? I don't fully understand the EF's role here

[iJaack]

I can tell that a lot of chains use random chainID and don’t care about collision until they reach Mainnet (or a bit after that, unfortunately). Chains that don’t adhere to this registry will always be there, but I guess new ERCs could be implemented that design an ‘enforcement plan’ within and outside the Ethereum ecosystem.

[yoavw]

This should be a one-time process during bootstrap. EF's role would be just to copy current content of eth-lists/chains to the new domain. This operation will be publicly verifiable. After it's populated, EF should have no way to keep editing the data in the domain.

ERC-7828 can be seen as an 'enforcement plan' because wallets that use chain-specific addresses won't be able to resolve new chains that don't adhere to this process.

For that reason I proposed (above) that eth-lists/chains stops accepting new entries when the one-time migration happens. It'll prevent inadvertent use of incompatible chainids by devs not familiar with the new process. Chains devs that don't adhere to it could register elsewhere and should be aware that they opt out of ERC-7828 support.

[iJaack]

Just to again remind about the chainID collision: there are two chains that currently use the same chainID.

Nova Network and Waves use the same chainID, 87.

[mds1]

A lot of tooling currently doesn't support uint256 chain IDs, e.g. see MetaMask: https://github.com/MetaMask/metamask-extension/blob/39528b02100a6003f412bbef5e0b560002c945bc/shared/constants/network.ts#L229-L233

Part of this ERC will require an effort to ensure various tooling developers support uint256 chain IDs

[Eikix]

Ledger only supports up to 4 bytes chainIDs for clear signing!

For ledger it's harder to implement because it's at the level of their hardware/firmware

[mds1]

What happens when an ENS name expires and has a new owner? The new owner can change data, what problems will this cause for users? We may want to consider a way to freeze or lock the data so only a specific address can update it

[sampkaML]

This is a great point. Let me put together some ideas for how we can potentially lock the data.

[SamWilsn]

Gentle reminder to keep technical discussions on the Ethereum Magicians thread.

[SamWilsn]

ENSIP-11

This is an external link, and must be removed. We do have a process for allowing certain external links. See EIP-5757.

[sampkaML]

Yes, I believe that incorporating additional information like the DA layer, tech stack, and other relevant details could be part of a new attestation-based specification or ERC. This will require further discussions and decisions on the optimal way to implement where this information is stored and how it's accessed. I strongly believe that these aspects are closely tied to how interoperability will function, and addressing them will be crucial for developing effective interop solutions.

[sampkaML]

I hear the point that 32-byte identifiers might seem like an overcorrection at the moment, especially if the current chain ecosystem isn’t scaling into the millions anytime soon. But I believe that making room for robust, collision-resistant identifiers now—even if it adds a small hurdle in the short term—ultimately sets us up for long-term success. By implementing larger identifiers early, we ensure that we won’t need multiple incremental expansions down the line as the ecosystem evolves and potentially grows beyond today’s forecasts.

In other words, taking this step now creates a durable standard that can accommodate future growth without repeated adjustments or migration pains. It’s about thinking ahead and choosing a solution that positions us for scalability and reliability in the years to come.

[sampkaML]

If they are live testnets i think they should be treated same way as a mainnet is.

[sampkaML]

I would say this is the version of the ERC.

[yoavw]

Suggested change

	An important property of the centralized list is that it keeps a one-to-one correspondence between names and indentifiers.
	An important property of the centralized list is that it keeps a one-to-one correspondence between names and identifiers.

[yoavw]

I think eth-lists/chains should stop accepting new entries as soon as we populate the chainid.reverse domain during bootstrap. We won't be able to add any additional entries to the domain afterwards, so new chains that inadvertently register new eth-lists/chains entries won't be resolvable by wallets later when chain-specific addresses are adopted.

New chains that for whatever reason prefer not to register their names on Ethereum L1 should register it in a new alt repo, so it'll be explicit that they opt out of chain-specific address resolution.

[yoavw]

If the chain changes his nature, it needs to change chainID.

If we included tech-stack, wouldn't it mean that tech changes cause unneeded service interruption? E.g. if Optimism switches from Optimistic to ZK validity proofs, should it require switching to a new chainid and refreshing it in every user's wallet?

[yoavw]

The one contract that is unlikely to ever change for a rollup, even if it changes its underlying technology, is the canonical bridge. It can't change easily because it holds assets on L1. Anything else might change in a future upgrade. Shouldn't we use CANONICAL_BRIDGE_ADDRESS rather than DEPLOYER?

[yoavw]

ERC-7828 indicates that they're resolved in the chain specified as the TLD. E.g. rollup.sepolia.

[yoavw]

This should be a one-time process during bootstrap. EF's role would be just to copy current content of eth-lists/chains to the new domain. This operation will be publicly verifiable. After it's populated, EF should have no way to keep editing the data in the domain.

ERC-7828 can be seen as an 'enforcement plan' because wallets that use chain-specific addresses won't be able to resolve new chains that don't adhere to this process.

For that reason I proposed (above) that eth-lists/chains stops accepting new entries when the one-time migration happens. It'll prevent inadvertent use of incompatible chainids by devs not familiar with the new process. Chains devs that don't adhere to it could register elsewhere and should be aware that they opt out of ERC-7828 support.

[yoavw]

This domain could also be made more expensive to deter squatting. L2 projects require significant funding anyway so spending hundreds of dollars on registration won't be a major issue, but will make squatting impractical.

[sambacha]

Why does ENS get to be the resolver?

This effectively gives them de facto namespace control over any L2 that uses this.

dmap seems a much more appropriate solution if your wanting namespace delegation and resolution.

[thedarkjester]

Suggested change

	Without this property, an attacker could register a fresh name pointing to an existing identifier. For example `my-testnet` could point to mainnet `0x1`. A user could be tricked into signing a transaction for the innocent looking `my-testnet` while actually signing a transaction for mainnet, a transaction that we attacker can then replay.
	Without this property, an attacker could register a fresh name pointing to an existing identifier. For example `my-testnet` could point to mainnet `0x1`. A user could be tricked into signing a transaction for the innocent looking `my-testnet` while actually signing a transaction for mainnet, a transaction that the attacker can then replay.