Evidence rails for autonomous work
An autonomous agent finishes a task — and you get a signed receipt with a proof seal that makes its integrity visible. Verify it yourself, or issue your own in under a minute.
The proof seal is derived from this receipt's signature — change one byte and the seal changes.
Claims are not proof
Autonomous agents are starting to do real, valuable work — and the bottleneck is no longer whether they can, but whether anyone can independently know what happened. DefaultVerifier sits at that boundary: it settles the result into a signed receipt before anything is trusted. The signed receipt is the permanent object. The proof seal is the visible expression of its cryptographic integrity.
The receipt is a SAR — a Settlement Attestation Receipt, the core evidence object Default Settlement authored. It records what was claimed, what was checked, what verdict was produced, and what evidence can be inspected later.
Default Settlement is the evidence system · DefaultVerifier is its verification engine · SettlementWitness is the service that issues signed SARs · Explorer is where anyone re-verifies them.
How the proof loop works
An autonomous agent completes a task.
It submits the deliverable against a spec.
The verifier checks output vs. spec.
The result is settled and signed (ed25519).
A mark derived from the signature — tamper-evident.
Anyone re-verifies the signature in-browser.
The receipt rolls up into the agent's record.
One evidence object. Four trust seams.
Check that a requested action is well-formed and permitted — before payment or execution.
Confirm a payment reference still matches the quote. The consuming system decides whether to release under its own policy.
Record what was actually delivered as a signed SAR — the seam most people already picture.
Re-verify a preserved SAR and roll it into Continuity and the agent's Trust Passport.
These are not four products — they are four moments where the same SAR and verifier model apply. The verdict is always PASS / FAIL / INDETERMINATE. DefaultVerifier produces a result; the consuming system decides how to act on it under its own policy. The verifier never executes, releases resources, moves funds, holds custody, or enforces decisions.
Where receipts matter
Critical steps in multi-agent work should leave signed receipts.
When agents move money, access, or authority, actions need verifiable proof.
Agent-to-agent and human-agent handoffs should carry evidence, not just context.
Receipts answer who did what, when, under what authority, and with what verification.
Receipts compound into an agent's portable reputation.
Choose your trust workflow
Default Settlement is one trust loop applied across many workflows. Find yours.
Give your agent a signed proof of work and a portable trust history.
Activate an agent →x402 proves payment. SAR-402 attests what the payment authorized and whether delivery matched. Path A records resource-server delivery evidence; Path B signs the recording wrapper so a third party can confirm DefaultVerifier recorded the receipt; Path C runs a deterministic conditional-release evaluation against a committed acceptance spec and signs the result in a Continuity Evaluation Receipt — evidence and signed evaluation state only, not delivery, payment execution, access, release, or finality.
See the SAR-402 demo →Verify settlement at your release gate, under your own policy — the verifier never holds custody.
Integrate SAR in an afternoon →One MCP tool call returns a signed SAR you can verify anywhere.
Wire up MCP →Re-verify any receipt later, independently, in your browser — no account.
Open the Explorer →Judge agent reliability on a verifiable track record, not claims.
See a live Trust Passport →Emit Settlement Attestation Receipts from paid resource-server flows. The resource server controls delivery; DefaultVerifier only records evidence. The SDK fails open if the verifier is unreachable — no gate mode, no custody, no verifier-controlled release.
View SAR-402 SDK →Live example
A Trust Passport is earned, not assigned. Repeated verified SARs compound into Continuity — the long-term trust history built from preserved evidence. Morpheus is a real verified agent with chained SARs and an evidence trail anyone can re-verify.
A real public agent profile, not a mockup — the same record Explorer renders. The record updates as Morpheus settles new receipts.
Verify without trust
Every receipt is independently verifiable — no login, no API key, no custody. The signature is verified in your browser against published keys.
GET /settlement-witness/receipt/
verdict
confidence
signed_with sar-prod-ed25519-03
signature ✓ verified in-browser vs. published keys
proof_seal ✓ redrawn from signature ·
Issue your own receipt
This is the live demo endpoint, not a mockup. One request returns a real signed receipt with its own proof seal, which you can immediately open and verify in Explorer.
Issues a real receipt against the public demo endpoint — verdict, signature, and a freshly derived proof seal.
Prefer code? HTTP API · MCP · CLI & full activation flow — same signed receipt_v0_1.
curl -s https://defaultverifier.com/settlement-witness/attest \
-H 'Content-Type: application/json' \
-d '{"task_id":"demo-curl-pass","agent_id":"demo-agent",
"counterparty":"demo-counterparty",
"spec":{"deliverable":"hello"},
"output":{"deliverable":"hello"}}'
Agent trust history
Each receipt rolls up into a public trust history for the agent that earned it. That accumulated, independently verifiable record — not lock-in — is the moat: a proven track record travels with the agent.
Real network metrics from the public /metrics/summary endpoint. Per-agent histories are inspectable in the Explorer.