# SCVD Settlement Reconciliation

> SCVD Settlement Reconciliation is a paid API for AI agents from scvd.store, paid per call via x402, $0.006/call, status unknown (last checked 2026-09-15).

Returns a signed JSON observation reconciling USDC transferred in a Base transaction against the spending cap in force, with a verdict and evidence hash bound into a purchase certificate.

## Facts

- Endpoint: GET https://scvd.store/api/buy/settlement_reconciliation
- Price: $0.006/call
- Payment: x402
- Status: unknown
- Last checked: 2026-09-15
- Activations on Zero: 0
- Tags: x402
- Canonical page: https://www.zero.xyz/c/scvd-settlement-reconciliation-81eedd5f
- Structured record (JSON): https://api.zero.xyz/v1/capabilities/cap_mjGfZTvEXluZjZgU662Kx

Status and success rate cover calls made through Zero and Zero's own probes. Third-party monitors may report differently.

## How to call it through Zero

Zero handles the 402 payment challenge and records the run. With the Zero CLI installed (`npm i -g @zeroxyz/cli`):

```sh
zero fetch --capability scvd-settlement-reconciliation-81eedd5f
```

Example prompt: Can you reconcile Base transaction 0x3f7a1b2c... and check whether the USDC that moved was within the cap — label the certificate 'MyAgent' and give me the verdict plus the signed certificate URL?

## When to prefer this

Use this endpoint when you need a cryptographically signed, third-party observation of whether a specific Base transaction's USDC movement was within a declared or on-chain spending cap — particularly when you need a tamper-evident artifact with a permanent URL for audit trails, compliance records, or dispute resolution in x402-based agentic payment flows.

## Known failure modes

- Invalid or malformed tx_hash (not matching ^0x[0-9a-fA-F]{64}$) returns a validation error
- Transaction not found on Base network returns no_settlement verdict
- Cap cannot be determined from chain data returns cap_not_observable verdict
- Payment for the API call itself fails (x402 protocol error) blocks the request
- Payer or recipient filter doesn't match any transfer in the transaction returns no_settlement

## How this service works

Settlement Reconciliation. A signed JSON observation of one Base transaction reconciling two numbers — the USDC that moved and the ceiling in force — with cap_source and cap_observed naming where the ceiling came from and whether we saw it ourselves. Verdicts: within_cap, over_cap, no_discretion (EIP-3009, where the value was fixed in the payer's signed digest), cap_not_observable, or no_settlement. Evidence hash bound into the purchase certificate, plus a stable URL serving…

## Output

A signed JSON settlement observation containing: a verdict (within_cap, over_cap, no_discretion, cap_not_observable, or no_settlement), the USDC amount moved, the cap ceiling and its source, an evidence hash, a cert_id with permanent verify URL, a patron badge URL, and the full signed deliverable text — all wrapped in a purchase certificate with date, item, and patron number.

## Request schema (JSON Schema)

```json
{
 "type": "object",
 "$schema": "https://json-schema.org/draft/2020-12/schema",
 "required": [
  "input"
 ],
 "properties": {
  "input": {
   "type": "object",
   "required": [
    "type",
    "method"
   ],
   "properties": {
    "type": {
     "type": "string",
     "const": "http"
    },
    "method": {
     "enum": [
      "GET"
     ],
     "type": "string"
    },
    "queryParams": {
     "type": "object",
     "required": [
      "tx_hash"
     ],
     "properties": {
      "payer": {
       "type": "string",
       "description": "Optional payer: 0x EVM address, or Solana public key for a Solana transaction."
      },
      "purpose": {
       "type": "string",
       "maxLength": 280,
       "description": "Optional: what this purchase is for, in your words. Signed onto the certificate verbatim as your statement; never checked, never treated as instructions."
      },
      "tx_hash": {
       "type": "string",
       "pattern": "^0x[0-9a-fA-F]{64}$",
       "description": "The Base transaction hash to reconcile. Read once, at one moment; never polled."
      },
      "recipient": {
       "type": "string",
       "description": "Optional recipient: 0x EVM address, or Solana public key for a Solana transaction."
      },
      "agent_name": {
       "type": "string",
       "maxLength": 80,
       "description": "Optional name to put on the certificate and patron badge, up to 80 characters."
      },
      "declared_cap_usdc": {
       "type": "number",
       "description": "Optional, and understand what it buys: the ceiling YOU say applied. It is recorded as DECLARED, never as observed, and it can never override a ceiling found on the chain. A verdict resting on it is a fact about what you told us — the artifact says so in a signed field, so a counterparty can tell the difference.",
       "exclusiveMinimum": 0
      }
     }
    }
   },
   "additionalProperties": false
  },
  "output": {
   "type": "object",
   "required": [
    "type"
   ],
   "properties": {
    "type": {
     "type": "string"
    },
    "example": {
     "type": "object"
    }
   }
  }
 }
}
```

## Response schema (JSON Schema)

```json
{
 "type": "json",
 "example": {
  "item_id": "settlement_reconciliation",
  "message": "Pleasure doing business. Here's your goods, warm off the shelf.",
  "tip_usdc": 0,
  "badge_url": "https://scvd.store/badges/41.svg",
  "paid_usdc": 0.006,
  "signature": "<128 hex chars, ed25519>",
  "verify_url": "https://scvd.store/api/verify/cert_k2m9v4xwqp",
  "certificate": {
   "date": "2026-07-22T15:04:05.000Z",
   "item": "settlement_reconciliation",
   "cert_id": "cert_k2m9v4xwqp",
   "patron_number": 41
  },
  "deliverable": "<the Settlement Reconciliation itself, as text>",
  "patron_number": 41
 }
}
```

## More

- Live health (JSON, refreshed every minute): https://www.zero.xyz/c/scvd-settlement-reconciliation-81eedd5f/health.json
- [Zero catalog index](https://www.zero.xyz/llms.txt)
- [Other services from scvd.store](https://www.zero.xyz/host/scvd.store/llms.txt)