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.
Endpoint paths are literal, and the /api/v1/ prefix is not general: six of the twenty-nine endpoints listed below carry it and twenty-three are served at the bare path shown. The two are not interchangeable. Measured 13 August 2026: /api/v1/health returns 200 and /health returns 404, while /observer/trends returns 200 and /api/v1/observer/trends returns 404. 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.
1.0.0-rc.10
and re-measured the same day against 1.0.0-rc.12,
which is the version this page now documents. Both runs produced identical results.
validateStructure is synchronous and performs no fetch. It checks the shape
the engine already knows, and it checks that credentialSchema.id appears in
your schemaAllowlist; it does not retrieve the document at that URL. A
credential declaring delegation/v2.7.json while omitting
credentialStatus, which is in that schema's required list,
returns { ok: true }. Pinning a schema version pins a string, not the
constraints the version exists to impose.
[revocation] status could not be established: unreachable (fetch failed) and no
cached copy exists. After one successful fetch, the same unreachable list returns
allow: true, reason: 'credential verified' and
checks.revocation: 'not-revoked'. The substitution is recorded only in
notes, as served from cache aged 0.0h (limit 24h), and
checks carries no value that distinguishes a live answer from a cached one
even though it carries 'status-absent' and 'not-configured' for
other checks that did not run. The staleness limit is measured against the cached file's
own age, not against the nowMs you pass in. Read notes, not only
checks.
issuer differs from config.issuerDid is denied at the
structure gate with issuer … does not match the pinned trusted issuer
…, including when that credential is validly signed by a key its own domain
publishes and raises the mandate ceiling. The validity window and the
eddsa-jcs-2022 proof both deny as documented./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.
GET /resolve/{did} and returns a W3C DID Resolution Result; only the
path on this page was wrong, and the 404 badge beside it made an available capability look
absent for as long as the wrong path stood. The row, the curl and the live
resolver above all point at the working path now. Three of the four remain 404 and are still
badged: /vac/partners, /aip/chain/verify/{id} and
/aip/type-registry/{category} — checked at both the bare and
/api/v1/ prefixes.
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.12. Re-measured against
rc.10 on 9 August 2026: they agree on 7 of the 8 artifacts this site publishes. The eighth is
never evaluated by the hosted engine at all — it is refused at that deployment's issuer
allowlist, which does not carry the testbed issuer. So the agreement is on samples rather
than a shared code path, and it is one sample narrower than the sample set. Tracked as
op-verify-service#1;
this notice comes off when it lands. Where they disagree, the published package is
authoritative.observer.verifyAgent, observer.recordTransaction and
observer.getVAC, under the heading of this package. No observer
object was defined anywhere on this page and the package exports no such object; those
three are operations of the deprecated SDK, and two of them are HTTP calls rather than
library functions. A reader copying that block had nothing to bind observer
to. The panel now lists the entry points the installed package exports.
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 through v0.8: an implementation conforming to any of those 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 13 August 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.7 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).
Correction, 13 August 2026. This section previously read "there is no published schema for it, and no verifier accepts one." The first half is true. The second was false, and it was false in the direction that reads as modesty. The published package verifies a decision attestation, and what it establishes is narrower than the word verifier suggests, so both halves are stated here rather than one.
What it does establish. verifyDecisionAttestation, exported from @observer-protocol/policy-engine, checks an Ed25519 signature over a canonicalisation of the whole document. Measured against 1.0.0-rc.10 and re-measured against
1.0.0-rc.12, both on 13 August 2026 with identical
results: no field can be altered, added or removed without the check failing, including fields the function never reads. It also requires that the identifier the payment cites is the identifier the document carries. So a third party learns that a named key signed those exact bytes, and that nobody has changed them since. That is non-repudiation, and it is real.
And there is a document left to run it on. The function takes the attestation document and its signature as arguments and cannot go and find them: its own refusal text for the case where they are absent reads a decisionId is an identifier, not a locator. A deployment that checked an attestation on receipt and kept only the verdict would leave a determination that nobody could re-check afterwards, including us. On deployments running the determination-records path, the raw document and signature are preserved through ingestion and stored as base64 of exactly what was received, beside a documentHash that is sha256 over those bytes. A determination is independently verifiable by a party who was not there.
Two measurements, and they are not the same kind. The one you can run: verify-samples/ppp-determination-refused-outcome.json is a stored determination record published on this domain, sha256 over its stored document bytes reproduces its documentHash, and the record returns attested under the version npm install serves. The one you are taking from us: an external implementation submitted 2,000 determinations and found every stored document byte-identical to what it sent, with the stored hash matching, on both the determination-only path and the payment path, checked in full rather than sampled. That figure was measured on the payment stack and recorded here on 17 August 2026. Nothing in this repository re-derives it.
Precisely which bytes. The stored document is the wire form. The signature is checked against a JCS canonicalisation re-derived from the parsed document, so for a document whose wire form is already canonical the two are the same sequence and for one that is not they differ. What the stored bytes give a counterparty is the ability to rebuild the verifier's input, which is the property that was missing when they were not kept.
Where it does not reach. Deployments that came before the determination-records path verified an attestation once and did not keep what they verified, so their determinations cannot be rebuilt by anyone, permanently, and no version of this package changes that. Nothing published here tells you which records those are: the boundary is a property of a deployment rather than a field in an artifact. Read the paragraphs above as a statement about a determination in your hands.
What it does not establish, and you can check each of these against the package.
No schema is published for the type at any URL, so no party can validate a decision attestation against anything published, and there is nothing for a reader to point a validator at.
policyRef.hash, vocabularyRef.hash and deciderArtifactDigest.value are confirmed present and non-empty, never confirmed correct against anything. The function resolves no policy, no vocabulary, no artifact and no input set; a reference whose hash matches nothing verifies exactly as well as one whose hash matches its document.
Second correction, 17 August 2026: inputsDigest was named in that list until now and does not belong in it. The function carries the field through to its result and checks nothing about it, not even that it is there. verify-samples/ppp-determination-refused-outcome.json is published on this domain, carries no inputsDigest at all, and returns attested. So the digest of the inputs a decision ran over is the one reference in the document that a verifier does not even establish the presence of, which is a weaker statement than the one this section made about it and is the true one.
The vocabulary travels inside the signed document, so when the engine checks that outcome is a member of the declared set, both the value and the set come from the same document under the same signature.
The function takes no clock. decidedAt and resolvableUntil are carried and compared to nothing: an attestation whose resolvableUntil is in the past verifies, and so does one dated in the future.
The short form: the signature and the document's internal coherence are checked; every reference the document points at is not. A separate export, acceptDecisionAttestation, is not a verifier and must not be read as one. It takes no document and no signature, reads the assurance field alone, declines independently-observed where a deployment cannot resolve an observer, and otherwise accepts. It accepts an empty object.
The related PolicyEvaluationCredential has the schema 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.