Payguard protocol
A seller-side boundary that makes settlement a necessary condition for releasing paid work.
Safety invariant
No successful paid response is released before successful settlement. Verification is necessary, but never sufficient.
- Bind the request to an immutable route-policy digest.
- Verify the bounded payment signature against the exact requirements.
- Settle, then attach immutable settlement evidence.
- Encrypt and durably cache the bounded upstream response.
- Move to Released and return the exact cached response.
Route policy
Each revision pins method, path template, Base network, native USDC asset, recipient, exact atomic amount, facilitator origin, upstream origin, byte ceilings, timeout, MIME type, and retention. Editing creates a new immutable revision; activation changes only the route pointer.
network: eip155:8453 asset: 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 scheme: exact amount: 1000000 payTo: 0x…
Held states
- SettlementUnknown
- The outcome cannot be safely classified. Do not release or blindly settle again; reconcile first.
- SettledDeliveryFailed
- Settlement succeeded but response delivery failed. Preserve evidence and route to recovery/refund review.
- Rejected / Expired
- No paid response is released. A new valid payment may be offered when appropriate.
Control-plane API
Wallet authentication uses a one-time EIP-4361 message. Tenant reads require a session and organization membership; browser mutations also require a same-origin CSRF token.
Open OpenAPI JSONGET /api/attempts?organizationId=<uuid>&state=SettlementUnknown GET /api/attempts/<id>/evidence?organizationId=<uuid> POST /api/attempts/<id>/remediation?organizationId=<uuid> GET /api/exports/attempts.csv?organizationId=<uuid>
x402 v2 headers
PAYMENT-REQUIREDcarries the exact challenge.PAYMENT-SIGNATUREcarries the bounded buyer payment payload.PAYMENT-RESPONSEis released with the settled response.
Payment signatures and raw upstream bodies are never returned by dashboard APIs or written to application logs.