Adoption Paths
OAN adoption can begin with one useful action. You do not need to operate Root, run a local Discovery node, understand chain governance, and write an SDK integration before you see value. The system is meant to support staged adoption from lightweight use to deeper participation.
This staged path is important because OAN serves different groups. A builder wants discoverability. A user wants trustworthy candidates. An enterprise wants evidence. An operator wants a governed role. A researcher wants a system that can be evaluated.
The stages are not a ladder everyone must climb. They are entry points. A product team may start at publishing. An enterprise may start at verification. A researcher may start at evaluation. A future node operator may start with trial-network material. The common thread is that each path can grow into deeper participation without changing the core trust model.
Stage 1: Use
The simplest path is to use official Discovery. A user writes a query, inspects candidates, and learns what evidence is returned. This stage teaches the most important OAN habit: Discovery is not the end; verification comes before use.
No resource publication is required. No node operation is required. This is the easiest way for non-technical readers to understand OAN’s value.
This stage is also useful for designers and product managers. It reveals what result evidence looks like, what terms are confusing, and how much explanation users need before they feel comfortable moving from a candidate to a native protocol action.
Stage 2: Publish
The next step is publishing a resource. A builder can register an Agent Service, Skill, MCP Server, or Tool/API resource through the official Register page, SDK, or community skill. The publisher learns resource type, did:oan identity, authorized domains, capability tags, package evidence, and lifecycle.
Publishing one real resource is more useful than reading ten abstract summaries. It reveals where metadata needs to be clearer and where tooling should improve.
For a first publication, choose something narrow. A precise resource with a clear endpoint or package and obvious domains teaches the workflow better than an ambitious resource whose scope is hard to explain.
Stage 3: Integrate
Developers can integrate OAN into products through the SDK. This means using baseUrl configuration, registration helpers, Discovery queries, lifecycle checks, package lookup, and verification helpers. A product can then consume OAN candidates without turning evidence into a plain search URL.
Integration is where OAN begins to matter to agents. An agent runtime can discover resources, verify them, and then proceed through MCP, API, Skill, or Agent Service protocols.
At this stage, the main engineering risk is dropping evidence too early. If an application converts a verified candidate into only a URL, it loses much of OAN’s value. Keep proof, lifecycle, DID, package, domains, and endpoint binding in the application model.
Stage 4: Operate
Operating infrastructure is a deeper commitment. A Registrar or Discovery node needs DID identity, endpoint reliability, domain scope, governance approval, status monitoring, and compatibility with the trust model. Operators should study trial-network material before assuming that running a process is enough.
The operator path is where OAN becomes open infrastructure rather than a single official deployment.
It is also where governance becomes visible. Operators should expect to explain identity, role, domains, endpoints, monitoring, and lifecycle procedures. The point is not to make operation burdensome; it is to make delegated trust reviewable.
Stage 5: Contribute
Contributions can be code, documentation, tests, examples, diagrams, SDK improvements, community skill workflows, resource profiles, or research reviews. Some contributions are highly technical; others make adoption easier for first-time users.
The best contributions usually reduce friction while preserving the trust model. A simpler form, a clearer error message, a better domain example, or a verification helper can matter as much as a new feature.
Contributors should look for places where the same mistake repeats: confusing domains with tags, assuming Discovery means invocation, hard-coding endpoints, losing proof fields, or treating stale status as current. Removing those traps improves adoption directly.
Choosing Your First Step
If you are a builder, publish one resource. If you are a developer, run one SDK query and verify a result. If you are an enterprise reviewer, inspect the evidence chain. If you are a node operator, read the trial-network path. If you are a researcher, start with the papers and then compare them to the working implementation.
The right first step is the one that produces evidence. OAN is easiest to understand when you see the package, proof, lifecycle, and Discovery result connected end to end.