# Settlement Attestation


Signed settlement attestation for an x402 payment on a supported network selected in the input contract.

## At a glance

- **Attests:** The whole observation object: the transaction hash asked about, what the chain said, the block height, the chain head at reading, the confirmations, the moment observed, the desk's battery, and the binding — what, if anything, ties the transaction to one payment authorization (none, authorization_nonce or the reserved input_commitment), beside what was asked. When a facilitator's settlement response was supplied, input_claims is signed too: the sha256 of the bytes received and a per-field table of whether each claim agrees with the chain — never the claimed values themselves, echoed outside the signature under received_not_observed. The projection beside the artifact is signed on its own, points back by evidence_hash, and is never the record. Observations signed before 2026-09-11 carry neither battery nor binding: read that as predating binding classes, never as unbound; a battery cited without a binding is defective. From battery v3, a nonce checked against a successful receipt adds signed binding.evidence: pairing result, reason and, when readable, authorizer, nonce, recipient, atomic amount and receipt positions — one canonical USDC AuthorizationUsed immediately followed by its Transfer, every supplied term matching; ambiguous authorizers need payer, unknown ordering stays unestablished. Battery v2's independent nonce and transfer matches can overstate correspondence: consult /corrections before citing its binding claim. Battery v4 also checks the EVM receipt's transaction identity, reported chain, block height, chain head and status before signing; malformed provider answers, and missing or duplicate batch answers, are refused rather than labelled. From settlement-attestation-v5, a signed auth_capture field names each USDC leg that touched the x402 auth-capture escrow set (role, deployment, direction, source); absent, none did; status and binding never move for it. Historical signed bytes are unchanged; a sheaf (attestation_bundle) is this artifact at volume, every member signed alone.
- **Input:** tx_hash (query parameters; input schema and checkout: https://scvd.store/menu/settlement_attestation?view=compact)
- **Output:** A signed JSON observation of one transaction on Base, Polygon, or Solana — the identifier's shape picks the chain — with status (SETTLED, NOT_FOUND, PENDING_FINALITY, INSUFFICIENT_MATCH or REVERTED), block height (slots on Solana), confirmations, chain head, the query echoed back, and an evidence hash — verifiable against the store's published key without asking the store. Instant. Every artifact carries a cert_id and verifies free at https://scvd.store/api/verify/{cert_id}.
- **Cryptography:** ed25519 signature by this store's key, published at https://scvd.store/.well-known/scvd-signing-key and carried inside every 402
- **Verify:** GET https://scvd.store/api/verify/{cert_id} — free, no account, no rate limit, checkable offline with the published key
- **Price and fulfilment:** $0.004 USDC fixed, one-off; nothing here charges again by itself, ever — there is no mechanism that could; delivered instantly
- **Does not attest:** That goods or services were delivered, that a NOT_FOUND will never settle later, or that the payment was legitimate. That the transaction was the settlement of any particular request: binding says what it ties, and authorization_nonce ties one EIP-3009 authorization, not one 402 challenge — whether the door tied that nonce to a single request is the door's work and unobserved. Under auth-capture, the lifecycle: whether the hold auth_capture names was later captured, voided or refunded was not read. Anything a facilitator's settlement response says: it is received, not observed, and an agreement row that reads disagrees is a finding about the response, not a verdict on anyone. One RPC read of public state, at one moment, signed by a party with no interest in the answer.

## About this item

An independent signed observation of whether an x402 payment settled — on Base, Polygon or Solana, and the identifier's own shape picks the rail: a 0x hash names an EVM transaction rather than a chain, so it is read on Base and then on Polygon; a base58 signature reads Solana. Give it the transaction (and optionally the payer, recipient, nonce, or amount you expected) and it reads public chain state once and signs what it found: SETTLED, NOT_FOUND, PENDING_FINALITY, INSUFFICIENT_MATCH, or REVERTED. Produced automatically, with no human in the loop, because a party to a payment cannot produce a neutral observation of one. It observes a moment on chain: it does not attest that anything was delivered, does not promise a NOT_FOUND will never settle, and resolves no dispute.

- **id:** `settlement_attestation`
- **price:** $0.004 fixed, one-off; nothing here charges again by itself, ever — there is no mechanism that could
- **fulfillment:** delivered instantly
- **buy:** `GET https://scvd.store/api/buy/settlement_attestation?tx_hash=<tx_hash>` (USDC over x402 v2 on Base, Polygon, Arbitrum, World, Solana, Arc (Circle Gateway), or USDC over MPP (evm/charge) on Base for every shelf item, every publication page and the commission desk)
- **required inputs:** `tx_hash` — fill the `<tx_hash>` slot above before paying. The bare door `GET https://scvd.store/api/buy/settlement_attestation` quotes free and refuses the paid request without it; no money moves.
- **sample:** https://scvd.store/samples/settlement-attestation.json
- **does not prove:** That goods or services were delivered, that a NOT_FOUND will never settle later, or that the payment was legitimate. That the transaction was the settlement of any particular request: binding says what it ties, and authorization_nonce ties one EIP-3009 authorization, not one 402 challenge — whether the door tied that nonce to a single request is the door's work and unobserved. Under auth-capture, the lifecycle: whether the hold auth_capture names was later captured, voided or refunded was not read. Anything a facilitator's settlement response says: it is received, not observed, and an agreement row that reads disagrees is a finding about the response, not a verdict on anyone. One RPC read of public state, at one moment, signed by a party with no interest in the answer.

House rules: give the transaction in the tx_hash query parameter: an evm hash (0x + 64 hex, read on base and then polygon) or a solana signature (base58) — the shape picks the rail; optional narrowing: payer, recipient, nonce (evm rails only — refused beside a solana signature), amount_usdc, or payment_payload (the base64 payment-signature you sent, read with the store's own replay-guard code). the artifact's binding field says what the answer ties the transaction to: one uniquely identified authorizer/nonce and its paired canonical usdc transfer bind it to one authorization, never to one request. supply payer to distinguish reused nonces across authorizers; every supplied transfer field must match the same pair. unrecognised event ordering establishes no binding; optional payment_response: the payment-response header you received, verbatim. received, not observed — its bytes are digested into the signature and echoed outside it, and each claimed field (transaction, network, payer, success) is set beside what the chain showed: agrees, disagrees, not claimed, or not observed; observes settlement only, never delivery; one read at one moment; no polling, no retry, no second look.

> Four tenths of a cent, friend. The chain read is free; the signed, disinterested receipt is what you are buying. An EVM hash (read on Base, then Polygon) or a Solana signature — the shape picks the rail. No transaction of your own yet? Buy anything here — the half-cent blessing counts — and the purchase response hands you this door's URL with your own settlement transaction already filled in, whichever rail you paid on.