Updated ENSIP draft: Contract Self-Naming via IContractName and IContractNamer

raffy · June 9, 2026, 4:23pm

To quickly recap on the thought process: during design, IContractName seemed like the better candidate, since it’s incredibly simple, but during implementation, a problem surfaced: it’s harder for an indexer to implement, since it’s an alternative resolution path (unless you’re invoking the resolver for each query.)

When contract naming was added to ENSv2, IContractNamer was used for everything that wasn’t Ownable. IContractNamer works great with EAC (supports multiple namers via simple role check), it works great with delegation (just return another contract’s isContractNamer() response), and it doesn’t imply the same mutable connotations that Ownable does.

ENSv2 core contract naming overview:

Ownable contracts name as expected
There is a single ContractNamer for the DAO
Any contract w/EAC implements IContractNamer, has role ROLE_CAN_NAME, and grants it to the DAO (Example)
- PermissionedRegistry (and UserRegistry and WrapperRegistry)
- PermissionedResolver
- PermissionedAddressSet
- StandardRentPriceOracle
Any contract w/o EAC delegates to the shared ContractNamer via DelegatedContractNamer
(Example)

Although IContractName isn’t used by the core contracts, it’s still a useful design. An improvement to the initial design would be a new event which should be emit anytime the underlying name changes to improve indexing efficiency.

We also want to be able to rename contracts, so we can version them if they get replaced. Although both techniques allow mutability, IContractNamer is less code if an existing authorization method already exists (the shared ContractNamer).

Lastly, there is a new library AccountNamerLib which codifies the authorization logic.

Other resources: