x402
A design for an x402 HTTP-payment-protocol adapter, letting a PolicyVault-delegated agent pay for resources under covenant-enforced limits.
Status: DESIGNED. Nothing described on this page is implemented, unit-tested, VM-verified, testnet-verified, or production-hardened yet. No production file, covenant byte, or configuration is changed by this design. It documents the intended shape of an x402 adapter so integrators can understand where PolicyVault would sit in an x402 flow.
What x402 is
x402 is an HTTP-native payment protocol: a resource server answers 402 Payment Required with a machine-readable statement of what it will accept, and the client retries the identical request carrying a signed payment payload.
The role PolicyVault plays — and never plays
| x402 role | PolicyVault |
|---|---|
| Client / payer | In scope — the only role. An AI agent with a PolicyVault-delegated agent key pays for a resource, under covenant-enforced caps, budgets, allowlists, and approval tiers. |
| Resource server / seller | Out of scope, permanently. PolicyVault is free forever, including commercial use; it never charges for its own protocol, covenant, SDK, API, security features, or ordinary usage, and must never emit a 402 for its own API. |
| Facilitator | Out of scope. A facilitator verifies and settles on someone else's behalf — a custodial-adjacent posture PolicyVault does not take. |
Receiving x402 payments into a PolicyVault vault needs no adapter at all — receiving KAS is just an address, not a covenant spend.
How a payment would be mapped onto the pipeline
An x402 PaymentRequired response would be normalized into a closed, strictly-typed intent under the same trust classification PolicyVault already applies to any externally supplied instruction — every field either passed through unchanged, derived, or rejected, never guessed. That intent would then flow through the exact same intent → build → sign → finalize → submit → reconcile pipeline as any other agent spend: the same policy checks, the same mandatory dry-run simulation, the same local intent verification before any signature, the same machine identity and scopes model for authenticating the calling agent. A protocol-level retry must never be able to duplicate a spend, so payment idempotency-key derivation is a first-class part of the design.
An honest, open gap
x402 (as published) assumes payment settles in the same call that unlocks the resource. PolicyVault's covenant-enforced model requires signing and submitting a real transaction, which cannot be forced to complete synchronously inside an HTTP request/response the way some other payment rails can. The design documents this gap and a proposed extension point rather than inventing protocol behavior x402 does not actually specify.
Deployment boundary
An x402 adapter, if built, would run as a separate module/process from PolicyVault's core — so that its absence, a crash, or its compromise degrades only x402-specific functionality and never the core vault pipeline, exactly like the MCP server and other agent-facing adapters.