Batch-settlement scheme specification for EVM

[phdargen]

Summary

Introduces the batch-settlement payment scheme specification for EVM chains, following the network agnostic specification introduced in #1145 by @CameronWhiteside.

This scheme enables capital-backed, high-throughput, low-cost payments using stateless unidirectional payment channels. Clients deposit funds into onchain escrow once and sign off-chain cumulative vouchers per request. Servers batch-claim vouchers across many channels in a single transaction and settle earned funds with a separate sweep transfer, reducing per-request latency and gas costs.

Key Features

• Fully gasless for client and server: All onchain transactions (deposits, claims, settlements, refunds, withdrawals) are relayed by the facilitator or any third party via EIP-712 signatures
• Stateless unidirectional channels: Channel identity is deterministically derived from an immutable ChannelConfig struct (channelId = keccak256(abi.encode(config))), fully reconstructible from the 402 response for recovery after client state loss
• Cumulative vouchers: Each voucher carries a monotonically increasing maxClaimableAmount; old vouchers are naturally superseded, eliminating the need for nonces
• Dynamic pricing: Clients authorize a maximum per-request, and servers charge the actual cost (actualPrice <= amount) within that ceiling
• Batched claims + sweep settlement: claimWithSignature aggregates claims across many channels (only onchain accounting, no transfers); settle sweeps claimed-but-unsettled funds to the receiver in one transfer
• Pluggable deposit collectors: Deposit via eip3009 (e.g. USDC receiveWithAuthorization) or permit2 as a universal ERC-20 fallback
• Flexible authorizer roles: payerAuthorizer supports fast ECDSA recovery (EOA) or EIP-1271 smart-wallet verification (zero address). receiverAuthorizer authorizes claims and refunds via EIP-712 and can be a server-owned address or a facilitator-provided delegate
• Cooperative refunds + timed-withdrawal escape hatch: Instant refundWithSignature when the server cooperates; initiateWithdraw / finalizeWithdraw with a 15 min – 30 day configurable delay as unilateral fallback
• Long-lived channel reuse: Channels can be topped up and reused after refund; config changes require a new channel.

Use Cases

• High-frequency pay-as-you-go API requests
• Streaming / metered API access (charge per token, data chuncks)

Links

x402BatchSettlement contract: #1950

[vercel]

@phdargen is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[pr0toshi]

Why use this for state channels not #1907?

Hub route = one channel, N payees. This is the biggest structural advantage. An agent opens one channel and pays any hub-connected API. Batch-settlement is strictly unidirectional/pairwise, a new channel (and deposit) per payer↔payee pair. For an agent calling 20 services, that's 20 escrows vs 1.

Bidirectional Bidirectional channels let funds be used for agent↔agent, user↔agent, user↔user payments. claimWithSignature makes funds not usable for state channel payments.

Doing 1 channel payer>payee shows yall are missing the whole reason for using state channels for APIs, if an API only costs $0.001 then this fucks them in gas. Hub route lets 1 channel do any payee so 1 wei payments are fine.

[pr0toshi]

If receiver are the server to then do one channel, n payees theres no flow in the spec.

[pr0toshi]

Also

{
  "scheme": "batch-settlement",
  "network": "eip155:8453",
  "amount": "100000",
  "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "payTo": "0xServerReceiverAddress",
  "maxTimeoutSeconds": 3600,
  "extra": {
    "receiverAuthorizer": "0xReceiverAuthorizerAddress",
    "withdrawDelay": 900,
    "name": "USDC",
    "version": "2"
  }
}

shows this is closed vs open source where anyone can have their own servers since there's no url. how does an API say where to sign with? the APIs could be server but then thats a new infra every API needs

[jithinraj]

Separate from the hub-routing question, I think one thing needs to be explicit in the spec is signer discovery.

The voucher model is clear. The “where does the client learn the signer or authorizer it should bind to?” path feels implicit.

Even one simple rule would help: if the authorizer is not the default receiver path, surface it in the requirement payload in a way the client can treat as authoritative for that accept entry.