Start here

Verify what happened. Issue your own when you're enrolled.

DefaultVerifier evaluates a declared condition against real evidence and returns a signed receipt — PASS, FAIL, or INDETERMINATE. Two things are true at once: checking a receipt is open to anyone with no credential, and issuing a receipt through the direct attestation endpoint requires an enrolled caller. This page gets you to your first verified receipt either way.

What's public vs. what requires enrollment

No credential needed

Public verification

Anyone can independently verify a receipt's signature and inspect its contents — no account, no key. This includes the public key set (JWKS), the receipt lookup route, and Explorer. You do not need to trust DefaultVerifier's word that a receipt is valid; you can check the cryptography yourself.

Enrolled caller required

Protected issuance / evaluation

Calling POST /settlement-witness/attest directly to have DefaultVerifier evaluate your own task and sign a receipt requires an enrolled scoped caller — a bearer credential issued to your integration, sent with every request alongside a timestamp and a nonce. An unauthenticated call to this endpoint is rejected.

This page previously described direct issuance as requiring no account or key. That changed with the D31 authentication cutover; this page now reflects the current, live contract.

Get your first verified receipt

1
See a real one first. Open sarexplorer.com and load any receipt id, or visit the homepage's live demo — no credential required.
2
Request enrollment. Direct issuance is operator-mediated, not self-service today. Contact Default Settlement at keith@defaultverifier.com to request an enrolled caller — see Integrate → Enrollment for what to include in that request.
3
Send your first protected request once you have a credential, using the headers below.
4
Verify the response yourself against the public key set — don't just trust the verdict field.

Required headers, once enrolled

Header	Value
`Authorization`	Bearer <your enrolled caller key>
`X-Settlement-Timestamp`	Unix seconds, must be within 120 seconds of server time
`X-Settlement-Nonce`	A fresh, unique value for this request — reuse within the 120-second window is rejected as a replay

Full semantics — exact freshness window, replay behavior, and error responses — are documented in Integrate.

Minimal protected request

curl -X POST https://defaultverifier.com/settlement-witness/attest \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <enrolled-caller-key>" \
  -H "X-Settlement-Timestamp: <unix-seconds>" \
  -H "X-Settlement-Nonce: <fresh-random-nonce>" \
  -d '{
    "task_id": "your-task-id-here",
    "spec": {
      "checks": [
        {
          "kind": "field_equals",
          "inputs": { "output_path": "$.status" },
          "expected": "ok"
        }
      ]
    },
    "output": { "status": "ok" }
  }'

This example evaluates to PASS because output.status equals the expected value the check declares. Change output.status to anything else and the same request evaluates to FAIL. See Integrate → Evaluator grammar for how checks[] works, including why a bare {"expected": ...} with no checks[] is not an evaluable contract.

Verify the signed receipt

The response is a signed receipt. Verify it independently — against the public key set, not against DefaultVerifier's say-so:

Public keys: GET https://defaultverifier.com/.well-known/jwks.json
Or drop the receipt id into Explorer, which performs the same check for you.
To fetch a receipt back later by id (no credential needed), see Integrate → Receipt lookup for the exact route and identifier format.

Where to go next

Integrate is the full contract: exact auth semantics, request schema, verdict and reason-code domain, the deterministic evaluator grammar, and how to opt into a counterparty-bound receipt. Spec covers the portable receipt structure and independent-verification mechanics in depth.