Inside x402 batch-settlement: commit now, settle later

x402 started with one idea: pay per request, settle per request. Its third scheme breaks that symmetry. With batch-settlement, the client signs a commitment at request time, gets the resource immediately, and the money moves later — rolled up, out of band, on whatever rail the network defines.

We have covered the other two schemes in this series. The exact scheme settles the precise amount on-chain before the resource is served. The upto scheme authorizes a maximum and settles actual usage. Both share an assumption: every request eventually maps to an on-chain transfer. batch-settlement drops that assumption entirely. Verification still happens per request. Settlement becomes an accounting process.

That makes it the most conventional-finance-shaped scheme in the x402 family — and, right now, the rail underneath Cloudflare's pay-per-crawl. This post walks the generic spec, the two trust models it allows, and the Cloudflare network binding that turns RFC 9421 HTTP Message Signatures into billable payment commitments.

Why per-request settlement stops making sense

The economics are straightforward. If a crawler fetches a page priced at a fraction of a cent, executing a blockchain transfer for each fetch costs more — in fees, in latency, in operational surface — than the content itself. Even with gasless primitives like EIP-3009 shifting fees to a facilitator, someone still pays per transaction, and settlement latency sits inside the request path.

Cloudflare stated the requirement plainly when it announced x402 support and the x402 Foundation in September 2025: agents and crawlers need "delayed settlement to account for disputes; and a single, aggregated payment to make their accounting simpler." Crawlers in the pay-per-crawl beta "are able to crawl a vast number of pages easily, generate audit logs, and then be charged a single fee via a connected credit card or bank account at the end of each day."

That is a different product than a stablecoin transfer per request. It is metered consumption with end-of-day invoicing — the billing model every cloud provider already runs — expressed through the x402 handshake so that the same client code can talk to both worlds.

From the "deferred" proposal to a spec'd scheme

The idea entered the protocol in two steps. Cloudflare's September 2025 post sketched a scheme literally named deferred: the 402 response carried an accepts entry with the scheme, a network identifier, the resource URL, and an extras object holding a transaction id and a termsUrl pointing at the agreement governing the deferred payment. On success, the server answered with a Payment-Response header — a receipt for a payment that had not happened yet:

# Original deferred proposal — success response
Payment-Response: scheme="deferred", network="example-network-provider",
  id="abc123", timestamp=1730872968

Two details in that sketch survived into the final design. The termsUrl acknowledges that a deferred payment is a legal relationship before it is a cryptographic one — the signature commits you to terms that live in a document, not in the payload. And the id in the response is the ancestor of the spec's commitment identifier: the reference both sides hold while the money is still in flight.

The generalized version landed in the x402 specification repository as specs/schemes/batch-settlement, added alongside a Cloudflare network specification (PR #1145) and merged into the main repo with the foundation-repo sync in April 2026. The rename matters: "deferred" described a delay; "batch-settlement" describes an architecture. The spec's one-line summary of the divergence from its siblings is precise: verification confirms the commitment is valid, but settlement stores it rather than executing a transfer.

The lifecycle: commit, accumulate, redeem

The generic spec defines three phases, and only the first one touches the request path.

This is the same decoupling we described in our own billing internals — reserve, proxy, settle — pushed one level further. There, settlement still happens per call against a prefunded balance. Here, settlement is allowed to leave the request path entirely.

What a network binding must nail down

Because the generic spec deliberately defines no concrete payload structures, no HTTP fields, and no error codes, all the load-bearing decisions move into the network binding. The spec makes seven of them mandatory. Every binding must define its commitment format and encoding; its verification rules (signature scheme, balance or credit checks, replay prevention, expiry logic); its storage behavior and what the commitment identifier contains; its double-spend prevention, so a commitment is accepted and redeemed exactly once; its expiry semantics for commitments that never get redeemed; its redemption process — who triggers it, when, and on what rail; and its trust model.

That last item is where the scheme splits into two families.

Capital-backed bindings keep the client's funds as the guarantee: pre-funded escrow, payment channels with accumulated signed receipts, or delegated wallet authorizations. No intermediary underwrites anything; if the commitments outrun the escrow, verification fails. This is the crypto-native shape — payment channels for streaming micropayments are the canonical example.

Credit-backed bindings replace capital with identity: the client is a verified entity with a billing account managed by a trusted intermediary, and settlement runs through off-chain infrastructure on a schedule. This is the shape of every net-30 invoice ever issued — and the shape Cloudflare chose.

The Cloudflare binding: cloudflare:402

The Cloudflare network specification is the first concrete binding, and it is unapologetically credit-backed: Cloudflare acts as Merchant of Record, "aggregating payment commitments, billing the identity associated with each signature agent, and distributing revenue to content owners on a periodic basis through traditional off-chain financial rails."

The network identifier is cloudflare:402 in CAIP-2 format — a namespace that names an HTTP status code rather than a blockchain, which tells you everything about where settlement lives. The accepts entry prices in the smallest unit of an ISO 4217 currency (cents of USD, not atomic units of USDC) and fixes payTo to the constant "merchant", because the actual payout routing is Cloudflare's business, not the protocol's:

{
  "scheme": "batch-settlement",
  "network": "cloudflare:402",
  "amount": "5",          // smallest unit — cents for USD
  "asset": "USD",         // ISO 4217, not a token address
  "payTo": "merchant",    // constant — routing is off-protocol
  "extra": { "version": "..." }
}

The client accepts the offer by attaching a PAYMENT-SIGNATURE header: a base64-encoded JSON payload carrying x402Version: 2, the committed amount and asset, and an accepted object echoing the requirements entry it is agreeing to. Echoing the offer back matters — it prevents a mismatch where the server verifies a signature against different terms than the client thought it was signing.

RFC 9421 as the commitment format

What makes the commitment binding is not the header itself but the HTTP Message Signature wrapped around it. The Cloudflare binding requires an RFC 9421 signature covering three components: @authority (the host being charged against, which blocks cross-origin replay), signature-agent, and payment-signature — so the payment payload is inside the signed envelope, not beside it.

# The commitment is a signed request
Signature-Agent: https://crawler.example.com
Signature-Input: sig1=("@authority" "signature-agent" "payment-signature");\
  created=...;expires=...;keyid=...;tag="web-bot-auth"
Signature: sig1=:...:
PAYMENT-SIGNATURE: <base64 x402 payload>

If this looks familiar, it should: it is the Web Bot Auth stack reused as a payment primitive. The only supported algorithm is ed25519. The supported tags are web-bot-auth and agent-browser-auth. The client publishes its public keys at a /.well-known/http-message-signatures-directory endpoint, identified by JWK thumbprint keyid, and registers that directory URL with Cloudflare to associate the signing identity with a billing account. Verification then runs in five steps: recognize the signature agent and fetch its key, verify the signature, check the committed amount and asset against the offer, check timestamp freshness (the spec suggests a window of about 30 seconds), and confirm the accepted object matches what was offered.

The consequence is elegant: identity and payment collapse into one signature. A crawler that can prove who it is can, with the same key and the same RFC, prove what it agreed to pay. Every signed request becomes an entry in an audit log that both sides can verify, and the end-of-day charge is the sum of entries. Disputes get a cryptographic paper trail instead of a server log.

The binding's error vocabulary reflects the credit model. Alongside the expected invalid_signature, invalid_payment_signature, and price_not_acceptable, there is signature_agent_unknown — your key directory is not registered with the network — and blocked, because a Merchant of Record can simply decline to extend credit. payment_failed, origin_error, and unknown round out the set.

Where the risk actually sits

Deferring settlement moves the risk; it does not remove it. The generic spec's mandatory components read like a checklist of the ways a deferred rail fails, and each maps to a concrete attack or loss scenario.

Replay is the sharpest one. In the exact scheme, replay protection is inherited from the chain — an EIP-3009 nonce can be consumed once, period. In batch-settlement, replay prevention is whatever the binding says it is. The Cloudflare binding leans on three layers: the signed @authority component (a commitment for one host cannot be replayed against another), the created/expires window with a freshness check of roughly 30 seconds, and the network's own storage marking each commitment as accepted exactly once. A binding that skimps on any layer turns one signed request into many billed ones — and unlike an on-chain double-spend, the client may only discover it on the invoice.

Expiry is the quieter failure. A commitment that is accepted but never redeemed is a liability sitting in a store: the seller has served the resource and holds a promise aging toward worthlessness. That is why the spec forces bindings to define both when unaccepted commitments become invalid and what happens to accepted-but-unredeemed ones. In credit-backed bindings this is the intermediary's problem — Cloudflare bills on its own cadence and eats collection risk as Merchant of Record. In capital-backed bindings it becomes an escrow-sizing problem: the client's locked funds must cover the worst-case window between commit and redeem, which is exactly the capital-efficiency cost the credit model exists to avoid.

Three schemes, one decision

With batch-settlement specified, x402's scheme family now covers three distinct positions on the settlement-timing axis. exact: the amount is known upfront and settles on-chain before access; trust-minimized, one transaction per request. upto: the cap is authorized upfront, actual usage settles after; still one on-chain settlement per interaction, sized to reality. batch-settlement: a signed promise per request, zero on-chain transactions in the request path, redemption on a cadence — with either capital or credit standing behind the promise.

The decision between them is the decision we mapped in the Bearer-vs-x402 walk-up tree, extended one node: how much counterparty trust does your interaction already have? Anonymous walk-up traffic wants exact — no relationship, no credit. Metered sessions with a known ceiling want upto. High-frequency, low-value, repeat-relationship traffic — crawling being the archetype — wants batch-settlement, because the relationship itself is the collateral.

Where this goes next is already visible. On July 1, 2026, Cloudflare announced the Monetization Gateway — extending the pay-per-crawl model from "charge AI crawlers for pages" to "charge any caller for any resource": APIs, datasets, MCP tool calls, with payment verification at the edge. At launch it settles in stablecoins over standard x402 (USDC among them), with a waitlist open. The two rails now run side by side under one roof: stablecoin settlement for walk-up callers, credit-backed batch commitments for registered crawlers. A seller behind Cloudflare does not choose a rail; they publish a price, and the scheme negotiation picks the rail per caller.

What it means for LLM4Agents

LLM4Agents runs a prefunded, per-call settlement model: agents deposit stablecoins, and our reserve-proxy-settle pipeline debits actual usage per request. batch-settlement is relevant to us on both sides of the counter.

As a buyer-side concern: our agents consume external resources, and an increasing share of the web's machine-readable surface is going behind Cloudflare's pricing — pay-per-crawl today, arbitrary resources via the Monetization Gateway next. An agent gateway whose outbound stack only speaks exact will be able to pay the stablecoin rail but not the commitment rail. Supporting the Cloudflare binding as a client means holding an ed25519 signing identity, publishing a key directory, registering it against a billing account, and signing outbound requests per RFC 9421 — machinery we already partially described for Web Bot Auth. Identity work and payment work have converged into the same key ceremony.

As a seller-side architecture lesson: the scheme validates a pattern we already run internally. Our billing pipeline verifies per call but batches the accounting; the spec generalizes exactly that separation and gives it a wire format. A future capital-backed binding — commitments drawn against an agent's deposited balance, redeemed in aggregate — would let us cut per-request settlement overhead for high-frequency tool calls without taking credit risk, because the escrow is already sitting with us. That is the capital-backed trust model applied to a balance we already hold.

The strategic caveat is concentration. The only shipped binding makes Cloudflare the Merchant of Record, the identity registry, and the settlement rail at once. That is the same centralization trade we flagged for x402 Bazaar: the open protocol is real, but the first operational network is a single company's edge.

Staying on the frontier

Concrete sequence, in priority order. First, add RFC 9421 request signing to our outbound HTTP stack — one signing identity per operator account, keys in the key manager and never in the LLM context, directory served at /.well-known/http-message-signatures-directory. This unblocks both Web Bot Auth verification and the Cloudflare payment binding with one investment. Second, register the signing identity with Cloudflare's crawler verification flow and test against pay-per-crawl-gated origins, so agents can consume commitment-priced content the day a workload needs it. Third, extend our x402 client to parse batch-settlement entries in accepts arrays and select schemes by policy: prefer exact for anonymous one-shots, upto for metered sessions, batch-settlement where a registered relationship exists and per-request settlement is waste. Fourth, prototype a capital-backed binding over our own deposits — signed per-call commitments against reserved balance, batch redemption into the operator ledger — and measure the settlement overhead it removes for chatty MCP workloads. Fifth, watch the spec repo: the scheme's generic layer is deliberately thin, and the next network bindings (payment channels, escrow contracts) will define whether batch settlement stays a Cloudflare product or becomes an open rail.