Governed payments

The payment domain is where governance stops being advisory. The model is a border crossing:

A DNA record is a passport (who you are). A mandate is a visa (permission for a specific class of trip). A passport alone gets you nothing at the gate. The kernel checks both, every time.

A payment executes only when the full chain passes:

identity → policy → mandate drawdown → spend ceiling reservation → rail

The pieces

• Mandates (payment visas) — human-signed spending authority, produced by a WebAuthn passkey ceremony. Approvers enrol credentials (POST /v1/approvers/credentials); their signatures issue mandates with a budget, use count, and expiry. Drawdown is a single atomic statement — settlement on a stablecoin rail is irreversible, so a single-use mandate that two concurrent payments both claim is money gone twice, not a bookkeeping error. Zones can require mandate enforcement wholesale.
• Spend ceilings — per-agent, per-currency limits in native minor units, with in-flight reservations so concurrent payments cannot race past the ceiling between the ledger sum and the ledger commit. Posture is configurable: allow (no covering ceiling = unlimited) or deny (no covering ceiling = refused).
• Payee registry — zone-scoped payee aliases with per-payee caps, maker-checker enforced: the identity that registers a payee (POST /v1/payees, created PENDING) can never be the one that approves it (POST /v1/payees/{id}/approve → APPROVED), and edits reset the payee to PENDING for fresh approval. /v1/x402/authorize binds the counterparty to the registered payee, so a quote cannot be redirected to an unregistered address.
• Rails — payment execution is rail-agnostic behind a Rail interface (authorize → outcome), with x402 (EIP-3009 transferWithAuthorization) as the reference rail. Deferred outcomes hold the spend reservation until an independent witness settles them.
• Receipts — /v1/x402/settle signs a receipt tagged for exactly what it proves; /v1/proxy/receipt-key publishes the verification key.

Buy side — the kernel spends on the agent’s behalf

Surface	What it does
POST /v1/x402/fetch	Fetch a URL; if the server answers 402, the kernel governs the quote, signs payment, retries, and audits
POST /v1/x402/authorize + POST /v1/x402/settle	Authorization oracle for quotes that reached the agent out of band (A2A) — govern, sign, settle, receipt
POST /v1/proxy/fetch	Rail-neutral spend proxy with durable idempotency keys — the agent never holds a wallet key
GET /v1/x402/budget	What the caller may still spend

The spend proxy requires a client-supplied idempotency_key — retries replay the recorded outcome instead of paying twice. When a price crosses the escalation threshold the kernel answers 202 with an approval_id; a human approves in the console, and the agent collects by retrying with the same idempotency key plus that id. Declines carry stable reason codes you can branch on — MERCHANT_NOT_ALLOWLISTED, CEILING_EXCEEDED, POLICY_BLOCK, PRICE_CHANGED — while error strings stay free to change. Worked requests are in the integration guide.

Sell side — the kernel charges for what it serves

The x402 paywall enforces settle-before-serve on configured routes: a request without payment gets a 402 challenge; the kernel verifies the EIP-3009 authorization cryptographically before serving. Supports per-route pricing, credit packs (POST /v1/x402/packs/...), KYA (know-your-agent) tiers, and a revenue view (GET /v1/x402/revenue).

Try it offline

The whole flow runs locally with no blockchain and no hosted facilitator — cmd/x402-seller speaks the real x402 v2 wire protocol and recovers the signing address exactly the way a token contract would on-chain:

scripts/x402-demo-up.sh

Then, in two terminals:

scripts/x402-try-allowed.sh

scripts/x402-try-blocked.sh