Verified against @dexterai/x402 5.3.1 · 2026-07-07

Settlement and crystallization

By the end of this page you will understand what the vouchers you collect are worth before any money moves, how a walked-away buyer still pays you, and which of those steps you own versus the facilitator.

The three states of a charge

A tab charge lives in three states on its way from "delivered" to "money in your account."

1. Vouched. The buyer signs a voucher (an ed25519 signature over a running cumulative amount) for each unit you deliver. You verify it locally and keep it. A voucher is a signed promise. It is not money and it is not on chain. If you held nothing but vouchers and the buyer's session vanished, you would have proof of debt and no settlement.

2. Crystallized. A voucher is posted to the facilitator, which writes an on-chain claim against the buyer's vault for the accrued amount. Now the amount is reserved. The buyer cannot withdraw it out from under you. Crystallization is the step that converts a promise into a reservation you can count on.

3. Settled. The final voucher is posted at tab close, the reservation resolves, and USDC moves from the buyer's vault to your token account in one transaction. This is the money.

Per-call payments collapse all three into one on-chain transaction per request. Tabs pull them apart so you can deliver a thousand cheap chunks and settle once. The gap between "vouched" and "settled" is the window crystallization exists to close.

Why the reservation is not a wallet freeze

Funds stay in the buyer's vault the entire time. The tab is non-custodial: the SDK never takes the buyer's money into an intermediary, and you never hold it either. What crystallization creates is a reservation sized to the accrued amount only: the exact amount you have delivered and the buyer has signed for. It is not a hold on the buyer's whole balance. The buyer can keep spending the rest of their vault elsewhere. You are protected for what you delivered, and nothing more is locked than what you earned.

Settlement happens at tab close by default. You choose when the middleware settles with the settle option: on-close is the common case, periodic settles on a schedule while the tab stays open.

The buyer who streams and walks away

The failure you actually worry about: a buyer opens a tab, streams a few dollars of tokens, and never calls close. No close means no buyer-initiated settlement. If vouchers were all that existed, that buyer's debt would sit unsettled until they came back, which they may never do.

Crystallization is what removes that risk. As you deliver, the facilitator's engine crystallizes the delivered vouchers into on-chain claims on its own cadence, without waiting for the buyer to close. By the time a buyer abandons the tab, the amount they streamed is already reserved on chain against their vault. Their walking away no longer strands your revenue. The claim resolves to settlement whether or not the buyer ever returns.

This is why the crystallization cadence is not yours to tune. The facilitator runs a single server-side engine that protects every seller on its own schedule. Your job is to deliver and collect vouchers. The engine's job is to make sure the amounts you delivered are reserved before a buyer can disappear with them. The Sell with tabs page has the rule in code terms: leave lockCadence unset.

Two guards that stop a tab being drained

Two mechanics protect you during the stream itself, before settlement is even in question.

Delivered versus signed. The meter budgets each request against the difference between what the buyer has signed for and what you have already delivered on that tab across all requests, not against the lifetime signed total. A buyer cannot reuse an old high voucher to pull more service than they have paid for on a channel they have already drawn down. The delivered total is monotonic and never resets.

One live stream per tab. Each tab channel carries a single-stream lease. Only one live stream can hold it at a time. This stops a buyer opening two concurrent streams on the same tab, both reading the same delivered baseline, and over-delivering against a single voucher. The lease has a time-to-live so a crashed stream's hold expires instead of blocking the buyer's next request. If you run more than one server instance, read the multi-instance note on the Sell with tabs page. The lease is only atomic within one process unless you back it with a cross-process store.

There is also a resume floor. When a session's first voucher arrives, the middleware reads the session's on-chain odometers and seeds a fresh channel's delivered baseline to whichever is higher of what has already settled or crystallized. A resumed session cannot re-consume budget that was already turned into money or into a reservation. You never deliver twice against the same dollar.

What you can see, and what you cannot

The seller SDK gives you accrual counters through the tab handle on each request: the cumulative amount the buyer has signed for and the amount you have delivered. It does not give you a settlement event. There is no callback that fires when a crystallized claim resolves to a settled transaction, because that transaction is produced on the buyer's side at close and the settlement signature is returned to the buyer, not pushed to you.

To confirm settled money, watch your own USDC token account on chain, or reconcile against the facilitator. During the stream, trust that a crystallized amount is protected. After close, trust the chain. Do not treat a stack of valid vouchers as settled revenue until the account balance says so.