A way to pay for AI by the token, in small increments, where neither the buyer nor the seller has to trust the other one.
The buyer counts the tokens it was actually given — not the ones it was told about. That single sentence is the whole idea. Everything else is bookkeeping around it.
Imagine filling your car at a petrol station where the display faces away from you. The attendant watches the numbers, stops when they like, and tells you what you owe. You have no way to check. You can set a limit beforehand — “no more than forty pounds” — but within that limit, whatever they say is what you pay.
That is the current state of buying language-model output. The price depends on how much the model writes, which nobody knows in advance. The seller counts it. The seller reports it. The buyer pays it.
For a fifth of a cent, disputing that isn’t worth anyone’s time — which is exactly why an inflated number is safe to send. The amounts are too small to argue over and too numerous to audit. Multiply by a million requests a day and the rounding error becomes the business model.
For thirty years, paying tiny amounts online has been impossible for a dull reason: card networks charge a fixed fee per transaction, so anything under a few cents costs more to collect than it is worth. The web went to subscriptions and advertising instead — not because those were better, but because the payment floor left nothing else.
That floor is why we ended up with accounts. To buy from a company you must first register with it, hand over a card, and top up a balance. Fine when you deal with five suppliers. Absurd when the buyer is an AI agent that might call forty different services in the course of one task, most of which it has never used before and will never use again.
Public ledgers removed the fee floor. What they didn’t remove is the trust problem: cheap settlement lets you pay a stranger a fraction of a cent, but it doesn’t tell you whether the stranger delivered what they charged for. Cheap money without verifiable measurement just means being overcharged faster.
The current standard for machine payments over the web revives an old idea — the HTTP response “402 Payment Required”, reserved in 1997 and unused ever since. It works well, and it settles unilaterally: the seller reports what it used, and the only thing checked is that the figure doesn’t exceed the cap. That is a reasonable arrangement between parties who already trust each other. Between strangers, it is the petrol pump again.
Everything below follows from one change: after each delivery, the buyer measures it too, using the same counting method the seller named before any money moved. Both sides sign their own figure.
The seller’s number stops being an invoice and becomes a claim, standing next to the buyer’s claim. If the two are close, the lower one is billed. If they are not, the session stops and the disputed delivery is never paid for.
The second change bounds what any of this can cost. The buyer never authorises a whole session — only one slice at a time.
One reserved slice of language. In the example terms used here, a babel is 550 tokens — roughly two paragraphs, worth about a fifth of a cent. The buyer authorises one babel, receives it, counts it, agrees it, and only then authorises the next.
The babel is the exposure bound: it is the most either party can lose if the other one turns dishonest mid-session, and the buyer knows the figure before agreeing to anything. Named the way the bel is — a unit of a thing that is otherwise hard to measure — and after the tower, which is where everyone stopped being able to agree on words.
The idea of reserving a quota rather than billing per unit or per session isn’t new. Telephone networks settled on it in the 1990s for exactly this reason: metering every second is too expensive, and trusting the total at the end is too risky. Reserve, spend, reserve again.
A session is this loop, repeated. Each pass produces a signed receipt that replaces the one before it.
Price per token, babel size, which counting method it uses, how long the buyer has to respond. The seller signs all of it, so it cannot quietly change later.
The money for the session goes into a single coin on Kaspa, guarded by a small program rather than by either party. Neither side can take it unilaterally.
Never the session. This is the step that bounds the loss.
Along with the content comes a fingerprint of the exact bytes sent, and the seller’s own token count.
It checks the fingerprint against the bytes it received — catching a seller that describes different content than it sent — then counts the tokens itself.
If the figures are close enough, both sides sign a receipt for the running total. If not, the session stops.
Each receipt carries the running totals and points back at the previous one, so the session forms an unbroken chain. Only the latest receipt matters — it supersedes everything before it. A hundred babels still settle in a single transaction.
If the counts differ by more than the agreed tolerance, the session halts. Everything already agreed settles normally; the disputed babel never becomes a receipt, and nobody pays for it.
There is no arbitration, because an arbiter would have to be trusted — and the point of the design is that nobody is. Halting costs the honest party one babel. That is the price of not needing a judge.
A small tolerance is necessary rather than sloppy. Two honest parties counting the same text genuinely disagree by one token about once in every 1,250 deliveries, purely from where the boundaries fell. Zero tolerance would halt honest sessions.
But a tolerance is also a place to hide. Someone could shade every single babel by one token in their own favour and never trip the limit. So both sides watch the running direction of the disagreements as well as their size: honest noise wanders both ways, while shaving drifts steadily one way. A persistent drift halts the session even though no single delivery ever broke the rule.
Kaspa is not involved during the session. It holds the funds and decides how they may leave. The program guarding them is about 500 bytes and understands two moves.
Anyone may publish the latest receipt, provided both parties signed it. It pays nobody yet — it records the claim and restarts a response window. A newer receipt replaces an older one, so an out-of-date claim can always be overridden by the real one.
Once the window passes with no newer receipt, the money is released: the seller gets exactly what the final receipt says it earned, the buyer gets the rest. If no receipt was ever posted, the buyer gets everything back.
This is what makes a session safe to walk away from. A seller that goes silent cannot strand the buyer’s money — the buyer waits out the window and takes it back. A buyer that vanishes mid-session cannot deny the seller what it already agreed to pay — the seller posts the last signed receipt and collects. Neither side needs the other to cooperate at the end, which is the property that makes trading with strangers reasonable.
With one obligation attached, and it falls on the seller. That window is also a deadline: it is counted from the moment the money was locked, and each posted receipt restarts it. If it runs out with nothing posted, the buyer takes everything back — including payment for work already delivered and already agreed. Holding a signed receipt you never posted is holding evidence of a debt the network is about to release.
That is a deadline rather than a vigil, and the difference matters. The seller already holds the receipt it needs, an older one can never overwrite a newer one, and a seller is a server — online because serving is the business. So it posts before the clock runs out, and chooses how much it is willing to let accrue between postings. That figure is the seller’s own version of the babel: a number picked in advance rather than a hope.
At intervals during the session, a fingerprint of the current receipt is also written to Kaspa as a timestamped record. It costs about 0.002 KAS, holds nothing up, and lets either party later prove a given receipt existed by a certain moment.
The babel is the buyer’s exposure, so smaller is better. Two things stop it from being arbitrarily small, and they are not the same constraint.
The first is obvious: the cost of settling. If closing a session costs a dollar, slices worth a fifth of a cent are absurd. Cheap settlement is table stakes, and plenty of networks have it.
The second is the one that catches people out: how fast blocks are produced. Remember the ending — post a receipt, wait a window, then the money is released. That window has to be long enough for the other party to notice a stale receipt and replace it with the real one. And it is counted in blocks, because that is what the timer mechanism understands. It has no concept of minutes.
So the same safety margin costs wildly different amounts of real time depending on how fast the network produces blocks:
Funds locked, waiting, before either party can walk away with them.
The same 600-block window. Measured live: 11.1 blocks per second.
That is not a tuning difference. Four days of locked capital per session makes the idea a curiosity; sixty seconds makes it something an agent can use forty times in an afternoon. The block rate is not a detail of the settlement layer — it sets how long anyone’s money is trapped.
In an ordinary blockchain, blocks form a single line. When two miners find a block at the same moment, only one can be in that line — the other is discarded, along with the work that produced it. The faster blocks come, the more often that collision happens, and the more of the network’s security is thrown in the bin.
That is why Bitcoin waits ten minutes. It is not caution; it is the cost of insisting the history be a single line.
Kaspa is not a chain. It is a blockDAG. Blocks may reference several predecessors at once, so blocks found simultaneously are all kept and then put in a consistent order, rather than one surviving and the rest being deleted. Nothing is wasted, so the rate can rise without security falling away.
The speed is a property of the shape of the ledger, not a dial someone turned up. That distinction is the whole reason a sixty-second dispute window exists to be used.
The guarding program must be able to say “the seller receives exactly this amount and the buyer receives the rest”. Most networks’ scripts can only say who may spend a coin, not where it must go. Kaspa gained that ability — a covenant — and without it the ending cannot be enforced at all.
A session’s funds are a specific coin with a program attached, not a balance in a shared account. A thousand sessions running at once never queue behind each other or contend over the same record. For traffic generated by software rather than people, that is the difference between working and not.
Kaspa is proof of work with no validator set to join, no stake to post and no list to be admitted to. A buyer that is a piece of software does not register with anyone before it starts spending — which is the point of the exercise.
None of the four is unique on its own. What is unusual is having them together: sub-cent settlement, second-scale block times, programs that constrain their outputs, and no gatekeeper. Remove any one and the numbers on this page stop working.
Two-sided measurement only works if two independent implementations, given identical text, return an identical number. That is far easier to get wrong than it sounds, and each rule below exists because the failure was measured rather than imagined.
| What goes wrong | How wrong | The rule |
|---|---|---|
| Counting each piece of a stream as it arrives, rather than waiting for the whole delivery | up to 21.5%, always in the seller’s favour | Reassemble before counting |
| Using a different counting method than the one named | 40.9% on Chinese, Japanese and Korean text | The method is named up front and must be obtainable by both sides |
| Cutting the session into slices at arbitrary points | disagreement 7.6% of the time | Babels tile from the start — which drops it to 0.08% |
| Assuming two honest parties always match exactly | off by one token in 0.08% of deliveries | Tolerance must be at least one token |
There is a fifth, subtler version: the two sides may run the same counting method written in different programming languages. Those can agree on a total while splitting the text differently — which then diverges on the next piece of text rather than this one. So the implementations are checked against each other boundary by boundary, on deliberately awful input: mixed scripts, emoji, flags, combining marks, pathological whitespace.
Nothing here is specific to language models. The pattern fits any trade where the quantity cannot be known in advance, both parties can measure it, and the sums are too small to argue about.
An AI agent working through a task may call dozens of services it has no account with and will never call again. It cannot pause for a human to approve each one, and it cannot register with all of them. It needs to pay a stranger a fraction of a cent and verify it got what it paid for.
Someone running a fine-tuned model on their own hardware can charge for it directly — no card processing, no chargebacks, no minimum spend, no signup for the buyer. The barrier to selling inference drops to the cost of hosting it.
Distributed inference and rendering networks currently need a trusted operator in the middle to hold funds and adjudicate disputes. Two-sided measurement removes the operator from the money path — the buyer verifies delivery itself.
Any service billed by how much was actually delivered has the same shape: an amount neither side knows up front, and a seller whose word is currently the only record. The unit changes; the machinery does not.
metered is the primitive; these are the first things built with it. Same two-sided count, same kaspa-x402 escrow rail — only the unit changes.
Sell a download by the byte. The buyer pays for the bytes that arrived and counts them itself; a stalled transfer costs nothing for what never came. — read the one-pager.
Tune in and pay for the seconds that actually play. Stop mid-stream and the meter stops with you, to the byte — recordings and live feeds alike. — read the one-pager.
Almost every marketplace exists because two strangers cannot verify each other. The platform holds the money, settles the arguments, and charges both sides for the privilege — and it has to be trusted by everyone, which is why there are so few of them and why they are so large.
Metering removes the reason for the middle. When the buyer can measure what it received, and the network enforces the ending whether or not anyone cooperates, a stranger is just a counterparty. Trading with one stops requiring an introduction.
That matters most for the buyers who are about to outnumber us. Software agents will make far more purchases than people do, each one too small to invoice, too fast to approve, and too numerous to audit. They need a way to buy from anyone, check what they got, and walk away — without asking permission first.