[Executable] Enable L2 Reverse Registrars and new .eth registrar controller

jefflau.eth · June 25, 2025, 8:54am

Abstract

This proposal enables five chain-specific reverse resolvers for L2 EVM networks, and one default reverse resolver as a fallback mechanism. The five chains are Arbitrum, Base, Linea, OP Mainnet and Scroll.

This proposal also enables a new .eth registrar controller and sets the reverse record of some currently un-named ENS contracts.

Motivation

The current implementation of reverse resolution is limited to Ethereum Mainnet and assumes that every entity (a generic smart contract or user account) has the same address across every EVM chain. This has been falling out of line with reality given the rise in smart contract accounts, indicating that reverse resolution should be resolved via a namespace for each chain, rather than a single reverse namespace for the Ethereum ecosystem at large.

This functionality defined formally in ENSIP-19, combined with ENSIP-11, enables “L2 Primary Names,” meaning developers can build end-to-end ENS experiences without forcing their users to transact on Ethereum Mainnet.

To support optionally setting the default reverse record at registration time, a new .eth registrar controller must also be enabled. Since new controllers have significant overhead, we are also taking advantage of this opportunity to add a referrer field for registrations and renewals. This field is emitted unchanged from the registration and renewal events and allows clients to convey information about the source of a registration or renewal for potential DAO-based referral reward schemes (not defined in this proposal).

Specification

Call setResolver on the ENS registry (registry.ens.eth ) for reverse with the address of the new default reverse resolver (0xA7d635c8de9a58a228AA69353a1699C7Cc240DCF)

Call setSubnodeRecord on the ENS registry (registry.ens.eth) for each of the following names, derived via [coinTypeAsHex].reverse as specified in ENSIP-19:

Reverse Namespace	Name	Owner	Resolver
Arbitrum	8000a4b1.reverse	wallet.ensdao.eth	0x4b9572C03AAa8b0Efa4B4b0F0cc0f0992bEDB898
Base	80002105.reverse	wallet.ensdao.eth	0xc800DBc8ff9796E58EfBa2d7b35028DdD1997E5e
Linea	8000e708.reverse	wallet.ensdao.eth	0x0Ce08a41bdb10420FB5Cac7Da8CA508EA313aeF8
Optimism	8000000a.reverse	wallet.ensdao.eth	0xF9Edb1A21867aC11b023CE34Abad916D29aBF107
Scroll	80082750.reverse	wallet.ensdao.eth	0xd38bf7c18c25AC1b4ce2CC077cbC35b2B97f01e7

Call addController on registrar.ens.eth with the address of the new .eth registrar controller (0x59E16fcCd424Cc24e280Be16E11Bcd56fb0CE547)
Call setController on reverse.ens.eth with the address of the new .eth registrar controller
Call setController on the new default reverse registrar (0x283F227c4Bd38ecE252C4Ae7ECE650B0e913f1f9) with the address of the new .eth registrar controller
Call setInterface on the .eth resolver (0x30200E0cb040F38E474E53EF437c95A1bE723b2B) with the address of the new .eth registrar controller, and the interface ID it implements (0xe4f37f79)
Call setDefaultResolver on reverse.ens.eth with the address of the new public resolver (0xF29100983E058B709F3D539b0c765937B804AC15)

Call setNameForAddr on reverse.ens.eth for each of the following addresses:

Address	Name
0x0fc3152971714E5ed7723FAFa650F86A4BaF30C5	dnssec.ens.eth
0x57f1887a8BF19b14fC0dF6Fd9B2acc9Af147eA85	registrar.ens.eth
0xaB528d626EC275E3faD363fF1393A41F581c5897	root.ens.eth
0x59E16fcCd424Cc24e280Be16E11Bcd56fb0CE547	controller.ens.eth
0x283F227c4Bd38ecE252C4Ae7ECE650B0e913f1f9	default.reverse.ens.eth

clowes.eth · June 25, 2025, 12:46pm

Thanks for this Jeff. That’s a clean explanation.
Good to see cross chain reverse resolution seeing the light of day.

I’ve spent a couple of hours on this. High level, no code deep dive.

Four main thoughts:

Has the new code been audited? Lots of moving parts here.
Can you share insight on the execution of productionized gateways with dRPC?
Calldata and Tenderly traces for this would be great, although I appreciate that there have been lots of discussions about governance interfaces supporting this through Drafting process.
The naming for contract discovery is a little confusing. The reverse resolver names e.g. 8000a4b1.reverse.ens.eth are subnames of reverse but reverse.ens.eth points to the default reverse registrar.

Some random commentary, and additional info for other readers…

Additional info: Namehash/Node for reverse.ens.eth => 0xc80bb329ad070734e9c503151c00f639f8a6acae8c9e76c730d272547417ce2f
Source

8000a4b1 => 2147525809
80002105 => 2147492101
8000e708 => 2147542792
8000000a => 2147483658
80082750 => 2148018000

These match with a historical source of truth, and my own calculations.

I noticed that the resolvers utilise dRPC gateways and fallback to gateways running on 3668.io. If I recall correctly, this is one of @nick.eth names? I’ve encountered sporadic failures pinging these gateways.

Ownership transferred to DAO Wallet here.

Comment/curiosity: Is there a plan to ever deprecate old registrar controllers at any point?

Additional info: This means that when you register a name you can set the default reverse resolution.

Interface ID validated here.

I assume we that we pass the eth node like in previous transactions e.g. this one.

Query: That said, is this discovery mechanism used?

Looking at IInterfaceResolver here, and the function comment this seems like a really weird and convoluted mechanism.

As mentioned, have not done a deep dive into the code but I did notice that the following NatSpec docs are inaccurate.

    /// @notice Registers a name.
    ///
    /// @param registration The registration to register.
    /// @param registration.label The label of the name.
    /// @param registration.owner The owner of the name.
    /// @param registration.duration The duration of the registration.
    /// @param registration.resolver The resolver for the name.
    /// @param registration.data The data for the name.
    /// @param registration.reverseRecord Which reverse record(s) to set.
    /// @param registration.referrer The referrer of the registration.
    function register(
        Registration calldata registration
    ) public payable override {

estmcmxci · June 26, 2025, 3:02am

About time!

Going forward, the DAO can activate new L2s by following this pattern:

[coinType].reverse.ens.eth
➝ mapped to resolver on L1
➝ offchain gateway
➝ queries coinType’s L2
➝ returns reverse name

—

This implementation is clean and sets a strong precedent by:

Forward-deploying a fallback resolver for emergent namespaces and future reverse resolution support
Opening a new vector for revenue through referral data emitted by the new .eth controller
One-shotting reverse record setup during .eth registration — a big UX win

Brilliant.

katzman.base.eth · June 26, 2025, 6:19pm

HYPE! So excited to see this spec on the verge of launch.

@jefflau.eth Two thoughts:

I think that this edit to ENSIP-11 should be formalized before this spec formally lands: Add "default" chain id 0 to ENSIP-11 by stevieraykatz · Pull Request #32 · ensdomains/ensips · GitHub. Unless I’m missing something, I think that it just needs to be merged at this point. It should drastically improve the UX for EOAs and counterfactual contracts leveraging this spec.
Do we have the address of the L2ReverseRegistrars that will be deployed on each of the respective chains yet? Or will those be described/deployed in a followup post?

The Basenames squad has been hard at work getting ready for compliance and we’re working through the last couple snags ensuring that we can formally comply with ENSIP-19 and migrate without any user/integrator downtime. More details to come from our end as we figure out the complete end-to-end picture and timing.

raffy · June 27, 2025, 12:37am

Since I was able to get my hands on ENSIP-19, I added these changes to the ENSIP-19 refactor as that was where I originally thought they should go. Instead of editing ENSIP-11, I was thinking of adding you as a contributor to ENSIP-19.

ENSIP-19 mentions:

default EVM chain and chainId = 0
default primary name
algorithm for coinType → chainId
includes the coinType / chainId / EVM table

katzman.base.eth · June 27, 2025, 6:08pm

Sounds like the PR I linked isn’t necessary then! Cheers, appreciate the contributor ack .

nick.eth · July 2, 2025, 7:03am

From our perspective:

L2 reverse registrars are straightforward and isolated; a vuln in one can’t affect anything other than correct reverse resolution for names on that L2. The’re upgradeable so a vulnerability could be fixed quickly and easily.
Registrar controller changes are likewise limited in scope; any modification to the reverse records is checked and limited to msg.sender, so we believe the scope for new issues here is also very limited.

As a result we don’t feel an audit is necessary for these changes.

blockful · July 9, 2025, 7:01pm

Calldata security verification

The simulation and tests of this proposal can be found here. The calldata was built based on the specification section of the proposal.

Checks performed

New contracts receiving permissions are owned by the DAO timelock (here)
Permissions and changes did took effect (here)

This can be checked by cloning the repo and running:
forge test --match-path "src/ens/proposals/ep-enable-l2/*"

Calldata:

0x7d5e81e2000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000002a000000000000000000000000000000000000000000000000000000000000004c00000000000000000000000000000000000000000000000000000000000001320000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000c2e074ec69a0dfb2997ba6c7d2e1e00000000000000000000000000000000000c2e074ec69a0dfb2997ba6c7d2e1e00000000000000000000000000000000000c2e074ec69a0dfb2997ba6c7d2e1e00000000000000000000000000000000000c2e074ec69a0dfb2997ba6c7d2e1e00000000000000000000000000000000000c2e074ec69a0dfb2997ba6c7d2e1e00000000000000000000000000000000000c2e074ec69a0dfb2997ba6c7d2e1e00000000000000000000000057f1887a8bf19b14fc0df6fd9b2acc9af147ea85000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb000000000000000000000000283f227c4bd38ece252c4ae7ece650b0e913f1f900000000000000000000000030200e0cb040f38e474e53ef437c95a1be723b2b000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb000000000000000000000000a58e81fe9b61b5c3fe2afd33cf304c454abfc7cb00000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000280000000000000000000000000000000000000000000000000000000000000036000000000000000000000000000000000000000000000000000000000000004400000000000000000000000000000000000000000000000000000000000000520000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000006e0000000000000000000000000000000000000000000000000000000000000074000000000000000000000000000000000000000000000000000000000000007c0000000000000000000000000000000000000000000000000000000000000084000000000000000000000000000000000000000000000000000000000000008e000000000000000000000000000000000000000000000000000000000000009400000000000000000000000000000000000000000000000000000000000000a400000000000000000000000000000000000000000000000000000000000000b400000000000000000000000000000000000000000000000000000000000000c400000000000000000000000000000000000000000000000000000000000000d4000000000000000000000000000000000000000000000000000000000000000441896f70aa097f6721ce401e757d1223a763fef49b8b5f90bb18567ddb86fd205dff71d34000000000000000000000000a7d635c8de9a58a228aa69353a1699c7cc240dcf0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a45ef2c7f0a097f6721ce401e757d1223a763fef49b8b5f90bb18567ddb86fd205dff71d34a7f8a095a00b663580c29f964c4bfc4ce8f41776d9ea5b70e2e08e69327a77bc000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b70000000000000000000000004b9572c03aaa8b0efa4b4b0f0cc0f0992bedb89800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a45ef2c7f0a097f6721ce401e757d1223a763fef49b8b5f90bb18567ddb86fd205dff71d3472c29f4186361a46935e4e9c3af71d1cf73cac00186fceb1cd1945ed9ed3dec1000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000c800dbc8ff9796e58efba2d7b35028ddd1997e5e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a45ef2c7f0a097f6721ce401e757d1223a763fef49b8b5f90bb18567ddb86fd205dff71d34f5b2aa07eebc1b04c9923c2e20c5988f7ec95c4150e7fb00a49f74cf73ff795a000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b70000000000000000000000000ce08a41bdb10420fb5cac7da8ca508ea313aef800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a45ef2c7f0a097f6721ce401e757d1223a763fef49b8b5f90bb18567ddb86fd205dff71d3477f44888a7cd760c9d34db42bba63325958f70077f99de6be6b318dd388d22c2000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000f9edb1a21867ac11b023ce34abad916d29abf10700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a45ef2c7f0a097f6721ce401e757d1223a763fef49b8b5f90bb18567ddb86fd205dff71d34fc94dc633606a32d73e903a0aa85e12fbe1cabc6e53ee69c1893547fda6d9691000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000d38bf7c18c25ac1b4ce2cc077cbc35b2b97f01e70000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024a7fc7a0700000000000000000000000059e16fccd424cc24e280be16e11bcd56fb0ce547000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e0dba60f00000000000000000000000059e16fccd424cc24e280be16e11bcd56fb0ce5470000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e0dba60f00000000000000000000000059e16fccd424cc24e280be16e11bcd56fb0ce5470000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000064e59d895d93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4aee4f37f790000000000000000000000000000000000000000000000000000000000000000000000000000000059e16fccd424cc24e280be16e11bcd56fb0ce547000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024c66485b2000000000000000000000000f29100983e058b709f3d539b0c765937b804ac150000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c47a806d6b0000000000000000000000000fc3152971714e5ed7723fafa650f86a4baf30c5000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000f29100983e058b709f3d539b0c765937b804ac150000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000e646e737365632e656e732e6574680000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c47a806d6b00000000000000000000000057f1887a8bf19b14fc0df6fd9b2acc9af147ea85000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000f29100983e058b709f3d539b0c765937b804ac15000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000117265676973747261722e656e732e6574680000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c47a806d6b000000000000000000000000ab528d626ec275e3fad363ff1393a41f581c5897000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000f29100983e058b709f3d539b0c765937b804ac150000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000c726f6f742e656e732e65746800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c47a806d6b00000000000000000000000059e16fccd424cc24e280be16e11bcd56fb0ce547000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000f29100983e058b709f3d539b0c765937b804ac1500000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000012636f6e74726f6c6c65722e656e732e65746800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c47a806d6b000000000000000000000000283f227c4bd38ece252c4ae7ece650b0e913f1f9000000000000000000000000fe89cc7abb2c4183683ab71653c4cdc9b02d44b7000000000000000000000000f29100983e058b709f3d539b0c765937b804ac150000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000001764656661756c742e726576657273652e656e732e657468000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Next steps:

Make sure the tested calldata matches what will be proposed (cc @jefflau.eth, @nick.eth)
The TTL parameter on ENSRegistryWithFallback.setSubnodeRecord was set to 0 (since there was no description about it)

Disclaimer: That is not an audit of the contracts.

nick.eth · July 10, 2025, 10:27am

This is now onchain for voting.

blockful · July 10, 2025, 2:29pm

Review of active proposal

The proposal has 16 operations, on the submitted proposal, 6 of them use parameters that differs from the tests and calldata published above. While the proposal simulation passes, if executed, it will not achieve the goal of the proposal.

Operations 2, 3, 4, 5, 6:

These operations are described in step 2 of the specification section. The differences are in some label and node arguments, which are crucial for the reverse resolution on ENSIP-19 to happen. The labelhash was probably calculated differently.

Operation number (1 to 16)	Argument	Expected	Submitted
2 - registry.setSubnodeRecord	label	a7f8a095a00b663580c29f964c4bfc4ce8f41776d9ea5b70e2e08e69327a77bc	7d8e29b968b7788e83efa746345c315e0cf10df6950259a7cb05ce0149b8b6e3
3 - registry.setSubnodeRecord	label	72c29f4186361a46935e4e9c3af71d1cf73cac00186fceb1cd1945ed9ed3dec1	4056cb788b3af93d9486e35f4d0aff6b21a4da32161ef55acba5a78d69dad5b6
4 - registry.setSubnodeRecord	label	f5b2aa07eebc1b04c9923c2e20c5988f7ec95c4150e7fb00a49f74cf73ff795a	44495acbb270e33daa2b6b957b8713b55ab4a023300855e3adeb370f8bfcd47a
5 - registry.setSubnodeRecord	label	77f44888a7cd760c9d34db42bba63325958f70077f99de6be6b318dd388d22c2	f66cf533d101dfb2f2352e61965e14aa7e9c4164b3bfc91cbe188645e0f16336
6 - registry.setSubnodeRecord	label	fc94dc633606a32d73e903a0aa85e12fbe1cabc6e53ee69c1893547fda6d9691	2e83a9aa4cc1622acc9e36e8853598634e92fa0eb10aec9b07fc68664b2ad87e

Operation 10

These operations are described in step 6 of the specification section. The namehash for .eth TLD is incorrect.

Operation number (1 to 16)	Argument	Expected	Submitted
10 - ethTLDResolver.setInterface	node	93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae	58665280491fc90c59d3e71704f32f95343423627fb87cf300bb02544c671cdb

Recommendation

Vote against the proposal that’s now live and resubmit with above parameters.

nick.eth · July 11, 2025, 7:49am

Apologies to the DAO and delegates for this mess-up. A new tool we developed to give better insight into transactions produced faulty data, and I failed to catch it on manual review due to a combination of a copy-paste error and insufficient dilligence. We’ll try again with correct calldata in the next day or two.

raffy · July 14, 2025, 6:40pm

Arbitrum: ChainReverseResolver → ArbitrumVerifier → EthVerifierHooks / isBoLD = true / window = 50400 / minAgeBlocks = 1800 (6 hrs @ 12sec/block)
Base: ChainReverseResolver → OPFaultVerifier → EthVerifierHooks / GameFinder / window = 21600 sec (6hrs)
Linea: ChainReverseResolver → LineaVerifier → LineaVerifierHooks
Optimism: ChainReverseResolver → OPFaultVerifier → EthVerifierHooks / GameFinder / window = 21600 sec
Scroll: ChainReverseResolver → ScrollVerifier → ~~ScrollVerifierHooks?~~ should be EthVerifierHooks
- Fixed Deployment: ChainReverseResolver

clowes.eth · July 15, 2025, 11:27am

Great spot @raffy

To add some color to this comment, the Deployed Verifier contract being used for Scroll is using the incorrect ‘hooks’ contract which defines how chain specific account and storage proofs are verified.

Scroll’s Euclid upgrade adopted Ethereum’s native Merkle-Patricia Trie whereas previously they had used a zkTrie.

The contract deployer needs to call setGatewayVerifier on the Scroll ChainReverseResolver and pass in the address of a deployed verifier using these new hooks. Labs can either deploy their own or use one already deployed e.g. scroll.verifier.unruggable.eth

This issue does not necessitate additional changes to the calldata for this executable but does require the aforementioned verifier update.