When not to settle probabilistically

Sub-cent API calls have an awkward cost structure. On x402's default path each call is one on-chain transfer, and on Base a transfer costs about as much gas as a $0.001 call is worth. The textbook fix is thirty years old: instead of charging a cent every time, charge a dollar one time in a hundred. Expected revenue is the same, and there are a hundred times fewer transfers.

We built that for x402, measured where it would actually help, and the answer was: almost nowhere. What the measurement did show is that the market is mostly paying for the wrong settlement scheme — and that choosing the scheme per resource saves far more than any one scheme does. This page is the short version.

What we built

A sparse ticket is a Permit2 authorization for a ticket value T — say $1 — against a verifier contract. The facilitator commits to a secret before the buyer signs; after the buyer signs, it reveals the secret, and the ticket wins if a hash of the buyer's signed digest and the secret falls below p / T. A winner moves T to the merchant in one transfer. A loser moves nothing, and no one can settle it later: the contract is the only spender, and it checks the odds itself.

That last property is what earlier proposals to bring lottery tickets to x402 did not have, and it is what makes the scheme usable from an ordinary wallet — no deposit, no channel, no escrow. It reduces to four rules the contract enforces:

1. Only the verifier can move the funds, and only the named facilitator can call it.
2. Funds move only if the revealed secret matches the commitment and the roll is under the threshold.
3. The threshold is recomputed from the price and the ticket value, so the advertised odds are the settled odds.
4. The buyer's signature covers the purchase ID, so one purchase gets one roll.

What the x402 index looks like

We pulled Coinbase's public x402 index in full: 14,964 resources and 487,261 reported calls over thirty days. Price alone has been reported before. What we added is recurrence — calls per paying address — crossed with price:

Two things stand out.

The buyers and the calls are in different places. At least 61% of payer–resource pairs are provably single-call, and the largest group is single-call and sub-cent. But 91% of calls come from repeat relationships.

The cheap schemes for repeat traffic exist and are barely offered. batch-settlement and Circle Gateway both make repeat traffic nearly free to settle. Resources that offer either account for at most 4.8% of calls — and every one of them also offers plain exact.

The index doesn't say whether a "call" is a paid call or any request. If only a tenth were paid, the repeat share falls from 91% to 47%. The direction holds; the headline number is an upper bound.

Four things that bound the ticket

A ticket can only be as large as the smallest of four limits.

The merchant's variance. With n calls a month, the realized revenue has a coefficient of variation of √((T/p − 1) / n). Keeping that under 20% means T ≤ p · (1 + n/25). A tenfold reduction in transfers therefore needs at least 225 calls a month, and a resource with one call a month can carry a ticket only 4% above its price.

The buyer's exposure. A buyer who makes one call at $0.01 with a $1 ticket isn't paying a cent. They're paying a dollar, one time in a hundred.

The client's cap — which already exists. The x402 reference client filters payment options before any policy runs, with a default cap of

export const DEFAULT_MAX_AMOUNT_PER_PAYMENT: Money = "$1";

Coinbase's agent-wallet documentation uses $0.05 per call as its example. A $1 ticket on a $0.001 resource is fine; a $5 ticket is never seen.

Onboarding. EIP-3009, the default exact path, costs the buyer nothing up front. Every Permit2 path, this one included, costs a first-time buyer one approval transaction. The classical lottery-ticket literature never had to account for this, because it assumed the buyer already had a bank account or an escrow.

Where it pays

With the reference client's $1 cap, the region where a ticket cuts transfers tenfold holds 25 of 11,630 low-recurrence resources — 3% of all calls. With the $0.05 cap, it holds 22. Demand a fiftyfold reduction and it holds none.

In the group the scheme was designed for — single-call, sub-cent — the median ticket reduces transfers by 4%. A sparse settlement costs slightly more gas than a plain transfer, so for 3,648 of those 4,716 resources the scheme can never pay for itself, however many buyers come back.

The mechanism works. It just has almost nowhere to work today.

The more useful result: choosing per resource

Since no single scheme fits the index, we measured what it costs to pick one scheme for everything, against picking per resource. Settlement gas for the month, at $0.002 per transaction:

Always-sparse looks cheapest only until you count the approval transaction every new buyer has to make; with half or all of the buyers new, it costs $122 or $141. The "best possible" figure is a hindsight bound — it can never lose, so it proves nothing on its own. The rule is what counts, because a merchant could deploy it today:

mean calls per payer above 2               → a channel or gateway
otherwise, 100+ payers and a price ≤ $0.10 → offer a sparse ticket alongside exact
otherwise                                  → exact

We held that rule fixed and changed everything around it: gas price, how long deposits last, the merchant's tolerance, the client's cap, and contract gas costs — 288 combinations in all. The rule beats the best single scheme in 195 of them. Most of the losses come from one situation: deposits that last six months or more, where a channel for everyone is cheaper. That tells a runtime the one number it has to measure before choosing: how long its buyers' deposits actually last.

The best single scheme also changes with the assumptions. At some settings it's channels; at others it's sparse tickets. A merchant who picks one scheme on principle is betting on conditions they haven't measured.

Measured gas

We wrote the verifier contract and ran it against the real Permit2 bytecode from Base.

Adjusted for USDC's own transfer overhead, a sparse settlement costs 0.91 to 1.11 times a plain transfer. We also checked that the contract rejects a wrong caller, a price above the signed one, a wrong secret, and an inflated threshold.

What it means for Tollstile

Tollstile set out to be protocol-neutral: the same merchant lifecycle over x402, MPP, L402, or whatever comes next. This study argues for the next step, which is to be regime-aware as well.

The runtime already has what it needs. Its ledger knows each resource's call rate, how many buyers it has, and how often they come back. x402 already lets a server offer several payment options in one 402 and lets the client choose between them. What's missing is the rule that connects the two, and that is what selectRegime() in the experimental packages/sparse sketches.

What we haven't measured

Three things the public index can't tell us, and which way each would push the result:

• What a "call" is. If many reported calls are unpaid probes, there is less real volume, and the region shrinks. We tested this: it goes from 25 to 22.
• Who the buyer is across resources. A buyer who calls fifty resources once each looks single-call everywhere, but that buyer would happily fund a gateway balance. Knowing this would shrink the region.
• How many buyers already have a Permit2 approval. This is the one that pushes the other way. If every buyer already had one, the sub-cent resources where sparse settlement wins would grow from 63 to 1,068. This is on-chain, and it's the measurement most likely to make the scheme look better than this study does.

A second snapshot of the index at the end of October will test the rule out of sample: fixed on September's data, scored on October's.

Read more

• Paper: When Not to Settle Probabilistically, working draft v0.9 (PDF, pre-release) — the full argument, including the threat model (selective abort, replay, and what they require of the merchant's ledger), related work, and references.
• Code: packages/sparse — the rail, an in-memory facilitator, the verifier contract, the gas benchmark, and a Base Sepolia harness. It is private and experimental.
• Data and scripts: research/sparse-settlement — each table above can be regenerated from a snapshot of the index.