Registrar, Root, and Discovery

OAN separates onboarding, acceptance, and search into different node roles. Registrar helps resources enter the network. Root decides what is accepted and publishes evidence. Discovery exposes verified candidates for users, SDKs, and agents. The roles work together, but none of them should be mistaken for the whole system.

This role separation is one of the strongest practical safeguards in OAN. A Registrar cannot make an invalid resource trusted merely by accepting a form submission. A Discovery node cannot turn unaccepted material into a trusted result by ranking it highly. Root should not become a business-traffic gateway or a universal search engine. Each node does its job and leaves evidence for the next layer.

The Three Roles

The system is designed so that a failure or compromise in one role has a bounded effect. A malicious or mistaken Registrar should not be able to bypass Root. A Discovery node with poor ranking should not invalidate the underlying package proof. A resource provider with a valid endpoint should not gain visibility outside the authorized-domain rules.

Registrar: The Onboarding Gate

Registrar is the first infrastructure node most resource publishers touch. It accepts resource registration material, checks that the structure is coherent, verifies DID-control evidence where required, validates resource type and metadata, checks authorized-domain scope, and submits Root-bound material through a trusted upstream path.

Registrar can also improve user experience. It can help normalize metadata, suggest capability tags, show validation errors, and issue holder-facing registration evidence to the resource publisher. But that local registration evidence is not the same thing as Root acceptance. The ordinary resource registration credential belongs to the Registrar and the resource holder; it is not something Root needs to receive for every resource as a governance object.

The most important Registrar rule is scope: a Registrar may onboard only what its own authorization covers. If a Registrar is authorized for a subset of domains, resource authorizedDomains must stay within that subset. If it has wildcard scope, it may onboard resources across all domains, subject to the rest of the validation rules.

Root: The Publication Trust Anchor

Root is the node that turns a valid upstream submission into an accepted publication unit. It verifies Registrar authorization, request signatures, DID structure, resource type consistency, hashes, freshness, subject-control evidence, authorized-domain coverage, and package fields. If a submission passes, Root records the accepted facts, creates Root proof, and enqueues publication work.

Root is also where governance-derived infrastructure state becomes operational. Registrar and Discovery authorization is not just a configuration comment. Root needs to know which infrastructure identities are authorized, suspended, recovered, revoked, or scoped to specific domains. In the current architecture, Root uses a Trust Indexer-backed authorization cache for this read model, so chain-governance state can be reflected in service behavior.

Root is intentionally not a ranking engine. It does not decide which resource is best for a user’s query. It also should not become the runtime path for every resource call. Its value is to provide acceptance and evidence so downstream nodes and clients can verify what they use.

Discovery: The Verified Read Side

Discovery is the read-optimized side of the network. It synchronizes packages that Root has accepted and published, verifies package hashes and Root proof, indexes DID Document metadata and package facts, applies its own authorized-domain scope, and returns signed responses to queries.

Discovery can support keyword search, structured filters, capability tags, semantic search, or ranking strategies. Those retrieval choices are important, but they do not change the trust semantics. A Discovery node may improve recall and precision, but it must still return candidates whose evidence can be traced back to Root-accepted material. In human terms, Discovery should say: “Here are candidates and here is the evidence,” not “trust me because I found them.”

Why Publication Is Often Asynchronous

After Root accepts a resource, the resource may not appear in Discovery instantly. Publication can involve package storage, CDN synchronization, downstream notification, Discovery fetching, verification, indexing, and query cache refresh. OAN treats this as a normal lifecycle sequence rather than pretending everything is a single transaction.

That asynchronous design is useful at scale. Root can process submissions and enqueue publication work. CDN can serve verified package material. Discovery nodes can pull and verify packages independently. Clients can distinguish “accepted by Root” from “visible in Discovery.” Good user interfaces should present that distinction clearly.

Operational Consequences Of Role Separation

The role split also gives operators better failure diagnosis. If a resource fails before Root, the problem may be Registrar validation, subject-control evidence, domain scope, or request signing. If Root accepts but Discovery does not show the resource, the problem is likely publication, notification, Discovery synchronization, domain filtering, or indexing. If Discovery returns a result but a client rejects it, the issue is likely proof, hash, lifecycle, endpoint binding, or local policy.

This is not only an internal operations concern. Public user interfaces should reflect the same model. A user should not see one generic “failed” state when the actual stage is known. Clear stage boundaries make OAN easier to trust.

Third-Party Nodes Need These Boundaries

Third-party operation is only realistic if every role has limited authority. A domain-specific Registrar can be useful without being able to register every resource. A specialized Discovery node can serve a community without overriding Root. A Root service can enforce publication facts without becoming a universal marketplace.

This lets the ecosystem grow by specialization instead of centralization. Operators can take responsibility for one role and one scope, while users can still verify the resulting evidence chain.

What Each Role Should Not Do

Registrar should not override governance scope. Root should not accept a submission merely because a Registrar says it is fine. Discovery should not expose resources outside its authorized domains. None of the infrastructure nodes should hide missing proof behind a friendly result card. And consumers should not treat a Discovery response as the final step before invocation without verifying the returned evidence.

Those negative boundaries may sound strict, but they are what make third-party operation possible. If node operators can join the ecosystem only by following clear authority boundaries, users can rely on evidence instead of personal trust in every operator.

Further Reading

• OAN architecture overview
• OAN yellow paper
• IETF draft: OAN resource identity and discovery