x402 · agent payments · payment channels · 13 September 2026
x402 batch settlement: minDeposit, prepaid channels and spend caps
x402 batch settlement is built for agents that repeatedly buy small API calls. Instead of putting every request onchain, the buyer deposits funds into a channel once, signs cumulative vouchers offchain, and the seller claims and settles them later. That speed comes with a different risk boundary: the amount locked in the channel can be materially larger than the price of the next request.
Published 13 September 2026 · sources checked 13 September 2026
10×
current TypeScript server default for the announced minDeposit hint
5×
current client depositMultiplier default when no valid minDeposit hint is used
3×
documented minimum depositMultiplier
Why this changed
minDeposit makes channel sizing part of the 402 negotiation
On 7 September 2026, the x402 project documented and shipped an optional extra.minDeposit hint for EVM batch settlement. Current documentation says servers always include a resolved hint in the payment requirements. The default server target is ten times the per-request amount, while a route may override it with an atomic integer or a money string for a default asset.
A valid client uses the announced target instead of its fallback amount × depositMultiplier calculation. The documented client multiplier defaults to five, with three as the minimum. That means the server can ask for a larger opening balance to reduce top-up frequency, while the buyer still needs an independent policy for how much capital it is willing to lock.
The important accounting distinction is simple: minDeposit is not the price of the next API response. It is a proposed channel-funding target. Treating the two as the same can make an autonomous buyer approve substantially more exposure than the request itself appears to cost.
Economic state machine
Separate request price, locked capital and settled value
| Boundary | Meaning | Operator rule |
|---|---|---|
| Per-request amount | The advertised route amount remains the maximum for one request. | Do not confuse one-call price with channel deposit size. |
| minDeposit hint | Server-announced target for opening or topping up the channel. | Treat it as capital-locking input, not the price of one response. |
| Spend cap | Buyer policy can clamp how much is automatically deposited. | Set it explicitly for autonomous buyers. |
| Voucher | Cumulative off-chain authorization representing total claimable value. | Persist monotonic state and reject stale or conflicting vouchers. |
| Claim / settle | Seller aggregates voucher value and moves funds onchain later. | Delivery can precede final onchain settlement. |
| Refund | Unused channel balance can be recovered through the scheme's close/refund path. | Recovery rules and withdraw delay belong in buyer risk policy. |
Buyer guardrail
Do not let a server hint become an unlimited capital-allocation instruction
Current x402 documentation says spendControls.maxAmountPerPayment is passed into scheme selection so a capital-locking scheme can reuse the buyer's existing payment policy. For batch settlement, the automatic deposit is clamped to the spend cap multiplied by the deposit multiplier. If no spend cap is configured, the automatic deposit is not bounded by that mechanism.
Autonomous buyers should therefore evaluate at least three numbers before opening or topping up a channel: the per-request maximum, the server's requested deposit target, and the buyer's own maximum acceptable locked balance for that seller. A purchase can be cheap while the requested channel funding is comparatively large.
For stricter control, the SDK also exposes a deposit strategy that can cap the proposed deposit or decline an automatic top-up. That is a better enforcement layer than asking the language model to remember an informal budget.
Server enforcement
The hint and the enforcement switch are different things
A server can announce a minDeposit without rejecting smaller deposits. Current TypeScript documentation says enforceMinDeposit defaults to false. When enforcement is enabled, a deposit below the resolved minimum is rejected with invalid_batch_settlement_evm_deposit_below_min_deposit. The facilitator itself does not enforce that server minimum.
That distinction matters when debugging a 402 loop. A buyer that caps the requested deposit below the server's hint may still succeed against a non-enforcing server, but it may repeatedly receive a rejection from an enforcing one. Inspect the returned error and the accepted payment requirements before blindly increasing the deposit.
Production reliability
Fast vouchers still require durable economic state
The server delivers paid responses after verifying off-chain vouchers, before every unit of value has individually settled onchain. It therefore has to preserve the latest voucher and channel state until claim, settlement and refund work is complete. The x402 documentation recommends durable server storage in production; Redis or Valkey is the documented fit for serverless or multi-instance deployments.
Buyers need the same economic discipline. A crash or timeout should not create a new channel or a larger top-up until the existing channel state has been reconciled. The payment channel is durable financial state even when the HTTP request that used it was short-lived.
Scheme choice
Use batch settlement when repeat volume justifies locked capital
| x402 scheme | Best fit | Primary buyer risk |
|---|---|---|
| exact | Fixed-price, simple or occasional purchases. | Paying for the wrong resource or retrying a settled purchase. |
| upto | Usage-based calls where the final charge may be below an authorised ceiling. | Granting a ceiling that is too large or accepting incorrect metering. |
| batch-settlement | Many repeated low-value calls to a seller where off-chain vouchers reduce latency and settlement overhead. | Locking more capital than intended, losing channel state, or failing to reconcile claims/refunds. |
Operator checklist
Before an autonomous buyer accepts batch settlement
- 1. Confirm the facilitator advertises batch-settlement for the intended network.
- 2. Read the per-request amount and
extra.minDepositas separate economic values. - 3. Apply a hard buyer-side spend/capital-locking cap before opening or topping up.
- 4. Decide whether a server-requested minimum above policy should be rejected rather than automatically raised.
- 5. Persist or reliably recover channel identity and cumulative voucher state across retries and restarts.
- 6. Reconcile claim, settlement and refund evidence separately from HTTP delivery success.
- 7. Prefer
exactfor low-frequency sellers when the efficiency gain does not justify prepaid exposure.
Primary sources
Read the current scheme documentation before shipping
The implementation details above are based on the current x402 Foundation batch-settlement documentation and repository state checked on 13 September 2026. Batch settlement is a newer scheme and SDK/facilitator support can move quickly.
Continue
Verify the seller, then choose the smallest authority that fits the workload
Usage-based
x402 upto: metered billing and Permit2
Compare a per-request spending ceiling with a prepaid batch-settlement channel.
Trust
Verify an x402 API before paying
Check payment requirements, seller identity and delivery expectations before funding.
Retries
Retry x402 requests without duplicate payment
Keep logical purchase identity stable across HTTP retries and recovery.
Machine API
Inspect zFinia's machine services
See machine-readable service contracts, current prices and API entry points.