For Node Operators

Operating an OAN node is different from publishing a resource. A node participates in infrastructure. It may onboard resources, expose Discovery results, or support future governed roles. That means it needs identity, scope, governance recognition, service reliability, and ongoing status management.

A node is not trusted just because it is running. It becomes useful when its role, DID identity, authorized domains, endpoint, status, and Root-recognized authorization fit the OAN trust model.

This distinction should shape the operator mindset from the beginning. Deploying binaries is the easy part. Becoming part of a governed trust path requires identity, review, scope, observability, and current authorization.

Governance boundary

What Operators Prepare

Prospective node operators should prepare:

  • node DID identity and key custody plan;
  • requested role, such as Registrar or Discovery;
  • public endpoint information;
  • requested authorized domains;
  • operator description and contact process;
  • reliability expectations;
  • status and monitoring approach;
  • lifecycle change process;
  • compatibility with OAN protocol routes;
  • evidence needed for governance review.

The exact trial-network process may evolve, but these materials are the practical core.

Operators should also prepare for change. Domains may be updated, endpoints may move, software may be upgraded, and keys may rotate. A serious operator should have a process for making those changes visible without surprising Root, Discovery peers, SDK users, or public status pages.

Registrar Operator Focus

A Registrar operator needs to validate resource submissions within its authorized scope. That includes resource type, DID material, domains, tags, package fields, hashes, and subject-control evidence. It should reject resources outside scope and forward Root-bound submissions correctly.

Registrar operation is not just hosting a form. It is an admission responsibility.

A good Registrar also provides helpful user feedback. It should reject invalid submissions clearly, distinguish user-fixable metadata problems from governance or Root rejection, and avoid accepting resources that it cannot lawfully or technically onboard under its domain scope.

Discovery Operator Focus

A Discovery operator needs to synchronize Root-accepted packages, verify proof and hashes, enforce authorized-domain scope, build indexes, answer queries, and sign response material. If semantic Discovery is enabled, the operator must also maintain derived indexes without letting them become a separate source of truth.

Discovery operation is not just running a search engine. It is operating a verified read side.

If semantic Discovery is enabled, the operator must maintain an additional derived state. Embeddings, ranking indexes, and explanation caches should be rebuildable from verified package data. They should not become a private truth source that outranks Root proof or lifecycle state.

Recognition, Authorization, Operation

Operators should distinguish:

Concept Meaning
Application The operator submits intent and material for review.
Recognition The ecosystem or repository records the application or approved participation path.
Governance authorization The role and scope become part of governed state.
Root-recognized operation Root and services enforce the current authorization.
Public operation Users can reach the endpoint and verify node behavior.

Skipping these distinctions creates confusion. A GitHub entry is not the same as runtime authorization. A running endpoint is not the same as current governance state.

The distinctions also help public communication. An applicant can be visible before activation. An authorized node can be temporarily unreachable. A revoked node can still have a live endpoint. Users need precise labels to understand what is happening.

Ongoing Responsibility

Operators must keep endpoints healthy, keys protected, domain scope accurate, software updated, logs usable, and status clear. If they change domains, endpoints, or identity, the lifecycle process should reflect that. If they stop operating, status should not remain ambiguous.

OAN can only grow as open infrastructure if node operation is treated as a responsibility, not a badge.

For early operators, the most valuable contribution may be operational feedback: which application fields were unclear, which status endpoints were missing, which domain-scope errors were hard to diagnose, and which SDK behaviors made integration harder than necessary.

Further Reading