Root Node as Trust Anchor

Root is the publication trust anchor in OAN. It verifies resource submissions, checks Registrar authority, enforces authorized-domain coverage, records accepted package versions, produces Root proof, and drives publication toward CDN and Discovery. It is the service that turns a valid submission into a verifiable OAN resource package.

Root is powerful, but its role is narrow. It is not a marketplace, search engine, resource runtime, or business traffic gateway. Its job is to make publication facts trustworthy and enforce infrastructure authority.

This narrowness is deliberate. The more Root tries to do, the harder it becomes to audit and scale. OAN keeps Root focused on acceptance and proof so Discovery, CDN, SDKs, websites, and native protocols can evolve around a stable trust anchor.

OAN publication flow

What Root Checks

When Root receives a Registrar-origin submission, it should check:

  • whether the Registrar is currently authorized;
  • whether the Registrar role and domain scope cover the resource;
  • whether the request envelope is signed and fresh;
  • whether DID syntax and DID Document structure are valid;
  • whether subject-control evidence is sufficient;
  • whether resource type and metadata are consistent;
  • whether package, metadata, and DID Document hashes match;
  • whether authorizedDomains are typed and valid;
  • whether policy constraints are satisfied.

These checks prevent “Registrar says so” from becoming enough by itself. Registrar is an authorized upstream, but Root still verifies the evidence that matters for publication.

The checks also protect honest Registrars from accidental overreach. If a Registrar is misconfigured or submits a resource outside its domain scope, Root should reject the package. That keeps the trust path consistent even when one upstream component makes a mistake.

What Root Produces

Root acceptance should produce a versioned, hash-bound ResourcePackage and Root proof. Those outputs become the evidence used by CDN, Discovery, SDKs, and clients. A Discovery node can index the package. A client can verify the proof. A website can show lifecycle status. An operator can diagnose publication state.

Root proof is therefore the bridge between governance-aware acceptance and downstream trust.

Because Root proof is versioned and hash-bound, it gives downstream systems something concrete to verify. Discovery can verify before indexing. SDKs can verify before exposing a candidate as usable. Auditors can later inspect which version was accepted and what facts were bound.

How Root Uses Governance State

Root needs a current view of infrastructure authorization. In the current design direction, on-chain or governed authorization events are projected into operational state through the Trust Indexer. Root consumes that read model and applies it when accepting Registrar submissions or coordinating Discovery visibility.

This means genesis fixtures or old local configuration should not be treated as the final authority once governance state exists. Root should know whether a node is authorized, suspended, recovered, revoked, and which domains it covers.

In practical terms, Root should fail closed when its authorization read model is unavailable or too stale for trust-sensitive decisions. Accepting a Registrar submission with unknown current governance state would weaken the model that governance is meant to provide.

Root Is Not Discovery

Root should not become the place where every query is ranked. Discovery nodes handle search, indexing, semantic matching, and signed candidate responses. Root’s role is earlier in the trust path: acceptance, proof, and distribution coordination.

Keeping Root out of ordinary query traffic helps scale and preserves a clean trust boundary. It also allows multiple Discovery nodes to serve different communities while still relying on Root-accepted package facts.

Root may expose status, package lookup, or proof-related APIs, but those are not the same as ranking search results. The searchable experience belongs in Discovery. Root’s role is to make the search corpus trustworthy.

Root Is Not Runtime Invocation

After a resource is discovered and verified, clients use the resource’s native protocol. Root does not broker every MCP call, API request, skill install, or Agent Service invocation. This avoids turning Root into a bottleneck and lets OAN stay compatible with many resource types.

This is one of the reasons OAN can scale from demos to ecosystem use. Root can remain a conservative verifier while high-volume read traffic and runtime traffic are handled by components designed for those workloads.

Further Reading