What Is OAN?

OAN, the OpenAgenet Network, is infrastructure for making agent resources discoverable and verifiable before they are used. It is built for an ecosystem where resources may be published by many organizations, exposed by different infrastructure nodes, discovered by agents or humans, and invoked through many different native protocols.

The simplest definition is:

OAN is a governed identity, publication, and Discovery layer for agent resources.

It gives resources portable did:oan identity, lets authorized infrastructure nodes register and expose those resources, lets Root verify and publish accepted package versions, and lets Discovery return candidates that can be checked before invocation.

OAN publication flow

A Resource, Not Only an Agent

Many agent-infrastructure projects start from an “agent” as the primary object. OAN starts from a broader object: the discoverable resource. A resource can be an Agent Service, a Skill, an MCP Server, or a Tool/API endpoint. Future resource types such as prompts, workflows, datasets, model endpoints, or domain packages can fit the same pattern if they need identity, publication, discovery, and verification.

This resource-first model is important. A developer may not only need to find another autonomous agent. They may need a skill package, an MCP server exposing tools, an API suitable for an agent workflow, or a callable service with its own protocol. OAN lets these different forms share a common trust path without forcing all of them into one runtime model.

The Trust Path

OAN can be read as a sequence of trust-preserving steps.

First, a resource is represented by did:oan identity material. The DID Document can carry verification methods, services, protocol bindings, resource metadata, capability tags, authorized domains, and endpoint or artifact references.

Second, a Registrar helps onboard the resource. It checks shape, metadata, DID control, domains, hashes, and package fields, then submits Root-bound material through an authorized upstream path.

Third, Root verifies the submission. Root checks Registrar authority, DID structure, hashes, policy constraints, authorized domains, freshness, and package consistency. If the material passes, Root accepts a version and creates proof.

Fourth, the accepted package is distributed and synchronized. CDN serves Root-verified package material. Discovery nodes fetch, verify, filter by their own authorization scope, index, and return candidates.

Finally, a client verifies the candidate before calling the native protocol.

The Five Commitments

The white paper’s design can be summarized in five commitments.

Identity before interaction: a resource should have portable identity before another agent or user connects to it.

Lifecycle before directory: Discovery should expose current Root-accepted resources, not stale or revoked listings.

Authorization before exposure: infrastructure nodes should expose only the resource domains they are authorized to serve.

Verification before invocation: a client should check DID material, package hashes, Root proof, lifecycle state, and endpoint binding before use.

Compatibility before replacement: OAN should complement MCP, A2A, ANP-like protocols, APIs, DID/VC methods, and domain protocols instead of replacing them.

Where OAN Fits

OAN sits between raw resource discovery and native protocol invocation. A marketplace may provide a user experience. A search engine may improve retrieval. MCP may define tool interaction. A2A may define agent-to-agent communication. Enterprise systems may define internal approval and access controls. OAN contributes the missing trust envelope: governed identity, accepted publication, authorized discovery, and reusable verification.

This is why OAN is useful for both humans and agents. A human user can inspect evidence before choosing a resource. An SDK can verify evidence automatically. An agent can use Discovery as a trusted candidate source without assuming that every matching endpoint is safe.

The Architectural Bet

OAN makes one architectural bet: the future Agent Internet will not be governed by one runtime, one marketplace, or one vendor directory. Useful resources will live across many protocols and organizational boundaries. The stable layer must therefore be the trust envelope around resources, not the execution format inside every resource.

That is why OAN keeps invocation protocol-neutral. The network can register a Skill, MCP Server, Tool/API, or Agent Service without forcing all of them to speak a single OAN runtime protocol. The common layer is identity, package proof, lifecycle, authorized-domain scope, Discovery evidence, and verification. Native protocols remain where actual interaction happens.

What Makes OAN More Than Metadata

It is easy to confuse OAN with a metadata catalog because the website and Discovery pages show descriptions, tags, and endpoints. The deeper point is that those fields are tied to an evidence path. Metadata is checked during onboarding, accepted by Root as part of package facts, distributed with hashes, indexed by authorized Discovery nodes, and verified by clients.

This evidence path is the difference between “someone wrote that this endpoint is useful” and “this resource version has a DID subject, accepted package material, and proof that can be checked before use.” That difference becomes decisive when agents begin selecting and invoking resources automatically.

What OAN Produces

OAN does not produce a single magic certificate that should be blindly trusted. It produces a chain of evidence:

a DID subject and DID Document;
resource metadata and package material;
hashes binding DID, metadata, and package content;
Root proof of accepted publication;
lifecycle and status signals;
Discovery response material;
authorized-domain scope;
links or endpoints for native use.

The value is that these pieces can be checked independently.