AI agents don’t pay like humans.
They call tools in bursts, retry, fan out, and keep going—often producing dozens or hundreds of paid requests inside a single workflow. If every request has to trigger an on-chain settlement, your “agent economy” quickly becomes a gas-and-latency economy.
At FluxA, we built Open Deferred Payments (ODP) as a new payment scheme on top of x402 v2. ODP keeps the same x402 request/retry UX, but changes *how settlement happens*: verify each micropayment immediately, then settle receipts later in batches allowing the system to scale to up to 60,000 payment verifications per second.
This post is a public, high-level technical overview of ODP, plus benchmark results against the default exact scheme.
x402 in 60 seconds
x402 v2 standardizes paid access to APIs and tools using a simple pattern:
- A client calls a protected endpoint
- The server replies Payment Required and lists acceptable PaymentRequirements
- The client retries with a PaymentPayload matching one requirement
- A server or facilitator verifies the payment and (depending on the scheme) settles it now or later
The “scheme” is where most of the interesting design choices live.
Why per-request on-chain settlement doesn’t scale
The default x402 approach—exact—is straightforward:
One paid request → one settlement on-chain.
That’s a great default for “single purchase” behavior. But it becomes a bottleneck for agent workloads and high-frequency APIs:
- Latency: each request inherits chain inclusion dynamics
- Cost: gas overhead repeats linearly with request count
- Hard ceiling: the chain now determines your maximum “payments per block”
When the natural unit of work is a tool call, “one on-chain settlement per call” is simply too expensive.
Enter ODP: session-based payments with deferred settlement
ODP reframes repeated micropayments as a session:
- The payer locks funds once in an on-chain debit wallet (with a withdrawal delay so funds remain available while settlement is deferred).
- The payer signs a SessionApproval once (limits: payee, asset, max spend, expiry).
- For each paid request, the payer signs a lightweight Receipt.
- The server/facilitator verifies receipts immediately and returns the protected response without waiting for settlement.
- A settlement processor later batches receipts and settles them on-chain (enforcing strict ordering via receipt nonces).
In short: Web2-like request latency, with rollup-like settlement economics for repeated calls.
How it works
From an agent developer’s point of view:
- The server advertises scheme=odp-deferred via x402 PaymentRequired.
- The client funds a debit wallet once.
- The client opens a session by sending a signed SessionApproval (often only on the first paid call).
- Each request includes a signed Receipt; verification happens immediately.
- Settlement happens later in batches on a schedule (e.g., every N seconds), not per request.
Safety in one paragraph
ODP is “deferred,” but it isn’t “trust me.”
It stays safe by enforcing:
- Signed approvals + signed receipts
- Strict sequential nonces per session (no reuse / no gaps)
- Spend caps + expiries
- Locked funds (debit wallet) with a withdrawal delay
- Contiguous-range batch settlement on-chain (so a receipt can’t be settled twice)
Benchmark: exact vs ODP on Base Sepolia
We ran an on-chain benchmark on Base Sepolia comparing:
- x402 exact
- x402 odp-deferred (ODP)
Test highlights:
- Auto-settle interval: 30s
- Max receipts per settlement batch: 200
- Gas cost estimates assume 10 gwei and $3,200 / ETH (for a consistent comparison)
About “theoretical throughput” in this post
Instead of “payments/sec,” we report an idealized upper bound:
Max settled payments per block
- For exact, it’s driven by gas-per-settlement (≈ one settlement tx per payment).
- For ODP, it’s driven by: how many settlement txs fit in a block, and
- up to 200 receipts per settlement tx.
Using the observed settlement gas footprints from this benchmark and a 60M gas block budget (Base Sepolia at the time of test; your chain may differ), the upper bounds are approximately:
- Exact: ~700 payments / block
- ODP: ~45,000–60,000 payments / block (depending on the settlement tx mix), because each settlement tx can carry up to 200 receipts
These bounds scale roughly linearly with the block gas budget.
Results
Scenario 1: 1 session × 10 payments
Scenario 2: 10 sessions × 10 payments
Scenario 3: 20 sessions × 50 payments (1000 payments)
What this shows
ODP removes the chain from per-request latency
ODP consistently reduced average latency from ~4.4–4.9 seconds down to ~0.28–0.35 seconds in our runs. That’s the difference between “agents can chain tool calls naturally” and “agents are constantly waiting on settlement.”
Batch settlement collapses on-chain write volume
Settlement transactions dropped from:
- 10 → 1
- 100 → 10
- 1000 → 33
Fewer settlement txs is the direct driver behind the gas savings.
The on-chain ceiling shifts by orders of magnitude
In an idealized “how many payments can fit in a block” sense:
- exact is bounded by “how many settlement txs fit in a block”
- ODP is bounded by “how many settlement txs fit” × 200 receipts per settlement
That’s why the theoretical upper bound jumps from \~hundreds to tens of thousands of payments per block.
Cost advantages grow with volume
In the 1000-payment scenario, the estimated settlement cost dropped from $0.3396 to $0.0263—because ODP amortizes settlement overhead across many receipts.
Future: making batching more trustless with ZK proofs
ODP already makes settlement verifiable (signed receipts, strict nonce rules, on-chain enforcement). But there’s a natural remaining trust surface: aggregation.
A clean next step is to make the batch aggregator *cryptographically accountable*:
- The facilitator/aggregator produces a ZK proof that a batch is valid: receipts are correctly signed,
- nonces are valid and non-overlapping,
- totals are correct,
- spend limits and expiry are respected.
The on-chain settlement contract verifies one succinct proof per batch, rather than re-validating every receipt on-chain.
This pushes ODP toward a “receipts rollup” model:
- less reliance on a single trusted operator,
- more permissionless settlement (anyone can post a valid batch),
- lower on-chain verification overhead as volume grows.
FAQ
What is Open Deferred Payments (ODP)?
ODP is a payment scheme built on x402 v2 that lets AI agents make high-frequency micropayments without settling each one on-chain individually. Payments are verified immediately but settled later in batches, achieving Web2-like latency with rollup-like settlement economics.
How does ODP reduce gas costs for AI agent payments?
Instead of one on-chain transaction per payment, ODP batches up to 200 receipts into a single settlement transaction. In benchmarks, 1,000 payments reduced settlement costs from $0.34 to $0.03 — a 92% reduction.
Is ODP secure even though settlement is deferred?
Yes. ODP enforces security through signed session approvals, strict sequential nonces that prevent replay or gaps, per-session spend caps with expiry times, locked funds in a debit wallet with withdrawal delays, and contiguous-range batch settlement on-chain.
What throughput can ODP achieve compared to standard x402?
In benchmarks on Base Sepolia, standard x402 (exact scheme) supports approximately 700 payments per block. ODP supports approximately 45,000 to 60,000 payments per block by batching up to 200 receipts per settlement transaction.
How does an AI agent use ODP in practice?
The agent funds a debit wallet once, then opens a session with a signed approval specifying limits. Each paid API request includes a lightweight signed receipt that the server verifies immediately. Settlement happens automatically in batches on a schedule.