Default Settlement Verifier

🚀 Default Settlement Verifier

Deterministic, neutral verification for agent-to-agent and programmatic settlements.

Landing page: https://defaultverifier.com

🚀 Quick Start

The Default Settlement Verifier is a crucial tool for ensuring the integrity of settlements. It offers deterministic, neutral verification for various types of settlements, whether between agents or in programmatic scenarios.

SAR v0.1 Specification

• Spec: https://defaultverifier.com/spec/sar-v0.1
• Public Keys: https://defaultverifier.com/.well-known/sar-keys.json
• Fixtures: https://defaultverifier.com/spec/sar-v0.1/fixtures/README

✨ Features

Overview

The Default Settlement Verifier is a stateless verification service. It assesses whether a claimed settlement outcome meets predefined conditions under deterministic rules. It answers a single question: “Given this claim and these conditions, does it verify?” It generates signed, replayable truth, rather than dealing with coordination, custody, or enforcement.

What It Does

The verifier takes a structured verification request that describes a settlement claim and evaluates it against deterministic rules. It returns:

• A binary verdict (PASS / FAIL)
• A confidence score
• A cryptographic signature
• Optional fee metadata (fee-aware; currently not enforced)

The verifier has the following characteristics:

• It does not hold funds.
• It does not initiate payments.
• It does not maintain session state.
• It does not rely on identity, reputation, or trust assumptions.

Core Properties

• Deterministic — Identical inputs always yield identical signed results.
• Stateless — Every call is independent.
• Neutral — There is no buyer/seller bias, no incentives, and no governance layer.
• Composable — It can be integrated into agent frameworks, payment rails, and settlement protocols.
• Auditable — Signed responses enable downstream verification and logging.

Intended Use Cases

• Agent-to-agent payments that require post-condition verification.
• x402-style pay-after-execution flows.
• Automated escrow or conditional release systems.
• Buyer protection primitives without custody.
• Programmatic settlement validation in AI workflows.

📦 Installation

No installation steps are provided in the original document, so this section is skipped.

💻 Usage Examples

Canonical Verification Endpoint (POST)

POST https://defaultverifier.com/verify

Important:
This endpoint only accepts POST requests. Browsers will display “Cannot GET /verify”. This is the expected behavior.

Example request:

{
    "task_id": "example-001",
    "spec": { "expected_output": "hash_or_descriptor" },
    "output": { "expected_output": "hash_or_descriptor" }
}

SettlementWitness (v0)

SettlementWitness is a thin, stateless wrapper that calls the Default Settlement Verifier and returns a replay-stable receipt for agent workflows. It adds no state, no judgment, no retries, and no facilitation logic.

Canonical Endpoints

• POST https://defaultverifier.com/settlement-witness
• GET https://defaultverifier.com/manifest

Notes:

• POST /settlement-witness is POST-only.
• GET /settlement-witness returns 405 by design.

Example (PASS)

curl -s -X POST https://defaultverifier.com/settlement-witness \
  -H "Content-Type: application/json" \
  -d '{
    "task_id": "example-002",
    "spec": { "expected": "foo" },
    "output": { "expected": "foo" }
  }'

Minimal response shape (trimmed):

{
    "witness": "SettlementWitness",
    "witness_version": "v0",
    "task_id": "example-002",
    "verifier_response": {
        "verdict": "PASS",
        "reason_code": "MATCH",
        "signature": "..."
    },
    "witness_timestamp": "...",
    "receipt_id": "..."
}

MCP (Canonical)

SettlementWitness is available via MCP for agent-native workflows.

• MCP Server: https://defaultverifier.com/mcp
• Health: https://defaultverifier.com/mcp-healthz
• Tool: settlement_witness
• Arguments (required):
  • task_id (string)
  • spec (object)
  • output (object)
• Returns: receipt JSON (verbatim)

Determinism guarantee: Identical inputs produce the same receipt_id and verifier signature. Timestamps may differ.

📚 Documentation

Security & Settlement Gating

The Default Settlement Verifier can act as a lightweight mitigation layer in autonomous workflows:

• Proof-of-Delivery — Deterministic PASS/FAIL verdicts verify that outputs match task specifications before settlement.
• Settlement Gating — Payments or downstream actions can be conditioned on verifiable completion.
• Dispute Reduction — Signed receipts provide replayable evidence for post-task settlement decisions.

The verifier does not enforce outcomes or custody funds; it generates neutral, signed verification receipts.

Determinism & Signatures (Replay Stability)

• timestamp and witness_timestamp may change on each call (observability).
• For identical inputs (task_id, spec, output), the verifier signature is stable.
• receipt_id is derived from the verifier signature and is stable for identical inputs.

Endpoint Behavior (Expected)

• POST /verify → works (GET not supported)
• POST /settlement-witness → works (GET returns 405)
• GET /manifest → works

OpenClaw Compatibility

SettlementWitness is compatible with OpenClaw via a drop-in skill definition included in this repository:

openclaw/skills/settlement-witness/SKILL.md

The skill calls the public HTTPS endpoint: POST https://defaultverifier.com/settlement-witness No local services are required.

Agent Wrappers & Skills

SettlementWitness is a stateless witness wrapper that issues replay-stable verification receipts for post-task settlement workflows. It is compatible with:

• Heurist Mesh (submission pending)
• MCP invocation patterns
• OpenClaw skills (drop-in wrapper included)

Deployment Notes (Factual)

• Verifier and SettlementWitness are served via HTTPS behind NGINX on defaultverifier.com.
• SettlementWitness runs persistently and is proxied via NGINX (no raw port exposure).
• Cloudflare cache bypass is enabled for API routes (/verify, /settlement-witness, /manifest).

Non-Goals

The Default Settlement Verifier explicitly does not:

• Act as an oracle of subjective truth.
• Resolve disputes.
• Store or escrow funds.
• Enforce payment.
• Provide reputation or identity services.

Those layers belong upstream or downstream.

Roadmap (Non-Commitment)

• Expanded claim schemas
• Optional replay-safe receipts
• Public verification key endpoint
• Optional metrics endpoint

No timelines are guaranteed.

📄 License

MIT License

Contact

Project discussions and updates: https://x.com/defaultsettle

Operator & Provenance

SettlementWitness is operated as part of the Default Settlement Verifier infrastructure.

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

SettlementWitness is a stateless deterministic attestation service. It does not hold funds, execute payments, enforce settlements, or trigger on-chain actions.

Receipt verification: see docs/signature-verification.md (added in this repo).

Support

If the Default Settlement Verifier or SettlementWitness saved you time, reduced risk, or helped you ship faster, you can support ongoing infrastructure work.

Support via GitHub Sponsors:
https://github.com/sponsors/nutstrut

Infrastructure is operated independently and remains free to use.