Case Study: SettlementWitness Integrates
InsumerAPI for Pre-Transaction Qualification

SettlementWitness is a delivery verification layer for autonomous agent commerce. It issues signed Settlement Attestation Receipts (SARs) that prove whether an agent completed a task to specification before payment settles. In its production stack, InsumerAPI sits at the front as the pre-transaction qualification layer: wallet auth verifies the principal qualifies before work begins, and SAR verifies the deliverable after work completes. Two independent primitives bookending the same transaction.

The problem: qualification and delivery are different questions

Agent commerce introduces a gap that traditional payment flows do not have. When an AI agent initiates a transaction on behalf of a wallet, two things need to be true: the wallet behind the agent is qualified to participate (the pre-payment verification question), and the work the agent performs is delivered as specified.

Most systems conflate these into a single trust decision. An agent passes an identity check, the transaction proceeds, and everyone hopes the outcome matches the intent. If the delivery falls short, the dispute happens after funds have moved.

The insight behind the SettlementWitness integration is that qualification and delivery verification are independent problems that require independent checkpoints. One before the transaction, one after. Neither should know or care how the other works.

The pre/post pattern

The architecture is straightforward. InsumerAPI handles the pre-transaction checkpoint. Before a payment or task begins, the system calls POST /v1/attest to verify that the wallet backing the agent meets specific conditions: does it hold the required tokens? Does it carry governance credentials? Is it capitalized on the relevant chain?

The attestation is ECDSA P-256 signed and verifiable offline via JWKS. It returns a boolean per condition, not a balance. The signed response includes a conditionHash that binds the exact conditions evaluated to the cryptographic proof. This creates a verifiable checkpoint: at block N, wallet W met conditions X on chain C.

SettlementWitness handles the post-transaction checkpoint. After the agent completes its task, the system submits the task specification and the actual output to the SettlementWitness endpoint. The verifier evaluates deterministically whether the output matches the spec, and returns an Ed25519-signed SAR with a verdict: PASS, FAIL, or INDETERMINATE.

Payment settles only if both checkpoints clear. The wallet was qualified going in, and the work was verified coming out.

Why loose coupling is the right design

The two primitives are deliberately independent. The qualification check does not know which settlement layer picks up after it. The SAR does not need to know how qualification was established. What links them is the transaction itself, not a shared protocol or data format.

This matters for composability. A different project could use InsumerAPI for pre-transaction qualification and a completely different delivery verification system. Or use SettlementWitness for delivery verification with a different qualification layer at the front. Tight coupling would make both less useful as standalone infrastructure.

The InsumerAPI attestation travels as a signed credential. The SAR travels as a signed receipt. Both are independently verifiable by any third party with access to the respective public keys. Neither requires trust in the other system.

Architecture

The defaultverifier.com stack positions the two layers explicitly:

1. Wallet auth (InsumerAPI): POST /v1/attest verifies the agent's wallet meets the required conditions. ECDSA-signed response. Pre-transaction.
2. Payment (x402): The payment signal fires. The agent commits to the task.
3. Delivery verification (SettlementWitness): Task output is evaluated against the spec. Ed25519-signed SAR issued. Post-transaction.
4. Settlement: Payment releases only on a PASS verdict from the SAR, gated by the pre-transaction attestation.

The pre-transaction attestation covers 33 chains (30 EVM + Solana + XRPL + Bitcoin). Token balances, NFT ownership, governance tokens, stablecoin holdings, and staking positions can all serve as qualification conditions. A single POST /v1/attest call handles up to 10 conditions across multiple chains simultaneously.

The x402 SAR integration

The integration is already live as a reference implementation. The insumer-examples repository includes a complete x402 SAR example showing the full pipeline: attestation request, payment signal, SAR generation, and offline verification of both the attestation and the receipt.

The SAR format uses JSON Canonicalization Scheme (RFC 8785) for deterministic serialization and Ed25519 signatures for receipt integrity. The sar-sdk npm package provides a TypeScript implementation for both generating and verifying SARs.

An independent implementation by xMandate has already validated the format, confirming that kid-indexed key rotation works cleanly from the verifier side with no changes to receipt verification.

What comes next

The pre/post pattern opens a natural question: should every transaction that verifies output also have verified eligibility going in? The SettlementWitness team is exploring making the qualification checkpoint a required input to the settlement flow rather than an optional layer.

The multi-attestation format (documented in the multi-attestation spec) supports combining signed attestations from multiple issuers in a single verification pass. A transaction could carry both the InsumerAPI wallet attestation and the SettlementWitness delivery receipt as independently verifiable entries in the same payload, each signed by its own key, each verifiable against its own JWKS endpoint.

Two checkpoints, one transaction

Agent commerce needs boundaries. Without them, an authorized agent with a valid identity can initiate transactions from an empty wallet and deliver work that does not match the specification. Identity alone does not prevent either failure. The trust layers that compose in agent payments exist precisely because no single checkpoint is sufficient.

Wallet auth sets the condition going in. The SAR verifies the outcome coming out. The transaction links them. Everything else is independently verifiable, offline, by anyone.

The integration is live at defaultverifier.com. The reference implementation is available on GitHub. The SAR SDK is published on npm.