New in 0.1.0: local-first verification. Receipt cryptography is verified entirely on your machine — no network required. Network is optional and only used when you explicitly request remote receipt issuance or resolution.

SettlementWitness

Verify SAR v0.1 settlement receipts locally. Optionally request DefaultVerifier-signed receipts.

When to use

• Before trusting a task-complete claim from another agent
• Before chaining downstream actions to an agent output
• Before using a receipt as evidence
• Before acting on a settlement- or payment-adjacent claim
• When you prefer a local, offline verifier

First run (offline, no network needed)

Run the self-test against all bundled fixtures:

python3 scripts/verify_receipt.py --self-test

Expected output: self_test_passed: true with all six fixtures [OK].

Verify a single receipt

python3 scripts/verify_receipt.py fixtures/sar-v0.1-pass.json

Returns JSON:

{
  "valid": true,
  "receipt_id": "sha256:...",
  "kid": "sar-prod-ed25519-05",
  "verdict": "PASS",
  "errors": [],
  "signer_lifecycle_status": "active",
  "trusted_current_production_signer": true,
  "trusted_historical_signer": true,
  "registry_snapshot_sha256": "2da5285f...",
  "offline_verification_note": "Verified offline against the bundled registry snapshot ..."
}

Tamper test (should fail)

python3 scripts/verify_receipt.py fixtures/tampered-receipt.json

Returns valid: false with errors listing the digest mismatch and signature failure. This proves the verifier actually rejects tampered receipts.

How to interpret results

`valid: true` is never the same claim as `trusted_current_production_signer: true`. A retired key's historical receipt is genuinely valid: true (the signature is real) while trusted_current_production_signer stays false — retirement never erases historical verifiability, and a historical receipt is never silently upgraded to a current-production claim.

PASS, FAIL, and INDETERMINATE are all valid signed outcomes when valid: true — they represent what the issuer attested, not post-hoc interpretation.

What works offline vs what uses the network

Fully offline (no network):

• Parsing a SAR v0.1 receipt JSON
• Recomputing the canonical digest from signed core fields
• Verifying receipt_id matches the digest
• Verifying the Ed25519 signature against the bundled public key registry
• All four bundled fixture checks (--self-test)

Optional network (only when you explicitly ask):

• Requesting a new DefaultVerifier-signed receipt — signing keys stay

server-side by design, so issuance requires the remote service

• Resolving a receipt ID
• Refreshing the public key registry
• Chain or correlation lookups

If DefaultVerifier is offline, local verification of existing receipts still works. The service being unavailable does not invalidate receipts you already have.

Optional remote receipt issuance

To request a signed receipt from DefaultVerifier (requires network):

curl -sS https://defaultverifier.com/settlement-witness \
  -H "Content-Type: application/json" \
  -d '{"task_id":"your-task-id","spec":{"expected":"value"},"output":{"expected":"value"}}'

The REST endpoint returns a signed SAR v0.1 receipt. You can then verify it locally with scripts/verify_receipt.py.

Public key registry: https://defaultverifier.com/.well-known/sar-keys.json Receipt explorer: https://defaultverifier.com/verified

Known limitation: settlement-witness-verified-v0.2 receipts

This skill's local verifier parses the legacy flat SAR v0.1 receipt schema only. Current production issuance uses the settlement-witness-verified-v0.2 receipt profile, which has a different shape (verification_basis, properties, receipt_profile fields; no confidence field). v0.2 receipts cannot be offline-verified by this skill version. The bundled key registry (keys/sar-keys.json) is kept current with the production signer set — including the current active signer, published at https://defaultverifier.com/.well-known/sar-keys.json — regardless of this gap, so that key-lookup stays accurate even where receipt-shape parsing does not yet cover v0.2.

Safety boundaries

DefaultVerifier issues signed evidence about whether a receipt is cryptographically valid. It does not:

• Execute user tasks
• Approve or reject actions
• Release, hold, or custody funds
• Prove legal settlement finality
• Prove payment finality
• Control downstream agent behavior

Acting on a verified receipt is the responsibility of the system or agent that reads it.

Environment

Override the public key registry path if needed:

SAR_KEYS_REGISTRY_PATH=/path/to/keys.json python3 scripts/verify_receipt.py receipt.json

Provenance

Operator: Default Settlement Verifier Repository: https://github.com/nutstrut/default-settlement-verifier Homepage: https://defaultverifier.com