Open Deferred Payments (ODP): Fast & Cheap Agent Payments on x402-v2
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.