Everything you need to register agents, issue credentials, verify identity, and integrate Observer Protocol into your stack. Open protocol, MIT licensed, self-hostable.
Get started with Observer Protocol. Full developer documentation, SDK reference, and working examples on GitHub.
offline.didDocumentPath at a local copy and it makes no network call at all. The hosted verifier is a separate deployment running a different engine version; see the SDK section.
All non-DID endpoints use the /api/v1/ prefix. DID document paths follow the W3C did:web resolution standard and are documented separately below. Full interactive documentation available via Swagger UI.
Verification, offline, from npm. Node 18+, MIT license. This is the package the rail
adapters depend on and the one under active release.
Offline verification is not an SDK detail. It is the protocol's central affordance and it has
its own page: verify a record, with a
runnable transcript, a field-by-field account of what each element proves and what it does not,
and two artifacts published specifically because they must fail.
/api/v1/resolve/{did} — sitting directly beside a
copy-pasteable curl command. That is the one that would have cost a developer
an afternoon before they concluded the fault was theirs.
verify.observerprotocol.org is open: its /version reports
verification.open: true at 60 requests per caller per minute, and an
unauthenticated POST /v1/verify returns 200 with a signed result.
engine.running: "0.3.3"; the package above is 1.0.0-rc.6. They
agreed on every artifact tested, including exact reason strings, but that is agreement on
samples rather than a shared code path. Tracked as
op-verify-service#1;
this notice comes off when it lands. Where they disagree, the published package is
authoritative.
Observer Protocol is governed by open specifications maintained on GitHub. AIP v0.9 was ratified on 25 July 2026 and is tagged v0.9 in the specification repository, with the review record in its pull request. It is additive over v0.6: an implementation conforming to v0.6 remains conforming.
The canonical specification for OP: identity model, event schema, verification logic, VAC structure, and API reference. Version controlled on GitHub.
AIP governs how agents interact: delegation credentials, magic-link authorization, authorization proofs, chargeback prevention, and type registry.
Machine-readable API specification in OpenAPI 3.0 format. Use to generate client SDKs, validate requests, or power your own Swagger UI instance.
The permanent citable reference for grants, investor materials, developer documentation, and academic reference. Updated April 2026.
X402PaymentCredential, Delegation v2 (three-level authorization), Settlement Receipt v1 (chargeback prevention). All $id URLs resolve.
On-chain agent identity and ERC-8004 registry integration. Indexers for Base and TRON mainnet, cross-registry DID resolution, registration file pinning, and OP validator on Base.
End-to-end demo: agent purchase, magic-link authorization, authorization proof, cryptographic dispute prevention. For AI infrastructure companies.
Observer Protocol uses the W3C did:web method. DID Documents are served at standard URL patterns, not through the API. This is intentional: DID resolution is a protocol-level concern, not an API endpoint.
The W3C did:web method transforms a DID into an HTTPS URL by replacing colons with forward slashes. Anyone with HTTPS access can resolve an OP DID without querying the OP API. This is what makes agent identity truly portable.
The domain mismatch rule: an agent's DID domain must match its organization's DID domain. A mismatch is treated as a fraud signal by AIP-compliant implementations.
| DID Component | Resolves To |
|---|---|
| did:web:example.com | https://example.com/.well-known/did.json |
| did:web:example.com:agents:abc | https://example.com/agents/abc/did.json |
| did:web:example.com:op-identity | https://example.com/op-identity/did.json |
The derivation is deterministic and you can reproduce it without us, which is the point: an agent's identifier is a function of its key, not a record we assign. Ed25519 shown here because it is the same curve Solana uses, so a Solana keypair derives an agent DID with no extra material.
Written down here because the answer is stronger recorded than reconstructed under questioning, and because two of the three are proposals rather than shipped behaviour. Which is which is stated.
ClearingSystemCode:PaymentProduct for fiat, CAIP-2 for chains. One field, one parser, both worlds: USABA:ACH.CCD, GBDSC:FPS, SGIBG:PAYNOW, eip155:8453.
The left half resolves against the ISO 20022 external clearing system code set, which appears in every pain.001, so it is not a vocabulary we invent or maintain. The right half distinguishes products sharing a clearing system, which is a real collision rather than a hypothetical one: ACH credit and Fedwire are different products on one system. It mirrors CAIP-2's namespace:reference grammar, so eip155:8453 parses under it unchanged and a fiat rail does not force a parallel identifier space.
What actually ships today: rail is a free-text string. The published delegation/v2.6 schema documents it that way, with examples 'usdt-trc20' and 'lightning', and no issued credential carries the grammar above. Schema URLs are immutable, so adopting it means a new schema version rather than an edit. Treat this as what the field is becoming, not what it contains.
A fiat reference field carries 31 characters or fewer, so a downstream party may hold only a pointer. Something has to serve what it points at, and hosting that at a vendor endpoint is uncomfortable: it puts us in the payment path and sits badly beside a claim that verification needs nothing from us.
Resolution through Observer Protocol infrastructure is defensible as a protocol layer rather than a vendor inserting itself, and only while all three of these hold:
The three conditions are the decision. A resolver that quietly stopped satisfying any one of them would not be a degraded version of this; it would be the thing this decision was taken to avoid.
A decision attestation records what was decided, under which policy version and content hash, over which inputs (as a digest), by which party, with the decider kept separate from the mandate issuer, and at which assurance level (self-declared versus independently-observed).
There is no published schema for it, and no verifier accepts one. The related PolicyEvaluationCredential has the same gap and it is not cosmetic: AIP v0.8 defines that type and requires schema validation when verifying it, without ever assigning it a schema URL. The published engine has no dispatch on credential type at all, and the hosted service accepts only {agentDid, mandate}. Every evaluation credential we have issued fails our own verifier for this reason, while its signature verifies correctly under canonical W3C Data Integrity tooling.
We are not documenting a schema we have not published, and not shipping a verifier that reports success over a check it did not perform. The verification page states the same thing, and the affected artifacts stay published rather than being withdrawn to tidy the picture.