Protocol deep dive

The x402 protocol,
governed.

x402 v2 makes HTTP 402 real: agents paying for resources in USDC, per request, in seconds. Sumway implements the protocol on both sides — with policy limits, optional signed-agent verification, and a tamper-evident audit record.

x402 v2 · CAIP-2USDC · EIP-3009CAP_X402_OUTSettle-before-serveOptional KYA identitySHA-256 ledger

The protocol in 30 seconds

Three steps.
Three headers.

01

402 + PAYMENT-REQUIRED

An agent requests a paid resource. The server answers HTTP 402 with a PAYMENT-REQUIRED header containing a v2 challenge: price, asset (USDC), recipient address, and CAIP-2 settlement network.

02

PAYMENT-SIGNATURE

The agent retries with a PAYMENT-SIGNATURE header carrying a signed EIP-3009 authorization — a gasless USDC transfer the seller can settle without holding the buyer's keys.

03

200 OK + PAYMENT-RESPONSE

The seller verifies the signature, settles through a facilitator, and serves the content with a PAYMENT-RESPONSE receipt. Sub-cent payments, seconds to settle.

The mapping

What x402 specifies.
What Sumway adds.

The protocol defines the wire format. It deliberately says nothing about who may spend, how much, on whose authority, or how you prove it later. That silence is where Sumway lives.

402 challenge

x402 protocol

Price, asset, and payTo advertised per resource

Sumway kernel

Per-route price table; payTo is operator-configured. Use dedicated treasury or revenue addresses in production.

PAYMENT-SIGNATURE payload

x402 protocol

Signed EIP-3009 USDC authorization

Sumway kernel

The gateway’s configured signing key signs after policy checks; agents never receive that key. Managed or HSM-backed custody is required for production deployment.

Capability to spend

x402 protocol

Not specified by the protocol

Sumway kernel

CAP_X402_OUT gates x402 micropayments separately from wire/ACH; no capability → blocked and written to the ledger

Spend limits

x402 protocol

Not specified by the protocol

Sumway kernel

Atomic per-agent spend ceilings with reservations — concurrent payments cannot race past a cap; micro-unit money, no float

Agent identity check

x402 protocol

Any valid signature is a valid payer

Sumway kernel

Optional Know-Your-Agent verification checks the signed agent request before settlement. Binding an agent identity to the settling payer address is a planned control.

Settlement

x402 protocol

Seller settles via facilitator, then serves

Sumway kernel

Settle-before-serve, fail-closed: no settled payment and durable audit record → no content, ever

Replay & recovery

x402 protocol

Nonce embedded in the authorization

Sumway kernel

Settled-nonce store: replays are rejected; a same-nonce retry after a failed audit write recovers the stuck settlement and serves

Repeat buyers

x402 protocol

Pay per request

Sumway kernel

Credit packs purchased over x402 itself — prepaid credits drawn down per request, every sale on the ledger

Choosing a seller

x402 protocol

Buyer picks an endpoint

Sumway kernel

Ranked provider selection under kernel caps — agents automatically pay the cheapest qualifying seller

Audit

x402 protocol

PAYMENT-RESPONSE receipt

Sumway kernel

SHA-256 hash-chained ledger entry for every decision; revenue is a distinct ledger action that never counts against spend ceilings

Both sides of the transaction

Buying and selling,
end to end.

BUY SIDE · kernel-held wallet
> agent → kernel: POST /v1/x402/fetch { url }
> kernel: CAP_X402_OUT presentOK
> kernel → seller: GET /api/data402
price $0.05 USDC · payTo 0x8f3…c21
> kernel: reserve $0.05 against ceilingRESERVED
> kernel: sign EIP-3009 (agent never receives signing key)SIGNED
> kernel → seller: GET + PAYMENT-SIGNATURE200 OK
ledger: spend $0.05 · receipt · hash chain intactRECORDED
SELL SIDE · settle-before-serve paywall
> buyer → paywall: GET /premium/report402
price $0.10 USDC · payTo configured revenue address
> buyer → paywall: GET + PAYMENT-SIGNATURE
> paywall: verify EIP-712 signature locallyOK
> paywall: optional KYA identity checkOPTIONAL
> paywall → facilitator: settleSETTLED
> paywall: write revenue audit entryRECORDED
paywall → buyer: content + PAYMENT-RESPONSE200 OK

API surface

Four endpoints.
Whole economy.

Agents integrate by calling the kernel — they never hold keys, never talk to a facilitator, never see a nonce. Sellers integrate by wrapping any HTTP handler with the paywall middleware and a price table.

POST/v1/x402/fetch

Buy side — fetch a paid resource through the kernel wallet, under capability and ceiling checks

GET/v1/x402/budget

Buy side — an agent's remaining spend ceiling and reservation state

POST/v1/x402/packs/:id

Sell side — purchase a credit pack over x402; credits draw down on later requests

GET/v1/x402/revenue

Sell side — settled paywall earnings, backed by revenue entries on the ledger

The invariants

If a payment can't be proven,
it didn't happen.

Everything above is subordinate to one rule: no durable audit record, no resource. A path that serves paid content without a settled, audited payment is a design bug — not a feature.

Settle-before-serve: a request that fails facilitator settlement gets a fresh 402, never the content.

If settlement succeeds but the audit write fails, the paywall returns 500 and does not serve — the buyer's same-nonce retry recovers and serves once the record exists.

Revenue entries use a distinct ledger action: paywall earnings can never be confused with agent spend or count against any ceiling.

No capability, no ceiling headroom, or failed required identity verification → the payment does not fire, and the block is written to the hash-chained ledger.

Put your first endpoint
behind a 402.

Sumway is in private deployment. If you're building in the x402 ecosystem — buying, selling, or both — we'd like to talk.