Lazarus XBT

Lightning Stream · UsesWhat it is for

The uses Lightning Stream was conceived for, and how far each has come. Each says plainly whether it is built, run only as a demo, designed, or only conceived. What is marked released is in the app for Umbrel, StartOS and Linux and runs on XBT mainnet; the rest ran on a regtest, a private test network of our own.

This page accompanies Draft 11 of the Lightning Stream whitepaper, 27 October 2026. Back to the whitepaper.

1The uses in view

A film or other media, paid as it plays
Released. A shop sells films per MiB and the app plays them as they arrive, paying for the bytes it receives. Tested on mainnet between our own nodes; see On mainnet.
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, paid after delivery
Released. A hashmaker lists its miners and a hashtaker rents them into its own DATUM Gateway, paying for each slice after it is delivered: only shares its own gateway accepted are counted. Names from Kilombino. One rental has been paid on mainnet between our own nodes.
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.
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.
Planned
The AI model offered to Nostr clients as a data vending machine (NIP-90), paying from a wallet over Nostr Wallet Connect, ranking and search on Browse, and a guard that stops a hashtaker renting toward a majority of the network's hashrate. None of these is released.

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.

One paid call with tickets: request, 402 with terms, two tickets locked, then a release carries one secret, and requests paid from the balance get data and a signed receipt. Buyer (an agent) Seller (an API) GET /forecast 402 · price · seller's node · ticket terms first: 2 hashes sent, 2 hold invoices paid over Lightning release: the secret of one ticket then GET /forecast, paid from the balance hash the secret, find its ticket, collect, serve 200 OK · data · receipt signed by seller
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.

Chunks are checked against the signed manifest and a ticket is released for each; a chunk that fails its proof is not paid and the stream stops. Signed manifest root = H(chunk 1…8) Each chunk arrives with a proof. Check it, then release a ticket for it. 1 2 3 4 5 6 7 8 verified · ticket released bad proof never paid The seller risks one chunk. A chunk that fails its proof is not paid for.
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 per piece still limits what the buyer can lose to one ticket, 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.

The agent asks the policy wallet to pay over MCP; the wallet holds the keys, enforces the owner's signed policy and pays through the owner's Lightning node. AI agent asks; cannot sign MCP Policy wallet holds the keys and the ticket secrets daily budget · per-seller caps allowed sellers only human approval, single payments only tamper-evident log of what it released Owner signs the policy Owner's Lightning node invoices · offers · tickets
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.

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 11, 27 October 2026.