[Temp Check] Authorize TLDMinter as Root Controller

[steg]

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 via execute. 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:

1. DNS registry operator publishes an a=0x... TXT record at _ens.nic.{tld},
2. Claim is submitted with DNSSEC proofs to TLDMinter,
3. Contract checks the allowlist and verifies the DNSSEC proof chain,
4. 7-day minimum delay — DAO/Security Council can veto before execution,
5. 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 assertions
• test_fullClaimLifecycle() — submit claim, wait 7 days, execute
• test_daoVetoBlocksClaim() — DAO vetoes, execute reverts
• test_securityCouncilVetoBlocksClaim() — SC vetoes, execute reverts
• test_cannotExecuteBeforeWindowExpires() — premature execution reverts

---

Decisions in this Temp Check

1. Do you support the single-proposal structure? TLDMinter pre-deployed via EOA, proposal authorizes it and seeds the full allowlist in one vote.
2. 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.
3. 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:

1. Finalize audit scope and assign firm.
2. Prep the executable proposal with audited contract address.
3. 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.

[liubenben]

The core concept is highly commendable. It establishes a much-needed separation of concerns, empowering TLD operators with autonomy to manage their namespaces while allowing the DAO to focus on protocol standards. Automating this process effectively prevents the inevitable “voting bloat” from manually onboarding hundreds of TLDs.

However, mapping massive global DNS resources to the ENS Root requires patience to ensure secure and continuous operation. Granting Root Controller privileges is highly sensitive. This brings up a practical question: do we have concrete data on how many of these 1,166 gTLD operators are actively interested in integrating right now? Maybe starting with a smaller pilot batch of interested operators allows us to battle-test the contract safely.

[nick.eth]

While I’m broadly supportive of automating the claim process, I don’t really understand the motivation here. We’ve had a few inquiries from TLDs in the past, and all have been willing to make the effort to do a DAO proposal (with our facilitation). We haven’t encountered TLDs that want this integration but find that to be too large a burden to bear, particularly given that any would-be integrator needs to implement bespoke contracts to allow 2LDs under their TLD to be claimed.

Further, my worry is that by making this easy, we will end up with more and more TLDs switching to bespoke integrations that only work using their custom interface, resulting in fewer DNS names being meaningfully usable by end-users. We’ve already seen this with TLDs where the owner has deployed a custom implementation that then becomes moribund and renders that TLD unusable.

[estmcmxci]

Responding OBO @steg:

@liubenben

do we have concrete data on how many of these 1,166 gTLD operators are actively interested in integrating right now?

I haven’t seen concrete demand numbers yet. But I don’t think current demand should determine whether we solve for a structurally non-atomic TLD claiming process.

—

@liubenben

Maybe starting with a smaller pilot batch of interested operators allows us to battle-test the contract safely.

This sounds reasonable, but it’s too defensive as a default posture. We should use our resources to proactively onboard TLD operators, not wait for inbound requests.

In parallel, we should actively educate operators on why claiming their ENS TLD node matters and what a healthy implementation path looks like.

With the ongoing ICANN gTLD application round, this is exactly the moment to move from ad hoc per-TLD governance to a scalable, policy-bounded onboarding path.

—

@nick.eth

Further, my worry is that by making this easy, we will end up with more and more TLDs switching to bespoke integrations that only work using their custom interface, resulting in fewer DNS names being meaningfully usable by end-users. We’ve already seen this with TLDs where the owner has deployed a custom implementation that then becomes moribund and renders that TLD unusable.

This is great feedback, thank you.

Let’s distinguish the two failure modes and reconsider our approach:

1. Fragmentation from bespoke integrations.
2. Dereliction from inactive/moribund operators.

Both can be addressed programmatically via enforcement at the claim manifest, but sequencing matters.

Passing the Temp Check as-written would authorize TLDMinter before any such enforcement exists, which would admit exactly the kind of bespoke claims you’re describing — and once admitted, they’re effectively permanent.

So we’d want to structure this as a two-phase rollout rather than the single switch-flip originally proposed:

• Phase 1 — Authorize TLDMinter as a Root controller and seed the 1,166-TLD allowlist, but deploy with claim execution gated off at launch. No TLD finalizes ownership transfer until Phase 2 turns it on.
• Phase 2 — Manifest design and claim activation. Ship an approved implementation standard, enforced via the claim manifest, that addresses both fragmentation and dereliction before any claim can finalize; then flip claimsLive in a single executable.

Fragmentation is addressed at the moment of claim (who can own a claimed TLD); dereliction is addressed across the lifetime of a TLD (what happens when operators go silent).

Phase 2 carries a real tradeoff between enforcement strength and claimant sovereignty: any mechanism strong enough to prevent bespoke fragmentation and operator dereliction introduces some concentration of ongoing authority, and loosening it in either direction has costs.

We have a point of view on where that line should sit and will present it with the rescoped proposal.

[nick.eth]

This is an interesting idea. It does tread a fine line, however, as we still maintain the official position that DNS TLD owners own their TLDs in ENS too - but here we’d be providing a mechanism that they can only use in a limited fashion.

Perhaps a more defensible option would be to allow TLD owners to claim TLDs, but only after they demonstrate a reasonable (multi-year) deprecation policy for their implementation, and ensure it’s administered by an organisation with the resources to maintain the implementation independently if need be.

[estmcmxci]

@nick.eth

Perhaps a more defensible option would be to allow TLD owners to claim TLDs, but only after they demonstrate a reasonable (multi-year) deprecation policy for their implementation, and ensure it’s administered by an organisation with the resources to maintain the implementation independently if need be.

Agree that this approach offers stronger post-claim durability guarantees and is more rigorous than originally proposed—we’ve thought through the design in detail and are seeking feedback on our rationale before committing anything to code.

What we’ve scoped

We’ve worked through what “reasonable multi-year deprecation policy” and “organization with resources to maintain the implementation independently” would actually mean in operational terms, anchored to what ICANN, Mozilla, and ccTLD redelegation precedents have converged on for analogous registry wind-downs.

The deprecation policy shape is a commitment on four fronts:

• Notice and timeline
• Successor
• User migration
• Governance

The organizational-capacity bar is an argument on four fronts:

• Funding and runway
• Operational posture
• Identity and governance
• Track record and standing

Addressing social conventions programmatically

Demonstrating commitment to a deprecation policy and arguing for organizational capacity has historically been tied to social convention. With this design, we wanted to see how much of that social convention can be addressed programmatically — moving what’s traditionally reviewer-verified prose into contract-verified primitives.

Our rescoped proposal will introduce a set of on-chain policy primitives that gate claim submission on verifiable commitments. The claimant’s registrar must expose specific interfaces — announcement procedures, successor-authentication methods, user exit rights, audit registries, and others — that the contract checks at claim time.

Most deprecation-policy commitments can be enforced this way: rejected at the gate before any review window opens, reducing load on manual review.

Organizational capacity, by contrast, is harder to verify directly. Lighthouse Labs’ Node Metadata Standard offers a partial path — structured, typed metadata attached to ENS names lets claimants publish machine-readable disclosures of entity, jurisdiction, maintainers, and endorser attestations.

We’re treating it as load-bearing for capacity verification: if it reaches Final status, several capacity fronts become contract-gated rather than reviewer-verified.

Ask

Read the Research Document, comment on the reasoning where you disagree, and push back on specific design choices you think are wrong.

We want delegate alignment on the direction before we commit additional engineering work — both on the contract scope (the primitives introduced above) and on the review infrastructure.

Feedback in this thread or as comments on the doc both work.

[nick.eth]

@estmcmxci

Demonstrating commitment to a deprecation policy and arguing for organizational capacity has historically been tied to social convention. With this design, we wanted to see how much of that social convention can be addressed programmatically — moving what’s traditionally reviewer-verified prose into contract-verified primitives.

Our rescoped proposal will introduce a set of on-chain policy primitives that gate claim submission on verifiable commitments. The claimant’s registrar must expose specific interfaces — announcement procedures, successor-authentication methods, user exit rights, audit registries, and others — that the contract checks at claim time.

Before you get too deep on this, I’d suggest considering a more socially grounded approach that is less engineering intensive. Broadly speaking, we can expect gTLD owners to be stable organisations with good organisational controls and compliance postures. While programmatically enforced compliance might be necessary if this system were open to all comers - and as an engineer I certainly understand the attractiveness of it - in this instance I think it may be significantly more straightforward and pragmatic to enforce this socially.

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.

[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.

[Arnold]

@nick.eth

It’d be useful if there were technical measures in place to fetch and archive such policies to Github to guard against bitrot.

@estmcmxci

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

Thanks for exploring the standard @estmcmxci. This should be possible with what we have been developing.

While I am not familiar with the requirements of this project, I’m confident we can express all the required properties in a purpose built schema and store the relevant details directly on ENS avoiding the need for Github. We’ve been able to write non-trivial claims for < $1 which also provide cryptographic pathways for verification downstream. See: Txn.

If this moves along happy to assist/collaborate.

[steg]

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-chain policy_hash stays 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.