Update: Following discussion, we’re updating this Temp Check to proceed along a two-phase approach.
Phase 1: Deploying TLDMinter with execution off
In Phase 1, TLDMinter ships as specified-above with contract deltas:
| Delta | Change |
|---|---|
executionEnabled flag |
execute() is gated behind a boolean flag, off at deploy. The DAO flips it at Phase 2. Effect: claims can be submitted and sit in the timelock; none can finalize until the DAO turns execution on. |
MintRequest.policyHash |
MintRequest gains one field, bytes32 policyHash — one storage slot per claim. |
| TXT record extension | The existing _ens.nic.{tld} TXT record carries two new strings alongside a=0x...: policy=<url> and policy_hash=0x<hex>. Both ride the same DNSSEC-verified RRset — no new oracle calls, no new verification path. |
PolicySubmitted event |
New event PolicySubmitted(bytes32 indexed labelHash, string policyURL, bytes32 policyHash), emitted by submitClaim. Off-chain archival tooling subscribes to it. |
The hash is committed, not enforced on-chain. submitClaim records policyHash and emits the event; it adds no new revert paths and no new authority surfaces.
Enforcement is social — a reviewer reads the policy during the existing 7-day veto window (see Phase 2). This keeps the audit surface small: the net-new code is TXT-string parsing plus one event, on top of the DNSSEC + claim flow already in scope.
Implementation status: these deltas are specified, not implemented; the reference implementation lands as part of the audit-scope step, with a Sepolia deployment for inspection before the executable.
Phase 2: Operationalizing TLDMinter with a ratified review process
Phase 2 turns TLDMinter on — the DAO flips executionEnabled — and adds no contract changes. What it ratifies is the off-chain review process that makes execution safe to enable:
-
A requirements document — deprecation policy, organizational capacity, and successor process — drafted by the proposing team (steg) and shaped through governance dialogue.
-
Archival tooling — fetches each claimant’s policy from the committed
policy=URL at claim time and mirrors it to GitHub, so the document behind the on-chainpolicy_hashstays reproducible years later (guards against bitrot) -
A claims-review process — during the 7-day veto window, a designated reviewer reads the claimant’s policy against the ratified requirements and either files a veto or lets the claim pass. Reviewer identity is an open question for governance dialogue.
Audit scope for Phase 2 is effectively zero — the contract ships and is audited in Phase 1.
Forward-compatibility: Node Metadata Standard
In phase 2, we’re proposing forward-compatibility with the Node Metadata Standard (NMS, ENSIP-64 draft) — optional, not required.
The workflow has two documents: the requirements doc the DAO ratifies, and the policy doc each claimant publishes against it.
Phase 2 ships the requirements in two mirrored forms — the canonical Markdown spec (what the DAO ratifies) and an accompanying JSON Schema.
A claimant adopting the schema declares class=Org and schema=<url> on their operator ENS name; the DNS-committed URL points at a JSON file that validates against it. A claimant who prefers Markdown ships Markdown and goes through the same review against the same requirements — nothing about the mechanism changes for them.