We’ve been iterating on approaches to contract naming on ENS based on feedback from @nick.eth, and other key community members, and would like to share our proposal on what we believe to be the best way forward.
TLDR; we create a new custom resolver and reverse registry optimised for smart contracts that can serve as a registry for all Ethereum contracts and DApps, built on ENS, but without requiring core protocol changes.
Proposal - The Enscribe Contract Naming Pilot: A Custom Reverse Registry for All Smart Contracts
The Problem: Not Every Contract Can Have a Name
The Ethereum Name Service (ENS) has become essential for user-friendly blockchain interaction. The ability to set a primary name for a contract (e.g., uniswap.eth) is a powerful feature, but it’s currently limited. To set a primary name, a contract must implement specific interfaces like Ownable (ERC-173), which grants administrative control.
However, many critical contracts are intentionally designed without owners to be trustless and immutable. This includes contracts deployed from burner accounts, or core protocol contracts where ownership would be a liability. Many contracts were deployed even before the introduction of ERC-173. As a result, a significant portion of the on-chain world remains unnamed, making them harder to identify and trust.
The Solution: An Experimental, Standalone Reverse Registry
The Enscribe team proposes an experimental pilot to address this gap. We plan to launch a new, standalone Reverse Registry specifically for smart contracts. This registry will operate as a custom ENS resolver, allowing any contract to have a primary name (not exactly ENS primary name, maybe we can call it Enscribe primary name) without requiring any changes to the contract itself or to the core ENS infrastructure.
Our goal is to create a flexible and inclusive naming system that caters to the realities of smart contract development.
How It Works
Our system is built around a custom resolver that includes a StandaloneReverseRegistrar with a flexible ruleset.
-
Custom Resolver: Developers can choose to set their ENS resolver to our custom Enscribe resolver. This is an opt-in process that gives them access to our naming system without affecting the main ENS registry.
-
Flexible Authorization: The core of our experiment is a new
setName()function that bypasses the standard checks. It uses a custom rules set for the authorization model managed by the Enscribe team in the short term. Our initial thoughts on the ruleset are:- For Deployers: In addition to
Ownable, the original deployer of a contract whether an individual, a multi-sig, or a DAO has direct authority to name their contract. Unless authority is transferred or changed by the Enscribe team for any reason (in case of leaked private key). - For Other Contracts: For contracts deployed with burner accounts or compromised keys, a legitimate controlling entity (like the project’s DAO) can submit a claim to the Enscribe team. After a review process to verify their connection to the contract, we will grant them the authority to set the name.
- For Deployers: In addition to
-
Direct Name Setting: Once an account is authorized, they can call
setName()on our resolver to directly set the Enscribe primary name for their contract. This action is recorded within our resolver’s context, providing a verifiable, public name for the contract.
A Complete Contract Profile
Beyond just a primary name, our custom resolver will allow for the creation of a full contract package or even DApp registry built on ENS through a rich set of text records. This turns a simple name into a comprehensive, verifiable profile. Users can add critical metadata directly to their contract’s ENS record, including:
- Verification: Links to source code verification on platforms like Sourcify and Etherscan, and the verified
abi,binandsrcrecords hosted by them. - Links:
contenthashfor a decentralized website, aurlfor a traditional site, andrepofor the source code. - Metadata: Information like
author,license, and a human-readablenoticeexplaining the contract’s purpose. - Technical Details: The contract
auditreports, and potentially theproxyImplementationaddress for proxy contracts.
Collaboration with a number of contract/DApp developers and developer tooling teams would be sought to help establish a suitable baseline of contract or DApp metadata standards.
A Safe and Non-Intrusive Experiment
This pilot is designed to be completely independent and additive to the existing ENS ecosystem.
- No Core Changes: We will not be modifying any of the core ENS registry or registrar contracts. Our system works entirely within our custom resolver.
- Opt-In: Participation is entirely voluntary. Developers choose to use our resolver.
- Community Focused: This initiative is aimed at making the on-chain world more legible and user-friendly, benefiting developers, users, and analytics platforms alike.
The Long-Term Vision
If this pilot proves successful and valuable to the community, we envision a future where our registry could be controlled by the ENS DAO. It could potentially act as an official fallback reverse registry for contracts, providing a name when one isn’t set through the primary ENS mechanism. This would be a significant step toward ensuring every contract on Ethereum can have a clear and trusted identity.
We believe this experiment will demonstrate a clear need for more flexible contract naming solutions. We invite the community to provide feedback on this proposal and to participate in the upcoming pilot.