TL;DR
- What: Authorize TLDMinter as an ENS Root controller and seed 1,166 post-2012 ICANN gTLDs into its allowlist — in a single executable proposal.
- Why: DNS TLD operators claim their names trustlessly via DNSSEC proofs, under programmatic policy the DAO defines and can change at any time.
- Receipt: Sepolia testnet — DNSSEC proof verified via
submitClaim, TLD minted viaexecute. Contract:0x48729B...980F - Policy: 7-day minimum delay (veto open until execution), 10 claims per rolling 7-day window, 14-day proof freshness, emergency pause.
- Ask: Signal support for this design going to audit + executable. Audit budget: $30k–$50k (includes remediation review), drawn from Meta-Governance’s existing contract audit allocation ($100k for Term 6).
Problem
ENS is positioning itself as the coordination layer of the internet — the identity substrate for humans, applications, and increasingly, autonomous agents.
ENSIP-25 introduced verifiable AI agent identity. ERC-8004 brought on-chain agent registries. The naming layer for the agentic web is being built, right now, on ENS.
We need buy-in from TLD operators to fulfill this vision, and right now, it’s too high friction for them to bother.
Every new ENS TLD requires a full governance proposal, a DAO vote, and a one-off setSubnodeOwner call. That’s secure, but it doesn’t scale. For every TLD, the same gauntlet. DAO governance shouldn’t be the bottleneck, but right now it is.
With ~1,500 existing ICANN TLDs—and a new gTLD application round opening April 30—Ethereum Name Service has a unique opportunity to onboard hundreds of TLDs in a single governance cycle instead of years of one-offs.
We need to shift from per-TLD approvals to batched/programmable onboarding.
Proposed Solution
TLDMinter is a smart contract that lets ICANN TLD operators — or any white hat actor on their behalf — claim a TLD in ENS by submitting a DNSSEC proof chain on-chain. The operator publishes a TXT record at _ens.nic.{tld} containing their Ethereum address, verified against the IANA root trust chain via DNSSEC.
Anyone can submit the proof, but the TLD is always minted to the address in the DNS record — the submitter is just a gas relayer.
TLDMinter verifies this cryptographic chain via the existing DNSSECImpl oracle — the same oracle ENS already uses for DNS name imports. If the TLD is on the DAO-approved allowlist, it opens a claim subject to timelock and veto.
No manual intervention, no trusted intermediary — the DNS registry’s own signatures serve as the proof of authority.
| Layer | Contract | Responsibility |
|---|---|---|
| DNS Verification | DNSSECImpl |
Verifies DNSSEC cryptographic chains, returns authenticated DNS records |
| Policy Enforcement | TLDMinter |
Parses _ens.nic.{tld} TXT records, enforces DAO policy (timelock, rate limits, veto), calls Root |
| Veto Authority | DAO Timelock / Security Council | Can veto pending claims any time before execution |
| Root Authority | ENS Root |
Gatekeeper — only authorized controllers can write TLDs to the Registry |
| State Storage | ENS Registry |
Canonical ownership state |
Execution flow
submitClaim() ──► DNSSECImpl.verifyRRSet()
│
▼
TLDMinter stores pending request
│
▼
┌─────────────────────┐
│ MINIMUM 7-DAY WAIT │◄─── veto() by DAO or Security Council
│ (veto open until │ (can veto any time before execute)
│ execute() called) │
└─────────────────────┘
│
▼ (if not vetoed)
execute() ──► Root.setSubnodeOwner()
│
▼
Registry.setSubnodeOwner(0x0, label, owner)
│
▼
Ownership recorded ✓
Allowlist
Only 1,166 post-2012 ICANN New gTLD Program TLDs are eligible for self-serve claims. Pre-2012 gTLDs (.com, .net, .org) and ccTLDs (.uk, .de) are excluded — the nic.tld namespace is only contractually reserved for post-2012 gTLDs under the ICANN New gTLD Agreement, so pre-2012 TLDs need a full governance proposal.
.eth is permanently locked at the Root contract level — Root.locked["eth"] = true — so even if .eth were somehow added to the allowlist, any attempt to assign it would revert. This protection is enforced by the Root, not by TLDMinter.
Adding TLDs to the Allowlist
The DAO can add new TLDs to the allowlist at any time via addToAllowlist() or batchAddToAllowlist() — both are onlyDAO, meaning they require a governance proposal through the timelock.
This means that we can onboard gTLDs from the upcoming and future rounds without redeploying the contract; the DAO simply votes to expand the list.
Policy parameters
| Parameter | Value | Adjustable? |
|---|---|---|
| Minimum delay before execution | 7 days | Set at deploy (immutable) |
| Rate limit | 10 claims per rolling 7-day window | By DAO (setRateLimit()) |
| Proof freshness | 14 days max age | Set at deploy (immutable) |
| Emergency pause | pause() / unpause() |
DAO Timelock or Security Council |
| Security Council veto | Active until July 24, 2026 | Expires automatically; DAO retains permanent veto |
Proposal structure
TLDMinter is pre-deployed via EOA and verified on Etherscan before the vote, following the standard ENS governance pattern (precedent: RegistrarManager, audited by Cyfrin). Delegates can inspect the deployed contract during the entire voting period.
Single proposal, 5 calls through the DAO timelock (~29.1M gas, ~51% headroom vs 60M block limit):
| Call | Target | Action | Gas |
|---|---|---|---|
| 1 | Root | setController(tldMinter, true) |
27,809 |
| 2 | TLDMinter | batchAddToAllowlist(TLDs 1-300) |
7,473,523 |
| 3 | TLDMinter | batchAddToAllowlist(TLDs 301-600) |
7,484,020 |
| 4 | TLDMinter | batchAddToAllowlist(TLDs 601-900) |
7,494,509 |
| 5 | TLDMinter | batchAddToAllowlist(TLDs 901-1,166) |
6,653,469 |
| Total | 29,133,330 |
Total governance time: ~9 days (7-day voting period + 2-day timelock). All 1,166 TLDs seeded in one cycle.
Live Demo: TLD Oracle Portal Walkthrough
Live demo: dnssec.eketc.co/tld-oracle
Sepolia: submitClaim | execute | Contract
1. Claim TLD
The claim interface is a 3-step process. Anyone can submit a claim (acting as a gas relayer), but the TLD is always minted to the owner address in the _ens.nic.{tld} TXT record – which only the DNS registry operator can set.
The contract enforces a 14-day proof freshness window to prevent replay attacks: if a DNSSEC proof is older than 14 days, the registry must re-sign before a claim can proceed.
2. Ready to Claim
These are the 7 TLDs that are both on the allowlist and have published working DNSSEC chains with _ens.nic.{tld} TXT records. The “Stale” badges show the proof freshness system in action – these proofs are older than 14 days, so claims would revert until the registry re-signs.
Two TLDs (.gift, .property) have already been claimed on the Sepolia testnet. The proof freshness check uses Algorithm 13 (ECDSA-P256), which Verisign adopted for .com/.net/.edu in 2023, signaling industry readiness.
3. On the Allowlist
The contract-level gate: 1,166 post-2012 ICANN New gTLD Program TLDs are eligible for self-serve claims. Pre-2012 gTLDs (.com, .net, .org) and ccTLDs (.uk, .de) are excluded because the nic.tld namespace is only contractually reserved for post-2012 gTLDs under the ICANN New gTLD Agreement.
Any TLD not on the allowlist reverts immediately without burning gas on DNSSEC proof verification. Delegates can check any TLD against the allowlist using the input field.
The DAO can add new TLDs to the allowlist at any time via addToAllowlist() or batchAddToAllowlist() — both are onlyDAO, meaning they require a governance proposal through the timelock.
This means future gTLD rounds can be onboarded without redeploying the contract; the DAO simply votes to expand the list.
4. Governance and Veto
The safety mechanism. Either the ENS DAO or the Security Council can veto any pending claim at any point before execute() is called — the 7-day timelock is the minimum delay, but the veto window remains open until execution.
The veto function checks msg.sender against the stored DAO timelock and Security Council multisig addresses. Veto scenarios include fraudulent DNSSEC proofs, disputed TLD ownership, or incorrectly allowlisted TLDs.
After the Security Council’s mandate expires (July 24, 2026), only the DAO retains veto authority.
5. How It Works
The end-to-end flow in 5 steps:
- DNS registry operator publishes an
a=0x...TXT record at_ens.nic.{tld}, - Claim is submitted with DNSSEC proofs to TLDMinter,
- Contract checks the allowlist and verifies the DNSSEC proof chain,
- 7-day minimum delay — DAO/Security Council can veto before execution,
- After delay expires with no veto, anyone can call
execute()to mint the TLD in ENS.
The entire flow is trustless – no manual intervention from ENS Labs required.
Testing
The proposal has been tested end-to-end against a mainnet fork using the full ENS governance pipeline (propose, vote, queue, execute through the real Governor and Timelock contracts):
git clone https://github.com/steg-eth/dao-proposals.git
cd dao-proposals
cp .env.example .env && echo "MAINNET_RPC_URL=https://eth.drpc.org" >> .env
forge test --match-path "src/ens/proposals/tld-oracle/*" --fork-url $MAINNET_RPC_URL -vv
5 tests pass:
test_proposal()— full governance lifecycle with before/after state assertionstest_fullClaimLifecycle()— submit claim, wait 7 days, executetest_daoVetoBlocksClaim()— DAO vetoes, execute revertstest_securityCouncilVetoBlocksClaim()— SC vetoes, execute revertstest_cannotExecuteBeforeWindowExpires()— premature execution reverts
Decisions in this Temp Check
- Do you support the single-proposal structure? TLDMinter pre-deployed via EOA, proposal authorizes it and seeds the full allowlist in one vote.
- Are you comfortable with the veto + rate-limit policy? 7-day minimum delay (veto open until execution), 10 claims per rolling 7-day window, Security Council veto active until July 2026.
- Do you support allocating audit budget? $30k–$50k (including remediation) from Meta-Governance’s existing contract audit allocation before the executable goes on-chain.
Artifacts
- RFC: Scaling TLD assignment with DNS-verified DAO-governed allocation
- Repo: steg-eth/dao-proposals —
src/ens/proposals/tld-oracle/ - Rationale: RATIONALE.md
- Demo: dnssec.eketc.co/tld-oracle
- Gas breakdown: gas-table.md
Next steps
If this Temp Check is endorsed:
- Finalize audit scope and assign firm.
- Prep the executable proposal with audited contract address.
- Post executable proposal.
Call to Action
Please signal endorsement by giving this post a “like”. Otherwise, leave feedback — we’re happy to accommodate questions and concerns.