The Status Quo re: Assigning TLDs
Currently, 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. With ~1,500 ICANN TLDs, it’s an undue burden to ask delegates to repeatedly go through the full governance process for each one.
Importantly, however, DNS can’t become an authority over ENS.
So the question is: can we make TLD onboarding programmable without giving up sovereignty?
Not “DNS assigns ENS,” but:
DNS proposes, ENS programmatically executes under DAO-defined law.
Programmable TLD Assignment Model
With Fusaka, bridging to ‘real-world’ cryptography has become economically feasible and practical at protocol scale. Let’s use this opportunity to build a turnkey solution for TLD operators that is cryptographically grounded, programmable by policy, and governed by the DAO.
A programmable TLD assignment model would move ENS from one-off governance actions to a standing, programmable process, while preserving root sovereignty and constitutional control.
This direction follows Article V of the ENS Constitution, which commits ENS to integrating with the global DNS namespace while preserving decentralization.
With this in mind, I’ve been exploring a concrete implementation of this model: the TLD Oracle.
How the TLD Oracle Would Work
Building off the recent integration of EIP-7951, I’ve developed a mock TLD oracle on Sepolia that demonstrates how this could work in practice.
Our system enforces strict separation across five layers:
| Layer | Contract | Responsibility |
|---|---|---|
| DNS Verification | DNSSECOracle |
Verifies DNSSEC cryptographic chains and returns authenticated DNS records. |
| Policy Enforcement | TLDMinter |
Parses _ens.nic.tld TXT records for ownership claims, enforces DAO policy (timelock delays, rate limits, veto mechanisms), and calls Root to execute TLD assignment. |
| Veto Authority | DAO Timelock / Security Council | Can veto pending claims during the timelock window. Security Council veto expires and can be revoked; DAO retains permanent veto power. |
| Root Authority | ENS Root |
Privileged gatekeeper that can write TLDs to the ENS Registry. Only authorized controllers (like TLDMinter) can call it. |
| State Storage | ENS Registry |
Holds the canonical ownership state (node → owner mappings). |
Execution Flow
submitClaim() ──► DNSSECOracle.verifyRRSet()
│
▼
TLDMinter stores pending request
│
▼
┌─────────────────────┐
│ TIMELOCK WINDOW │◄─── veto() by DAO or Security Council
└─────────────────────┘
│
▼ (if not vetoed)
execute() ──► Root.setSubnodeOwner()
│
▼
Registry.setSubnodeOwner(0x0, label, owner)
│
▼
Ownership recorded ✓
Demo: TLD Oracle
I’ve developed a live demo on Sepolia with testnet contracts that shows this model working end-to-end: EIP-7951 DNSSEC Solutions
The demo verifies _ens.nic.tld TXT records via DNSSEC using the P-256 precompile, then executes DNS-verified TLD assignment through a four-layer architecture:
| Layer | Role |
|---|---|
DNSSECOracle |
Verifies DNSSEC cryptographic chains |
TLDMinter |
Enforces DAO policy (timelock, rate limits, veto window) |
ENS Root |
Gatekeeper that authorizes writes to the registry |
ENS Registry |
Stores canonical TLD ownership |
Example execution: Sepolia Transaction Hash: 0xdbf45d11ae... | Etherscan Sepolia
This separation ensures DNS registries can claim their TLDs trustlessly while preserving ENS DAO sovereignty through veto mechanisms and timelocked execution.
Note: for this demo, we deployed mock ENS Root and Registry contracts on Sepolia to safely simulate root-level behavior.
Request for Red-teaming
I’m calling on the DAO to offer adversarial feedback on this model, both technically and operationally. Particularly interested in stress-testing:
- Whether the separation between DNS as evidence and the DAO as authority is airtight
- Failure modes around DNS compromise, oracle bugs, or policy misconfiguration
- Whether the timelock, veto, and revocation mechanisms are sufficient
- Any ways this design could unintentionally weaken ENS root sovereignty
The goal is to stimulate a collaborative environment where we can collectively find a scalable approach to TLD assignment ahead of the upcoming gTLD round, so the DAO has sufficient bandwidth to handle demand without compromising governance or sovereignty.
→ Repository: dnssec-solutions/TLD-oracle at master · eurekaetcetera/dnssec-solutions · GitHub