-
Notifications
You must be signed in to change notification settings - Fork 18
Description
I've been working on a multichain indexer for ENS, that tracks the domains and their resolutions across multiple ENS-compatible contracts. I noticed that some records indexed for Linea Names conflict with the ones recorded earlier for ENS Domains.
I started debugging and figured that Linea's Reverse Registrar didn't follow ESNIP-19 standard. The way that Linea's Reverse Registrar is currently setup follows the original ENS Reverse Registrar. What's important, both implementation use the same root node value namehash('addr.reverse')
for reverse resolution.
That's where I believe data conflicts originate from.
To add more context, I didn't notice any data conflicts between ENS Domains and Basenames. The latter follows ESNIP-19 and defines the root node for reverse registrar as following:
// @param BASE_REVERSE_NODE The ENSIP-19 compliant base-specific reverse node hash of "80002105.reverse"
bytes32 constant BASE_REVERSE_NODE = 0x08d9b0993eb8c4da57c37a4b84a6e384c2623114ff4e9370ed51c9b8935109ba;
Suggestion
Please consider implementing name resolution process the way ESNIP-19 defines it:
Possible Implementation
Update node value stored as ADDR_REVERSE_NODE
// from
// namehash('addr.reverse')
bytes32 constant ADDR_REVERSE_NODE = 0x91d1777781884d03a6757a803996e38de2a42967fb37eeaca72729271025a9e2;
// to
// namehash('8000e708.reverse')
// `8000e708` is the ESINP-19 compatible [coinTypeAsHex] calculated for Linea's Chain ID `59144`
bytes32 constant ADDR_REVERSE_NODE = 0xb84cbce1bcaa2d750f5a2874887b061647d807053b179c9e201287ab0aee8fe3;
contract ReverseRegistrar is Ownable, Controllable, IReverseRegistrar {