Trust and Governance
OAN is open infrastructure, but open does not mean uncontrolled. A node should not become trusted merely because it has an endpoint. A Registrar should not be able to onboard every domain just because it is reachable. A Discovery node should not expose resources outside the scope it is authorized to serve. Governance is how OAN makes infrastructure authority explicit, current, scoped, and revocable.
This section explains the public trust model. It does not document private operational secrets or official deployment runbooks. Instead, it explains what users, applicants, operators, and reviewers need to understand: who may operate infrastructure, how authority is scoped, how Root enforces that authority, how Trust Indexer supports current state, and why revocation matters.
The public model is intentionally more important than the current deployment details. The official deployment may move servers, switch domains, rebuild indexes, or upgrade contracts. The trust idea should remain recognizable: governance records infrastructure lifecycle decisions, Root enforces protocol authorization, resources are accepted as versioned packages, and Discovery exposes only candidates it is authorized to serve.
The Governance Idea
OAN separates resource trust from infrastructure authority. A resource becomes trusted for publication when Root accepts a package version. A node becomes authorized when governance and Root-recognized authorization say the node may perform a role within a scope.
These two ideas interact but are not identical. A Registrar can help a resource enter the system only if the Registrar is authorized for the relevant domains. A Discovery node can expose a resource only if the node’s scope covers the resource’s domains. Root uses governance-derived state to enforce these checks at runtime.
Evidence Layers
| Layer | What it answers | What it does not answer |
|---|---|---|
| DID identity | Who is the node or resource subject? | Whether the subject is currently authorized. |
| Governance state | Has the infrastructure role been approved, suspended, recovered, or revoked? | Whether a specific resource package is correct. |
| Root authorization | What role and domains does Root recognize for the node? | Whether a future governance change will keep it valid. |
| ResourcePackage | What resource version did Root accept? | Whether the Registrar is permanently trusted. |
| Discovery response | What verified candidates did this Discovery node return? | Whether native invocation is safe by itself. |
OAN’s strength comes from keeping these layers separate and checkable.
The most subtle layer is effective infrastructure authorization. Governance state says whether a node is currently approved under the governance process. Root-recognized authorization material says whether that node has a valid protocol-level authorization to act. OAN should require both for trust-sensitive infrastructure behavior. One without the other is not enough.
Why Governance Matters for Users
For ordinary users, governance may sound distant. It is not. It affects which Registrar can register a resource, which Discovery node can expose it, whether a node’s old authority still counts, and whether a resource appears in a domain-specific Discovery result.
Without governance, anyone can run a website that claims to be an OAN node. With governance, users can ask whether the node identity, role, scope, and current status are recognized. That makes third-party participation possible without asking every user to personally trust every operator.
This is why governance is user-facing even when ordinary users never vote. It shapes whether public results are meaningful. A user who sees “official Discovery” or “recognized third-party Discovery” should be able to understand that the label is backed by node identity, role, scope, and current status rather than only by branding.
Why Governance Matters for Operators
For node operators, governance defines the path from application to authority. A prospective Registrar or Discovery operator should prepare DID identity, endpoint material, role request, domain scope, operational information, and evidence that the node can serve its role. Approval is not only a social listing; it becomes current authorization that Root and clients can use.
Operators should expect authority to be scoped and revocable. A node may be authorized for one domain set and not another. A node may be suspended or revoked if it no longer meets requirements. The current state matters more than a historical announcement.
Operators should also expect evidence requirements. A node application is not only a name and URL. It should include DID identity, role request, endpoints, domain scope, operational contact, and enough information for reviewers to understand whether the requested authority is appropriate.
Root and Trust Indexer
Root is the service that enforces infrastructure authority when handling submissions, publication, and Discovery distribution. Trust Indexer is the operational read side that projects governance events into state Root can use. This division keeps governance events auditable while letting Root make fast runtime decisions.
The public lesson is simple: Root should not depend forever on old static configuration when current governance state is available. Effective authorization should be current, indexed, and enforced.
For public explanation, it is useful to compare the model to a flight control tower rather than a phone book. A phone book lists names. OAN governance changes who is cleared to perform infrastructure roles, under what scope, and whether that clearance is still current.