x402 protocol

Base USDC payments, receipts, failures, and safe retries

SignalHarness uses x402 V2 exact payments on Base mainnet. The live challenge—not a copied address—defines the recipient, amount, asset, network, expiry, method, and resource for each call.

Payment sequence

  1. Send a schema-valid POST without payment.
  2. Receive HTTP 402 and decode PAYMENT-REQUIRED.
  3. Validate the exact Base USDC requirement against budget and authority.
  4. Sign with an x402 V2-compatible EVM buyer client.
  5. Retry the identical request with PAYMENT-SIGNATURE.
  6. SignalHarness verifies, settles, checks finality, records the receipt, and executes once.

Receipts and completion

A successful response includes settlement information through PAYMENT-RESPONSE and the service response. Receipt and recovery records are server-side. A redirect, accepted signature, or transport handoff alone is not proof that payment or delivery completed.

Failure states

  • 402: no acceptable payment evidence; no service execution.
  • 4xx: invalid method, schema, size, payment, or replay; correct the request before authorizing anything new.
  • 202: payment or finality is pending; do not create another payment.
  • 409: conflicting or replayed operation; recover with the same payment and same request only.
  • 5xx/timeout: outcome may be uncertain; preserve the request and payment identity.

Safe retry rule

If the outcome is uncertain, resend only the identical service ID, method, body, and previously authorized payment evidence. SignalHarness idempotency and same-payment recovery can return the existing outcome. Never sign a second payment until the first payment is authoritatively failed or expired and the owner separately authorizes another spend.