Holesky ENS registration via resolver.eth completely broken?

Using the official resolver with a record on Holesky seems to be broken. There is no revert message so I cannot tell why this is failing: https://eth-holesky.blockscout.com/tx/0x9eb7788b9fd1b84fd72e74b22f0615a92cf43baed64b7f203a463f75a1c19e85

I had success using what looks like some random person’s deployed resolver: Holesky transaction 0x9200a48d0bae72e10605c091b69ca5760ad7d0c1aa9a41175beaf8957d4a19e5 | Blockscout

Why is this happening? Why does the official resolver (resolver.eth) per the post here (Testnet deployment addresses (Holesky and Sepolia)) fail to work?

It has been really frustrating trying to write my own code for sending ENS registration transactions (commit/register). None of the docs at ETH Registrar | ENS Docs explain what the resolverAddress is or what needs to go in the data array. I had to observe other people’s transactions on mainnet/testnets to learn what to put here, calling setAddr, which is insanely frustrating that there are not docs on this. I hardly know what setAddr does but no one else is sending transactions with a zero address resolver so I am not going to do that…

Thank you for reading, I could really use suggestions

1 Like

I’ve implemented all of the public registrars (Mainnet, Sepolia, Holesky, Base, Base Sepolia, Linea) and reverse registrars (Mainnet, Sepola Holesky) in vanilla html/ethers.

My tool prints out a full textual timeline of what it’s doing. For all registrars, it’s using the minimal information possible to bootstrap the process. It also supports choosing a final wrapper state, regardless of the available controllers.


I tested my tool on Holesky w/Wrapped+Address and it failed surprisingly. I compared the log output to the constructor of the current PR 0x9101 and noticed that the _trustedETHController 0x179B does not match the current default wrapped “eth” registrar 0xF404 (which can be derived from interfaceImplementer("0x612e8c09").

I patched the wrapped controller in my tool (0xF4040x179B) and the registration process worked successfully:


For unwrapped controller, registerWithConfig() lets you set both a resolver and a default addr(60) address. The address only makes sense if a resolver is set. The controller can do this w/o any special trust since it becomes the owner first, sets the record, and then transfers ownership.

For wrapped controller, register() lets you set a resolver, an array of calldata to populate the resolver, and a reverseRecord. The calldata only makes sense if a resolver is set. The reverseRecord also requires the resolver since it stores the name record in the same resolver.

To support these actions on a custom resolver, you must implement setName() and multicallWithNodeCheck() and you must permit the controller and reverse registrar contracts to make writes regardless of ownership.

Due to the design of the PR and the NameWrapper, there is a complex interplay between these contracts (they must trust each other) to enable the single transaction post-commit to register the name, set records, and set a primary name.

2 Likes

Many thanks for the detailed information. I like the UI of your tool, too. I understand what wrapping means now.

So to reiterate this is a deployment issue, right? The ETH Registrar Controller specified by Testnet deployment addresses (Holesky and Sepolia) (0x179Be112b24Ad4cFC392eF8924DfA08C20Ad8583) should be equal to baseResolver.interfaceImplementer(namehash("eth"), "0x612e8c09") but that is currently set to 0xF404D2F84BC1735f7D9948F032D61F5fFfD9D3C3.

And my deployment here worked because this other resolver trusts 0xF404D2F84BC1735f7D9948F032D61F5fFfD9D3C3 but the “official” resolver (resolver.eth on Holesky) does not, right?

1 Like

ya, the interfaceImplementer("0x612e8c09") result needs fixed.

Thanks. @jefflau.eth, please be aware of this. If you still have access rights, it would be nice if you could fix it and confirm what happened.