Observer Protocol is the open layer that refuses and proves. A mandate signed by the principal and out of the agent's reach. A request outside it that produces no instruction at all. A signed record of what was decided, verifiable by anyone without asking us. On any rail.
The control is designed to be the same on every one of them, and it has been demonstrated on Lightning. It has never run on a fiat rail. The register below says exactly where each one stands.
Every institution deploying agents already has two systems that look like they cover this. Neither one does, and neither can stop the other.
Your application writes down what the agent did and when. It is a record produced after the fact, by the same system that took the action, and it can be reconstructed, backfilled, or simply be wrong. It answers what happened. It cannot answer whether the thing that happened was permitted.
Your rail writes down that value moved. It is authoritative about settlement and silent about everything before it. By the time the instruction reaches the rail the decision is already made, and on the instant rails there is no state left in which it can be recalled.
Which human granted this machine the right to act, bounded how, for how long, and against which counterparties. That fact exists at the moment of delegation and nowhere afterwards. It is not in the decision log, because the log is written by the thing being constrained. It is not in the payment record, because the rail never saw it. When a supervisor asks whether an agent acted inside its authority, there is no artifact to hand them.
Two systems record two things, and neither one can stop the other. Observer Protocol records the third, and refuses before either of the other two is reached.
Three artifacts. Each one is a signed object, each one is checkable by someone who does not trust us, and the second one is the product.
A credential the human signs, not the machine. It states a ceiling, a counterparty set, a window, and whether a decision must be cited before the action is permitted. The agent holds a key that can spend inside it and no key that can widen it. Rewriting the mandate is not a permission the agent has to escalate to; it is a signature it cannot produce.
Not a warning. Not a flag on a dashboard for someone to review on Monday. No instruction is emitted, so there is nothing downstream to recall, reverse, or dispute. The check fails closed: if the mandate cannot be read, or the revocation status cannot be established, the answer is no. And the refusal is itself a signed record, which is the part nobody else publishes.
A signed statement naming the decision, the policy version and its content hash, a digest of the inputs it ran over, the outcome, and the party that decided, kept separate from the party that issued the mandate. It verifies offline, against public keys, with nothing from us. A determination is independently verifiable by a party who was not there. The set the published engine reads is delegation credentials, refusal records, lapse records and decision attestations. It does not include policy evaluation credentials, resolutions, instructions or releases. It travels with the counterparty rather than living in our database.
A successful payment demonstrates that a system can move money. It says nothing about whether the system could have stopped. So here is the other record: a payment that was requested, was fully fundable, had a route, and did not happen. One entry, on a live rail, with the money there.
lnd-custom op-mandate maxi-l402-v1The payment could have succeeded. There was more than four times the balance required, a live channel to a well-connected peer, and a working node. Nothing about the network prevented it. The mandate did.
The control matters as much as the refusal. Ten sats to the same destination, over the same channel, by the same RPC method, settled. So the denial is the mandate acting on the amount, not a broken node, a closed channel, or a route that was never there. A refusal you cannot distinguish from a failure is not evidence of anything.
Stripping the caveat does not help: it dies on the macaroon HMAC chain. A hand-rolled gRPC client running as a different user with a sanctioned macaroon was refused by the node the same way, and the middleware defaults to deny across all 70 RPC methods and fails closed if it dies.
did:key, not Observer Protocol's production issuer.
· One node, ours, so this is enforcement at a node and not closure of the Lightning network.
· The macaroon caveat is a sender-side trigger in the payer's own credential; it is not visible to the payee, who sees an HTLC and a preimage like any other payment.
This register has one entry because one refusal has happened on a live rail with funds present. It will grow as more do. We would rather show you one you can check than a list you have to sort.
The strongest claim we make is that you do not need our cooperation to check our work. That claim is worth nothing unless you can run it, so here it is, against a credential that is live on this domain right now. What you can check without us: delegation credentials, refusal records, lapse records and decision attestations. What you cannot: policy evaluation credentials, resolutions, instructions and releases.
$ npm install @observer-protocol/policy-engine $ curl -O https://observerprotocol.org/credentials/\ maxi-0001-trading-mandate-2026-08.json // verify.mjs import { verifyCredentialObject } from '@observer-protocol/policy-engine'; import fs from 'node:fs'; const credential = JSON.parse( fs.readFileSync('./maxi-0001-trading-mandate-2026-08.json')); const config = { credentialPath: 'maxi-0001-trading-mandate-2026-08.json', // pin the issuer. a verifier that trusts // whoever the credential names is not // verifying, it is agreeing. issuerDid: 'did:web:bitcoinsingularity.ai', schemaAllowlist: ['https://observerprotocol.org' + '/schemas/delegation/v2.2.json'], revocation: { maxStalenessHours: 24, onUnreachable: 'cache-then-deny', fetchTimeoutMs: 5000 }, didCache: { maxStalenessHours: 24 }, cacheDir: '/tmp/op-cache', auditLog: '/tmp/op-cache/audit.log', rails: {}, allowContractCalls: false, }; console.log(await verifyCredentialObject( credential, config, Date.now())); $ node verify.mjs { allow: true, reason: 'credential verified' }
Everything the verifier checks is public: the issuer's DID document and the revocation status list, which it fetches over ordinary HTTPS from the origins the credential names, and the schema, which it checks by $id against your allowlist without fetching anything. There is no Observer Protocol API in the path, nothing to authenticate to, and nothing we can withhold to make a credential stop verifying.
Point offline.didDocumentPath at a local copy of the issuer's DID document and it makes no network call at all. That is the mode an examiner uses.
It fails closed, and it will refuse us too. onUnreachable: 'cache-then-deny' is the only accepted value: if the revocation list cannot be fetched, a cached answer is used and then the credential is denied. A status list hosted on an origin other than the pinned issuer's is refused until you allowlist it, and Observer Protocol's own clause-zero revocation demonstration is exactly such a pair, so it does not verify out of the box. That limit is published in the package.
Without installing anything: a decision attestation or an enforcement refusal record can be pasted into /check and checked in your own browser, which also derives, from the record you paste, which of its fields that signature actually reaches. A delegation credential is the one artifact the box above is still the route for, because verifying it resolves a did:web issuer over the network and that page makes no request.
This is not a design preference. It falls out of the message specifications for the real-time rails, and it is the reason the control sits where it does.
Faster Payments, SEPA Instant, FAST and PayNow carry no state in which a submitted instruction can still be stopped. There is no pending window, no recall leg that a supervisor can reach, no status the receiving institution is obliged to honour a reversal from. Settlement is the first and last state.
Where an institution does offer a hold, it sits in that bank's own API, above the clearing rail and inside one perimeter. It is a product feature of a single participant, not a property of the rail, and it does not travel to a counterparty at another institution.
If the only stoppable moment is before the instruction exists, then that is where the control has to be. Everything after it is reporting.
A rail identifier that needs a branch for fiat is a rail identifier that will grow a parallel schema. ClearingSystemCode:PaymentProduct mirrors CAIP-2's namespace:reference, so one field carries both and eip155:8453 already parses under it unchanged. 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.
| Identifier | Rail | Why the right half exists |
|---|---|---|
| USABA:ACH.CCD | ACH credit, United States | ACH and Fedwire share a clearing system and are different products |
| GBDSC:FPS | Faster Payments, United Kingdom | Distinguishes FPS from Bacs and CHAPS on the same code |
| SGIBG:PAYNOW | PayNow, Singapore | Distinguishes PayNow from GIRO and FAST |
| eip155:8453 | Base | CAIP-2 already; no change, no branch |
Status: proposed. This grammar is a design decision, not yet a published schema. Credentials issued today carry rail as a free-text string, and the shipped delegation/v2.6 schema documents it that way. Published schema URLs are immutable, so adopting this convention means a new schema version rather than an edit to an existing one. Until that version ships, this is what the field is becoming, not what it currently contains.
OP is what refuses and what proves. Agentic Terminal is how an institution operates it. The line between them is not open-versus-paid; it is primitive-versus-operation.
Signed attestations for decisions, refusals and approvals. Decisions and refusals verify with nothing from us. An approval does not, at the version npm install serves, and section 08 carries the band. Spec-governed, and what verifies you can run yourself without telling us you have.
The approver cannot set the terms of what they are approving. Deployed inside your infrastructure, operated by your team or ours. Never holds funds. Never takes custody of credentials — the enforcement point reads the mandate it enforces, and holds no key that could issue, alter or re-sign one.
Written so that a reader who checks it finds it accurate rather than generous. Where a claim is weaker than we would like it to be, the claim moves toward the evidence.
wdk-op-policy), MPP/Tempo (mppx-op-account) and OWS (ows-op-policy), from a shared core. The Aqua demonstration runs in an instrumented build on Liquid; the hook is not in shipped Aqua.@observer-protocol/policy-engine 1.0.0-rc.12 on npm, MIT. Section 05 is a transcript of it running against a credential served from this domain.PolicyEvaluationCredential artifacts carry no credentialSchema and are refused by our own verifier on structure; one older trading mandate is missing authorizationConfig.policy. Re-issuing them is a signing operation, not an edit, and it has not happened yet.verified_events table holds 56 rows; 55 of them predate the current cutover and carry proof_strength = 'unverified', which is what that column exists to record. We do not count them as verifications and neither should you.did:key, cryptographically distinct from the enforcement point, and you can verify that separation offline from its own DID. What it is not is a second party. It is a fixture we generated and control — not a published organisation and not an independent third party with its own interests. The separation is real as cryptography and currently means nothing as governance. Proving a decider is genuinely independent needs a real second party, and until one exists this row says fixture rather than independent.instructed, report records, and no version of the engine ever published rebuilds their signed bytes, so there is nothing to verify a signature against. This is not a version pin and it is not a gap that a reader can work around by installing something else: those records carry a signature that no counterparty, and no one here, can check. Principle 04 below says the evidence is portable or it isn't evidence. For better than a quarter of what we sign, it isn't. A further 122 resolution records are rebuildable at some published version but not at the one npm install serves; section 04 of /verify carries that. Every figure in this row is read from results/ and fails the build if the copy and the measurement disagree.verifyDecisionAttestation is exported by the version npm install serves, and verify-samples/ppp-determination-refused-outcome.json is a published decision attestation it returns attested on. The record carries the document that was signed as base64 beside a documentHash, and sha256 over those stored bytes reproduces that hash, so the input to the signature is rebuildable from the record alone, by someone who holds nothing else and was present for none of it. Checked in CI in both directions, so a regression and a silent repair both break the build. What it establishes is narrower than the word verifier suggests, and the narrowness is stated where the check is run rather than here: a named key signed those exact bytes and nobody has altered them since, while policyRef.hash, vocabularyRef.hash and deciderArtifactDigest.value are confirmed present and never resolved against anything. The field-level account is on the docs page./check was published carrying no script of its own, and the page a browser received loaded static.cloudflareinsights.com/beacon.min.js. Nothing in our repository had changed, and it was injected only for requests carrying browser headers, so a build check reading the file and a plain fetch of the same URL both reported it clean. It was disabled at the zone the same day. Two runs of the audit an hour apart, on 17 and 18 August 2026, both found it absent, which is what corroborated means here and is the whole of what it means: it rules out a transient and rules out nothing else.
scripts/served-page-audit.mjs fetches the page as a browser and compares what it carries against what the page discloses, failing when something undisclosed appears, when something disclosed is no longer there, and when one of the page's own scripts is missing or altered. That third direction is the one a subtraction hides in: an injected script is loud, and the page's own verifier being removed leaves a page that renders and decides nothing. It also refuses to treat an absence as established on one observation: a thing that is disclosed and not there may have been removed at the zone or the edge may transiently have stopped adding it, so that answer is held open until a second run separated in time sees the same thing. It is a standalone file with no dependency on this repository, so it can run on a clock rather than on a commit, which is the only shape that catches a change nobody committed.
v0.9, review record in the public repository. Additive over v0.6 through v0.8; an implementation conforming to any of those remains conforming.delegation/v2.7.json, carrying requiresDecisionAttestation, served at a URL that is immutable from the moment it went live. Note precisely what this does and does not change: the shape is now pinned and public, and there is still no verifier path for a PolicyEvaluationCredential. A published schema is not a verifier.Four commitments that do not bend to convenience, including when the convenience would be ours.
What a system did is checkable. What it says about itself is not. Every artifact this protocol produces is built to be checked by someone who has no reason to believe us.
A machine holds no authority it was not explicitly given by a human who signed for it. Absence of a mandate is not permission to proceed carefully; it is refusal. The default is no.
Verification logic is public, reproducible and auditable. No authority required. Self-hostable by design: OP does not custody funds, execute payments, or control access.
An attestation that only means something inside our system is a log entry. Ours verify against public keys, in your hands, after we are gone. We are not the custodian of the proof.
On 22 February 2026 two agents built by different developers, running on different stacks, settled a payment on Bitcoin mainnet against authority that had been granted in advance. The point was never that no human was in the loop. The point is that the human was in the loop first, at the moment the authority was granted, and that what happened afterwards can be checked by anyone against the payment hash.