Uses: Lightning Stream

1The uses in view

A seller's own web app, paid as it is used: Released in 0.2.0. A seller's whole web app, for example Jellyfin with its full interface and films up to 4K, opens inside the buyer's app with an account made for each buyer; video is paid per MiB and pages per request. Played on mainnet between our own nodes, over a direct link and over a relay; see the 0.2.0 round and 4K and HDR.
Files, per GB: Released in 0.2.0. A shared folder (Umbrel's Downloads, StartOS's File Browser, any folder on Linux), sold per GB: a buyer downloads a file or opens it in a player of its own, and pays as it arrives, never past the file's listed size. The app has no player of its own. Bought on mainnet between our own nodes.
An AI model, paid per token: Released. A shop sells answers per 1,000 tokens, counted token by token. Tested on mainnet between our own nodes.
Hashrate, masked and paid as it arrives: Released. A hashmaker lists its miners and a hashtaker rents them into its own gateway, the Stream Gateway (DATUM-compatible), which comes with the app. Every job is masked with a key the gateway holds, so a rented miner can't tell which share is a block and can't withhold one. It mines solo to the hashtaker's own address, or on Lazarus Pool. Both sides check every share, and the hashtaker pays as the work arrives, seconds at a time. Names from Kilombino. Rentals have been paid on mainnet between our own nodes, the latest for 25 slices; in the lab 25 rentals at once each got 98 to 99% of their miners' work.
An API, a page or a file over HTTP: Released. The gateway stands in front of any web service and meters an answer per request, per byte, per token or per second. See Paying over HTTP.
A VPN exit, by the GB: Released in 0.2.0. A buyer's devices send their traffic out through another Stream user's internet connection, paid as it passes, with no account; an exit's country is checked, not believed. 315 MB went through a paid exit on mainnet between our own nodes; a fault in its charge found there is being fixed.
A shop with no web address: Released in 0.2.0. A home box sells without a domain, certificate or port forward: buyers reach it by its key over an encrypted link, through a free relay where needed, and in private mode never learn its address.
AI agents that pay: Released. A wallet an agent asks to pay over MCP, which holds the keys and keeps to rules the owner signs. See A wallet for agents.
A swarm: many sellers at once: Built, on a regtest, in the lottery's first form: 100 sellers paid at once from one 30-slot channel, where the 100 sellers were 100 gateways beside one seller node. See Many sellers at once.
Content that can be checked piece by piece: Designed, not built on tickets: the buyer checks each chunk against a signed manifest before it pays. See Paying only for what checks out.
Coming next: Paid relays, in an update; then paying from a wallet over Nostr Wallet Connect, AI sellers that are Nostr data vending machines (NIP-90), and media on Blossom servers sold through a gateway. Later ideas: ranking and search on Browse, a guard that stops a hashtaker renting toward a majority of the network's hashrate, ticket sizes that follow how fast a buyer spends, and paid torrent seeding. None of these is released; Coming next has the order.

2Paying over HTTP

Status: released, and in use on XBT mainnet. The wire is a draft of our own.

The web has kept a status code for this since 1997: 402 Payment Required, reserved for future use then and still [21]. The x402 standard, which Coinbase created and the x402 Foundation now keeps [22], gives it a shape: the server answers with a price and terms, and the client retries with a payment in a header. Lightning Stream uses that shape. The wire and the receipts were first built for the earlier channel, which is no longer in the tree. For tickets the seller's 402 has an entry of its own in its list of accepted payments, and every request of a session carries a signature over the request with the session's key; a ticket's secret travels in a release of its own. Both sides of that entry are built and run on a regtest: the gateway offers ticket terms in its 402, and the wallet's pay tool reads them and pays. The lottery has an entry of its own beside it. Its terms carry the size of a win and the price of a piece, which together fix the odds, and the buyer's half of each roll travels in a small request of its own after the piece has arrived. The tree's docs/TICKETS.md writes both down as a draft. Upstream x402 clients do not know either entry, so only Lightning Stream clients can pay with tickets or by rolls.

Figure 1. The 402 step happens once, and two tickets are locked before the first paid request. After that the wallet releases the next secret whenever the balance runs out, requests are paid from the balance, and the wallet locks the next ticket in the background. This flow now runs on a regtest between the wallet and the gateway; for what was measured see Numbers.

Each receipt is signed by the seller and bound to the hash of the request it paid for. With tickets the receipt matters more than before, because it is the only proof of payment the buyer can show: the secret proves nothing. A client that does not check its receipts has no such proof. An answer lost on the way is paid for from the balance. A refusal of a request the seller could authenticate is signed too; two answers cannot be (a request out of order, and a session the seller has forgotten), and the wallet releases nothing on their word.

For a single call from a buyer with no session, an ordinary Lightning payment is the right tool, and a seller's 402 can offer that beside tickets. Two existing forms do this: x402's exact scheme for a Lightning invoice [22] and L402 [23]. The wallet reads such an entry as x402's exact. Upstream x402 has since defined exact on Lightning; its definition has not been checked against ours, no seller in the tree offers the entry, and it was not run in the lab.

On the wire this is x402 v2. Since October 2026 the chain is named by its standard name, its CAIP-2 id [24] in the bip122 namespace, with "layer": "lightning" beside it to say that the payment is made over Lightning on that chain. Before, the entries used a name of ours, lightning:, which nobody else defines; the wallet and the gateway still read it for one release and write the new one. Because XBT and the SHA-256 chain share a genesis block, XBT mainnet is keyed to its fork block, 961,640, instead of genesis: bip122:0000000000000050c1e5f69672f45929. The scheme names, ticket and lottery, and the asset name are still ours. XBT is Bitcoin on BLAKE2b proof of work, and up to that block it has the same history as the SHA-256 chain, so its Lightning invoices look alike on both. What marks an XBT Lightning node, invoice or offer is feature bit 512, a convention of the two XBT Lightning forks [61][63] and not of ours. The wallet checks it on everything it pays, and it pays only through channels whose funding it can prove exists on XBT alone.

3Paying only for what checks out

Status: built and tested on the earlier channel, which is removed; on tickets designed and not built.

Paying per piece only helps if a bad piece can be caught. For content that exists before it is sold, such as a file, a dataset or a recorded stream, the seller first signs a manifest: the Merkle root [32] of every chunk it promises to send. Then the stream begins.

Figure 2. Streamed fair exchange, as designed for tickets. A seller that tampers with chunk 5 is paid for chunks 1 to 4, which it delivered, and nothing after. This ran on the earlier channel; on tickets it is not built.

This is where the order of a ticket turns round: the buyer checks a chunk first and releases its ticket second. The last chunk can be sold the opposite way, as an ordinary Lightning payment to a hash the seller chose, so that its key arrives only with the payment; selling a key through a hash lock goes back to Gregory Maxwell's contingent payment of 2011 [31]. Fair exchange was built and tested on the earlier channel, and it left the tree with the channel (The earlier design): chunks proved against a signed manifest, with a hash-locked last one, can no longer be bought with this code. On tickets it is designed, and simpler than it was, and the draft wire has a setting for it, but it is not built: the wallet does not buy content that way. The lottery has a first piece of it: where the wallet is given the hash of a piece, it sends its half of the roll only for a piece that matched. An agent cannot pass those hashes through the pay tool yet.

This only works for fixed content. Nobody can commit to the Merkle root of a model's answer before the answer exists. For generated output, paying as it arrives still keeps what the buyer can lose small and stated, but it cannot prove that a piece is any good.

4A wallet for agents

Status: released, against Lightning Fork nodes; tested on mainnet between our own nodes.

An AI model should be able to spend, but never to hold a key: a model can be tricked by what it reads. So the agent never signs. It asks a wallet to pay, and the wallet decides.

Figure 3. The model sees tools such as quote, pay and balance. The wallet is built so that an agent held to those tools, even a prompt-injected one, can spend only what the policy allows, with the exceptions listed below.

The wallet speaks MCP, the Model Context Protocol that Anthropic published in 2024 [26] and that AI agents already use for tools, so any agent that can call a tool can pay. It pays through the owner's own Lightning node: XBT Lightning invoices (BOLT 11) and offers (BOLT 12) [4], and, on a regtest, stream tickets and wins in the lottery through the same pay tool. A single payment the agent asks for by itself, a Lightning invoice or a payment on the chain, waits for the owner's signature from another device when it is above the owner's threshold. A paid call to a seller does not ask a person: ticket and lottery payments are bounded by the budget of the task and by the caps, and never wait for a human. The flow in which a paid call waited for the owner's approval belonged to the earlier channel and went with it (The earlier design). The policy itself is signed by the owner, so the agent cannot rewrite it.

For tickets the wallet has a ticket book. The secrets are made inside the wallet's signer, and the agent never sees one before it is spent. Each ticket is counted twice: against a cap on what may be locked when it is locked, and against the budgets when its secret leaves. A released secret is written down before it leaves the signer, so a crash cannot under-count what was spent. Routing fees are counted as spending. The ticket book is built, in the wallet's signer, and runs on a regtest against Lightning Fork nodes. It is tied to the agent's pay tool, so an agent buys a service with tickets there in one call. It holds 2 tickets with a seller the owner named and 1 with one it did not, the latter only after a prepaid ticket (A seller the owner has not named), and checks a channel's slots, its dust limit and the floor of Fee rates before a lock.

Real money only when asked for, and only to public sellers over https. The outside review found that "test networks only" was a sentence in the documents and not a guard in the code. Now it is a guard. On mainnet the wallet pays nothing until its owner confirms, in so many words, that it may pay with real money: in the app that is Settings → Your node → Pay with real money, straight after the spending rules are signed. Until then Home does not say the app is ready. The safe starter rules allow 2,000 sat a payment, 10,000 a day, 30,000 a week and 10,000 a seller, and ask the owner above 1,000; a cap is a hard cap, routing fees included. This guards against paying by omission and does no more: it makes no part of the software audited. Separately, the wallet sends nothing to a seller the owner has not named unless its address is https and every address its host has is on the public internet, so not a private, loopback or reserved one. A host whose address changes between the check and the connection (DNS rebinding) is not caught by it. A shop reached by its key has no host to check: its Lightning node must vouch for the link before the wallet sends anything.

Never more than the listing. Since 0.2.0 the price in a shop's signed listing is the most the wallet pays it; a shop that asks more is refused before anything is paid. A shop caught over-charging is blocked until the owner lifts the block with a message signed by the approval key, and each shop has a daily cap. An agent's calls are held to all of it.

For the lottery the same signer does the rolling. It makes the buyer's half of each roll from its own random source, checks the seller's half against what the seller fixed before the session, and works out every roll itself. It pays only a win it found, only by an invoice that names the seller's node and the agreed size of a win, and only once. The payment is written down as spent before it leaves, and what is booked is what the owner's node paid, with its routing fee. The owner's policy sets the largest win, how often a piece may win, and how many wins a seller the owner has not named may be paid.

The scope of the wallet's claim is narrow. It covers an agent whose only way to the wallet is the MCP tools. Software that can open the wallet's signer socket directly is outside it, so the socket must stay out of the agent's reach. The policy binds only what goes through the wallet: anyone who holds a broader credential for the Lightning node can spend past it. The policy also limits how much an allowed seller can be paid, not what else that seller does. And the outside review found faults in this very part, the wallet's budget accounting; see Status for where that stands. One rule that came out of those fixes carries over to tickets unchanged: the wallet books what it released, never a number the seller sends.

Back to the whitepaper · Draft 12, 31 October 2026.