Keep the Change
Update (9/18/26): Settlement certificates require at least f+1 signatures: every signer validates and retains the complete close. The settlement chain selects the canonical close.
Update (9/16/26): Operators can process payments to the same recipient in parallel across payers, with one signature check covering each payer’s batch. Validators keep account balances and settlement records in QMDB, updating only what changes at each settlement.
Update (8/20/26): Clearing now uses a 32-byte commitment and BLS12-381 multisignatures for the commitment certificate.
$0.000001 payments cost more to replicate, settle onchain, and index than they’re worth. Yet your agent will need to make millions of them over the coming years.
If we can’t use blockspace to scale to a billion TPS (or at least don’t want to cover the tab of doing so), what else could we do? Payment channels are cheap and instant between two funded parties, but reaching a new recipient means opening a new channel or asking existing ones to route for you (locking their liquidity and risking forced closure along the way). Rollups either prove a batch’s state transition or publish enough transaction data for anyone to replay and challenge it. Even then, binding sequencer preconfirmations need a separate challenge for signed payments omitted from the batch (see The Unavoidable Challenge).
Bajillion is a new optimistic clearing protocol for many-to-many payments at massive scale. At each settlement, all of that activity is bound by a ~100-byte certified commitment that most chains can process. Binding receipts arrive in one round trip and provide the evidence to hold the operator accountable. Payments flow through a non-custodial operator selected by the sender: if the operator disappears or censors an account, senders and recipients alike can force recovery onchain without its cooperation. And the protocol requires only signatures and Merkle openings.
One payment or a bajillion, each account settles once.
Payments at the Speed and Scale of the Web
When payments are as common as web requests, they need to be just as fast and dirt cheap. With Bajillion, a user can pay an API provider as fast as they can load a web page.
The user chooses an operator to handle payments and settle them onchain later. For each payment, the operator issues a binding receipt promising to pay the API provider.
The user receives it in one round trip and sends it with the API request, or the operator delivers it directly to the provider to save a hop. The provider can serve the response knowing the receipt gives it evidence to hold the operator accountable if settlement omits or contradicts the payment.
The operator later nets payments across accounts without separate channels or funded routes, dramatically reducing the data needed for settlement.
Suppose a user a has 100 and wants to pay 20 to b, who has 40. The operator verifies and records a’s signed request S, then countersigns it as R. Before forwarding the receipt to b, a verifies and retains it.
Figure 1: The dotted path is an optional operator push that reaches the recipient one hop earlier. The entry accumulates amount and payment count.
Payments are grouped into settlement periods called epochs. Every signature in epoch e is tied to that epoch’s onchain anchor \mathcal A_e.
The payer tracks a balance B_a and an epoch’s total debit D_a, initially zero. It keeps a vector V_a ordered by recipient, with one entry (G,J) recording the cumulative amount and payment count for each. These entries form the leaves of a binary Merkle tree (BMT). Before the example payment, B_a=100, D_a=0, and V_a is empty.
To send x>0, a updates b’s entry and signs the updated sequence number n_a for the epoch, cumulative debit, and vector’s Merkle root. The operator countersigns this updated payer state:
S=\mathsf{Sign}_a\bigl(\mathcal A_e,\;n_a,\;D_a+x,\;\mathsf{root}(V_a\text{ with }b:(G+x,\,J+1))\bigr), \qquad R=\mathsf{CounterSign}_{\mathsf{op}}(S).
For this payment, n_a=1, D_a=20, and V_a=\{b:(20,1)\}.
The payer durably saves each request before sending it, retries the same bytes if the response is lost, and retains the verified acknowledgment and openings (Merkle proofs of the payment entries).
Optimizing for Hot Accounts
Bajillion defines each payment as an update to the payer’s outgoing vector. This lets the operator accept payments from different payers in parallel, even when they share a recipient. Existing accounts can spend incoming payments backed by a receipt within the epoch, before settlement. A payment of x from a to b updates only b’s entry in a’s vector:
(G_{ab},J_{ab})\longrightarrow(G_{ab}+x,J_{ab}+1), \qquad \text{every other entry of every other vector unchanged.}
Repeated payments from the same payer to the same recipient accumulate in one entry for the epoch.
Suppose accounts (a,b,c,d) start with balances (100,40,25,35) and make these payments:
a\xrightarrow{20}b,\quad b\xrightarrow{12}c,\quad c\xrightarrow{7}d,\quad d\xrightarrow{5}a,\quad c\xrightarrow{4}b,\quad d\xrightarrow{6}b.
b’s three incoming payments remain in their payers’ vectors:
\begin{bmatrix} \underset{a\to b}{(20,1)} & \underset{c\to b}{(4,1)} & \underset{d\to b}{(6,1)} \end{bmatrix}
One Row per Active Account
When an epoch ends, the operator builds a close, the settlement package that nets its payments into new account balances. The operator and validators derive incoming credits from each payer’s final vector: b receives 20+4+6=30 across three payments. Each entry is authenticated by its payer’s signed vector root.
Netting each of the four accounts’ debits and credits gives their closing balances: a ends at 100-20+5=85, b at 40-12+20+4+6=58, c at 25-7-4+12=26, and d at 35-5-6+7=31. The total sent equals the total received at 20+12+7+5+4+6=54, and the balances still sum to 200. The six payments change four account rows, one per account.
For each account, B_a^0 and B_a^1 are its opening and closing balances, d_a is the total it sends, and c_a is the total it receives. Deposits f_a and withdrawals w_a complete the balance equation:
\boxed{B_a^1+d_a+w_a=B_a^0+c_a+f_a.}
Every payment credits its recipient’s balance. A close creates payouts only for authorized withdrawals.
Each close records one row for every account in its published account list, even if that account’s balance does not change. The rows are sorted by account key and contain no duplicates. A sender’s row includes its last signed payer state. Every validator derives the resulting balances and checks the epoch’s total debit D_e and credit C_e:
\boxed{D_e=C_e.}
Payments only move funds between accounts, so their combined balance changes from L_e to L_{e+1} only through deposits F_e and withdrawals W_e:
\boxed{L_{e+1}=L_e+F_e-W_e.}
Without deposits or withdrawals, L_{e+1}=L_e=200.
Figure 2: A separate epoch with 100 million payments of $0.000001, one atomic unit each. Every sender uses its own opening funds. The arrows group independent payments by sender and recipient, with both directions between b and c retained in the close.
Keep the State, Send the Changes
Every validator keeps each live account’s balance under its public key. Deposits and payments can add accounts, and a zero balance removes the record.
When a payment names a new public key, the operator records a balance for it without an onchain registration transaction. The recipient can spend the balance after the close is admitted, or let payments from many senders accumulate across multiple closes before requesting a withdrawal of the full balance.
At each close, the operator publishes a shared settlement record called the dealing. It contains active account keys, senders’ final signed payer states, and cumulative payment entries. A CDN can cache this shared record for efficient distribution.
Each validator checks the payer signatures and the operator’s countersignatures, derives incoming credits, and combines them with its stored balances and the deposits and withdrawals fixed at epoch registration.
From these results, every validator derives three roots:
- The state root commits to the current positive balances.
- The activity root commits to the cumulative log of account rows and payment entries.
- The payout root commits to the cumulative log of withdrawal outputs.
Account state uses Current Ordered QMDB, an authenticated key-value store backed by a Merkle Mountain Belt (MMB). Activity and payouts use Keyless QMDBs, append-only logs backed by Merkle Mountain Ranges (MMRs).
Each close appends its sorted account rows, then its payment entries grouped by payer. A row records the account’s final debit, sequence number, and outgoing-payment BMT root. Accounts whose balances do not change still get rows in the certified range, so their receipts can still be used in challenges. A proof server can read the entries directly from QMDB to reconstruct the BMT whose root the payer signed.
A 32-byte close commitment binds these results to the operator’s dealing and the epoch’s context. Validators already hold the balances needed to compute the new state, so the dealing needs no state-change proof.
Figure 3: The close binds three validator-derived roots. The activity log appends this close’s account rows and payment entries after those from earlier closes. Below, c’s row contains the BMT root that c signs, and its two entries sum to the row’s debit of 11.
The settlement chain holds deposited funds and tracks commitments, counts, pending closes, deadlines, and claimed payout ranges. Bajillion validators store the underlying account and log records offchain.
Certifying Settlement
Assume at most f of the committee’s n validators are faulty or malicious. Before signing, every validator checks the complete close, computes the new balances and roots, and durably retains the full account and log data. A certificate requires at least q=f+1 signatures on the resulting commitment, ensuring at least one honest validator checked and holds the complete close.
The operator hashes the dealing with the epoch’s registered parameters to identify its proposal. Validators include this hash in the commitment they sign, tying their settlement results to the operator’s proposal and the previous state.
The operator can then verify the certificate and check that the proposal hash matches, without rebuilding the validators’ logs.
Figure 4: Every signer derives the same three QMDB roots before signing one close commitment. For 100 validators with at most 33 faulty members, 34 signatures suffice.
Deployments can choose their certificate scheme. With BLS12-381 multisignatures (MinSig), the certificate is one 48-byte aggregate signature plus a \lceil n/8\rceil-byte signer bitmap, with proofs of possession checked at committee registration. Including the 32-byte commitment and an eight-byte bitmap-length prefix, the total for 100 validators is 101 bytes.
The validator-derived root bundle is 184 bytes. With the eight-byte withdrawal total, it forms a 192-byte close descriptor. Sending that descriptor with the commitment and certificate takes 293 bytes before chain transaction framing. The operator’s dealing is separate.
The settlement chain selects one certified close for each epoch and adds it to an ordered queue, a step called admission. A close can become finalized only after its challenge deadline \Delta_e has passed and every earlier close has finalized. A successful challenge invalidates that close and any later pending closes that depend on it. Their withdrawal outputs never enter the finalized payout root and cannot be claimed.
The Unavoidable Challenge
A certificate establishes that the disclosed close is internally valid. The operator could still have signed a promise it left out, a limitation shared by Bajillion, ZK rollups, payment channels, and any other system offering binding preconfirmations.
Consider two executions with the same public close \mathcal D_e and certificate, proof, or attestation \zeta. In \Xi_0, the operator signs only the acknowledgments represented by the close. In \Xi_1, it also delivers a valid private acknowledgment R^+. The verifier sees the same evidence in both:
\mathsf{View}(\Xi_0)=(\mathcal D_e,\zeta)=\mathsf{View}(\Xi_1).
If it accepts \Xi_0, it must accept \Xi_1. A committee, TEE, or SNARK/STARK can verify the published inputs. Certifying those inputs cannot rule out an additional private receipt.
The certified account rows record the final activity of every account included in the close. A missing payer counts as zero debit, so a proof of absence can challenge an omitted payment. For a nonempty range, an MMR proof shows the two rows surrounding the missing key, or the first or last row if the key falls outside the range. A certified row count of zero proves that the range is empty. Strict key ordering and uniqueness make these cases exhaustive.
Receipt holders can prove three kinds of contradiction:
Debit mismatch. The close records a cumulative debit of 20 after the operator acknowledged 35.
Entry mismatch. A retained entry promises more value or more payments to a recipient than the close records.
Acknowledgment fork. The operator countersigns two different payment states at the same payer sequence number.
Because validators have already checked the accounting and signed payer states, a receipt holder can prove a contradiction in one onchain call using signatures and any required Merkle openings. Every receipt a user relies on needs an honest holder who retains it, obtains the public openings from a Bajillion validator or proof server, and gets a challenge included by \Delta_e.
Suppose b has already served the API response, but the operator leaves a’s payment of 20 out of the close. The receipt and a public proof of the omission let b prove operator fault without the operator’s cooperation. An application could use this evidence to compensate b from an onchain insurance fund, permanently exclude the operator, or support offchain resolution.
A Deadline to Exit
A successful challenge stops a contested close from finalizing, but users must still be able to get their funds out. Every account can authorize an exact withdrawal or an account close. Normally the operator includes that signed request when registering the next epoch. A censored user can instead queue it directly onchain, even during an active epoch. The next registration must include it.
Once a withdrawal request is queued onchain or included in an admitted close, the close that carries it must finalize before the signed deadline T_w to avoid a hard fault. With challenge deadline \Delta_e,
\boxed{\Delta_e<t_{\mathrm{finalize}}<T_w.}
An exact withdrawal pays the requested amount if the epoch’s final balance covers it. An account close withdraws the entire balance. Every derived withdrawal output, including a zero-valued one, is appended to one payout MMR at a stable global index. An MMR opening binds that index to the output’s destination and amount. The output has no claim deadline, and its index is never recycled.
Pending outputs become claimable only when the close that carries them reaches finality. The chain then advances its finalized payout root and count and reserves the funds to pay those withdrawals. A challenged close and any invalidated later closes change neither the finalized root nor the count, and reserve no funds.
A claim supplies the output and an MMR opening against the current finalized payout root and count. The chain groups paid indices into nonoverlapping claimed ranges, stored in an ordered map from each range’s start to its exclusive end. It rejects a claim if its index i is already covered. Otherwise it inserts [i,i+1) and merges any touching neighbors. Recording the claim, reducing the reserve, and paying the destination happen atomically. A replay is rejected even though its membership opening remains valid.
Figure 5: The MMR proves that a payout exists. Claimed ranges prevent paying it twice. Filling a gap merges neighboring ranges, so these five claims occupy one record. Only payout indices 10–14 are shown. Ranges are end-exclusive.
Each claim checks only its neighboring ranges. The chain also includes log positions without payouts in these ranges, allowing them to merge across close boundaries. Fully paid history collapses to one range. With U outstanding outputs, at most U+1 ranges remain, even under adversarial claim order.
Hard Fault
If the operator misses an admission, deposit, or withdrawal deadline, or a holder proves a fault, the deployment permanently stops new work. Earlier pending closes that are not disputed may still finalize. Recovery then freezes the last finalized state root.
The recovery rules keep finalized payouts independently claimable, with no expiry, and refund unadmitted deposits. Accounts recover their balances with QMDB proofs against the frozen root, and each account can claim only once. A close that was never admitted or was invalidated changes neither the recoverable balances nor the finalized payouts.
Even if the operator disappears, recovery depends on a correct, live settlement chain and independently available balance and payout openings. The fault also freezes the last finalized payout root and count. Later claims must use proofs against them.
Streamlined Epoch Transitions
A payment reaches finality through an admitted close, after the challenge deadline fixed at epoch registration. Shorter epochs with earlier deadlines can reduce that wait, but require more frequent preparation and certification.
Once epoch e’s close is admitted, the operator can register e+1 against its state root and start payments before e finalizes. Registration fixes deposits and signed withdrawal authorizations before the first payment is acknowledged.
Accounts without deposits or withdrawals can start paying in the new epoch while the operator is still adding incoming credits from the previous one. At the transition, the starting spendable balance \widetilde B_a is the previous epoch’s starting balance minus accepted outgoing payments, plus incoming credits already added. Let \rho_a be the remaining credit from that epoch:
\boxed{B_a^1=\widetilde B_a+\rho_a,\qquad \rho_a\ge0.}
The account can spend from \widetilde B_a immediately. Adding \rho_a to the current spendable balance preserves any payments already made in the new epoch.
In the running example, a\xrightarrow{20}b leaves 80 available to spend. The incoming d\xrightarrow{5}a brings the closing balance to 85, but has not yet been added to the spendable balance. If a spends 20 and then 15 in the new epoch while that credit arrives between them,
80-20+5-15=50=(85)-20-15.
Figure 6: Both calculations include the same incoming credit. Adding it to the spendable balance preserves payments already accepted in the new epoch.
Deposits fixed at registration are available immediately. A new account funded only by incoming credit must wait for that close to be admitted before spending. A payer with an outstanding withdrawal authorization waits until its signed deadline before signing another payment.
Atomic Batches and Collecting Fees
Because a payer can send an atomic batch of payments with one signature, an operator can require the batch to include a payment to a designated fee recipient, such as its own account.
The operator checks the requested payments and the fee for the batch before countersigning, rejecting the entire batch if the fee is insufficient. For an accepted batch, it returns one acknowledgment containing an opening for each updated entry. The payer authorizes the fee alongside the other payments, and the operator’s acknowledgment binds them together.
The operator can price each transfer type or payer independently, including volume discounts or negotiated rates. Validators net the fee entry like any other payment, and settlement uses the same commitments and proofs. The fee schedule stays with the operator, so changing it requires no protocol change.
Figure 7: The fee shares the same signed payment root as the recipient payments. Recipient b receives the countersigned payer state and an opening for its own entry.
The Cost of Settlement
We benchmarked the Commonware Library’s reference implementation with one million live accounts, a fixed pool of 512 recipients, and one recipient per payer. We vary the number of active payers A. The operator sends the dealing to validators, who derive the close descriptor and certify its commitment.
| Measurement | One million live accounts | |||
|---|---|---|---|---|
| A = 1,000 | A = 10,000 | A = 100,000 | A = 1,000,000 | |
| Operator: dealing | 103 KB | 1.03 MB | 10.3 MB | 103 MB |
| Operator: prepare | 1.15 ms | 12.1 ms | 140 ms | 1.60 s |
| Validator: durable vote | 14.0 ms | 70.7 ms | 581 ms | 6.14 s |
The close descriptor is 192 B, and the commitment with its 100-validator certificate is 101 B.
Figure 8: Means of three runs with no warmup. The validator timer covers validation, sealing, signing, and durable writes to the public and private QMDBs. It starts with an encoded dealing and the previous close’s databases already open and durably stored. Setup and reopen checks are excluded. Sizes use decimal KB and MB.
AWS c8a.4xlarge: 16 AMD EPYC vCPUs, 32 GiB RAM, and a 160 GiB gp3 EBS SSD (6,000 IOPS, 250 MiB/s, ext4). Votes wait for the filesystem to confirm durable writes to network-attached EBS. Validation and the three public databases share 16 workers, with two I/O workers. The shared cache is 1 GiB with 4 KiB pages. State/activity write buffers are 256 MiB, other write and replay buffers 8 MiB. Full state/activity sections occupy 2.1–2.3 GiB, Merkle blobs about 2 GiB. Fixtures fit in RAM. All fixtures use benchmark limits, since one million accounts exceed the account limit set at deployment.
Repeated payments between the same pairs reuse these settlement records, spreading their byte cost over more payments.
Figure 9: Every account repeatedly pays one unit to its next neighbor. More payments share the byte cost of the operator’s dealing and the 100-validator committee’s certificate. The right plot includes the 101-byte commitment and certificate. The 192-byte close descriptor is separate.
Proof Sizes and Verification
Complete challenges include the signed receipts and any required Merkle openings. These fixtures use one million live accounts, a 512-account recipient pool, and one recipient per payer. Sizes are encoded bytes.
| Complete challenge | Active payers | |||
|---|---|---|---|---|
| A = 1,000 | A = 10,000 | A = 100,000 | A = 1,000,000 | |
| Debit mismatch | 622 B present 657 B omitted | 751 B present 786 B omitted | 847 B present 882 B omitted | 943 B present 978 B omitted |
| Entry mismatch | 673 B | 802 B | 898 B | 994 B |
| Acknowledgment fork | 417 B | 417 B | 417 B | 417 B |
Figure 10: All measured challenges fit in 1 KB. An omitted payer is the absence case of debit mismatch.
A payout proof shows that a withdrawal output is included under the current finalized root.
| Payout proof | Payouts | |||
|---|---|---|---|---|
| 1 | 1,024 | 500,000 | 1,000,000 | |
| Payout claim | 105 B 402 ns | 394 B 1.23 µs | 651 B 2.04 µs | 683 B 2.15 µs |
Figure 11: Each proof includes a 30-byte output and its MMR opening, measured at the middle payout. Verification starts from decoded inputs, with times averaged over 20 samples. The trusted root and transaction framing are separate.
Balance proofs authenticate withdrawal requests and recovery claims. With one million live accounts, all three measured payloads are under 1 KB.
| Balance proof | One million live accounts |
|---|---|
| Account present | 853 B |
| Account absent | 886 B |
| Recovery claim | 884 B |
Figure 12: Current Ordered QMDB proofs after updating all one million balances. Recovery includes the account identity as well as its balance proof. The trusted root and transaction framing are separate.
Adjust the workload and committee size below to estimate the operator’s traffic.
Figure 13: Modeled operator dealing per validator, with total operator traffic in parentheses. The dotted line shows all live account records at 40 bytes each, before database overhead and retained evidence. Both axes are logarithmic. The model excludes the close descriptor, certificate, and transport framing.
Each sender signs one batch of unit payments. Recipients per account is averaged over all live accounts. Below an average of one, the first senders pay the last recipients in key order. Otherwise, every account pays its next neighbors cyclically. All accounts stay live, with no deposits or withdrawals. Estimates beyond the prototype’s per-close limits extrapolate the same encoding.
A Bajillion Payments, One Settlement
Send a million payments without paying for a million onchain transactions.
Recipients can deliver the goods as soon as they verify a binding receipt, with evidence to challenge any payment the operator later omits or contradicts. Sharing settlement costs makes small exchanges practical, down to an agent buying a single API response.
The settlement chain keeps compact commitments and merged claimed ranges, a small fraction of the total activity.