[Temp Check] Authorize TLDMinter as Root Controller

[estmcmxci]

@nick.eth

One potential method would be to lay out the requirements for deprecation policy etc in documentation, and require that the gTLD claiming their name publish a compliant policy, posting its URL and content hash in the DNS record they use to claim the name. It’d be useful if there were technical measures in place to fetch and archive such policies to Github to guard against bitrot.

Great feedback, thanks!

—

Here’s the approach I’m currently contemplating — continuing with Phase 1 approach previously mentioned with a few contract deltas:

• authorize TLDMinter with the TLD allowlist but with execute() gated by an executionEnabled flag (off at deploy, flippable by DAO at Phase 2 ratification)
• add a single field to MintRequest (bytes32 policyHash)
• extend the existing _ens.nic.{tld} TXT record to also carry policy=<url> and policy_hash=0x<hex> strings
• emit a PolicySubmitted event so off-chain tooling can fetch and GitHub-archive the policy at claim time.

Everything else (DNSSEC verification, veto, rate limit, pause, allowlist, SC sunset) stays the same.

This addresses your suggestion end to end — social enforcement stays the mechanism, and the archival tooling makes the policies durable for review and ongoing checks.

Note that Phase 1 ratification implicitly endorses the Phase 2 mechanism described below — the contract being deployed assumes this shape.

We’re flagging that explicitly so Phase 1 is voted on with full context.

—

For Phase 2, we’d introduce a new direction that follows the social enforcement pattern:

• A requirements document for deprecation policy, organizational capacity, and successor process — drafted by the proposing team (steg.eth) and shaped through governance dialogue.
• Archival tooling that fetches the claimant’s policy from the committed URL at claim time and mirrors it to GitHub, so the document referenced by the hash can be reproduced years later.
• Assignment of a claims-review process. A designated reviewer reads the claimant’s policy against the ratified requirements during the veto window. Reviewer identity is an open question.

Audit scope for Phase 2 itself is effectively zero — the contract changes ship and get audited in Phase 1, not here.

—

I am also suggesting forward-compatibility with the Node Metadata Standard.

NMS allows a structured representation alongside the requirements doc and the claimant’s policy — the half of the workflow that benefits from being machine-readable.

Phase 2 can ship the requirements in two forms: the canonical Markdown spec (what the DAO ratifies) and an accompanying JSON Schema that mirrors it.

The schema describes a single-level object of string-typed records, so the requirements should be authored as flat fields — policy-url, policy-hash, notice-period, successor-process, operator-identity fields, operational-capacity fields, DNSSEC linkage fields — which keeps Markdown and schema in lockstep without re-litigating criteria.

How it would work

A claimant adopting the schema declares class=Org and schema=<https://…|ipfs://…> on their operator ENS name; the DNS-committed URL points at a JSON file validating against it.

• A claimant’s policy can be a JSON document that validates against that schema. The URL and content hash in the DNS record point at the JSON file. Reviewers grade structured fields against the ratified criteria; “compliant” becomes mechanically checkable for the obvious failure modes.
• A claimant who prefers Markdown ships Markdown and goes through the same review against the same requirements. Nothing about the mechanism changes for them.

What this gets us even when it’s optional

• Compliance becomes mechanically checkable for the obvious failure modes. Missing required fields, malformed dates, broken URI hashes, contradictory linkage to the DNS record — caught before a human reviewer ever opens the document. Reviewers grade quality against the published criteria, not “is everything present.”
• Indexer / dashboard surface for compliance status. Useful well beyond TLDMinter — anyone tracking gTLD operator hygiene gets a queryable signal for free.

—

Happy to continue shaping the contract spec in the open, but I think we’ve gathered enough detail and honed in on a direction that warrants moving to the next step in the process.

In a few days, I will update the original Temp Check with the Phase 1 contract deltas and the Phase 2 process described above.