Lightning Stream
Menu

Whitepaper · Progress and status

Progress and status

Where Lightning Stream stands: what is built and what is not, what has run and where, what has been reviewed, and what comes next. Lightning Stream 0.2.0 is released for Umbrel, StartOS and Linux, and has been tested on XBT mainnet between our own nodes.

This page accompanies Draft 12 of the Lightning Stream whitepaper, 31 October 2026, and version 0.2.0. Back to the whitepaper.

1Status and limits

Released
Version 0.2.0, 31 October 2026: one app for buying and selling, for Umbrel (a community store of ours), StartOS (our registry, https://registry.lazarus-xbt.xyz) and Linux (Docker Compose). The current version and every change are in the changelog; Try it has the setup.
On mainnet
Since 26 October 2026, between our own nodes: a fresh install from the published packages bought films and AI answers from our shop, a node box of ours bought from a second shop of ours, and a rental of hashrate was paid, every charge matching the meter to the millisatoshi. On StartOS the app's node key, through Lightning Fork's grant, was tested on mainnet; a paid buy there has not run yet. See On mainnet. Before 0.2.0, a round with real sats bought files, a web app over a direct link and over a relay, and AI answers from our demo shop Lightning Stream Genesis, exact to the millisatoshi; rented hashrate for 25 slices; and sent 315 MB through a paid VPN exit. It found two faults in paying, a VPN exit that charged too little and a test slice of hashrate that ran unpaid, both now fixed (The 0.2.0 round). Nobody outside the project has used it yet.
Reviewed, not audited
Chris Guida reviewed the earlier design and its published code in October 2026, and then, in a second review that read the code without running it, the ticket design, the lottery and the tree as they stood on 13 October; the move onto Lightning and most of Draft 9 follow from his two reviews. Kyle Santiago read the design and pointed out the slot and dust limits the defaults are built around. In October 2026, machine-assisted reviews of the payment code found further faults, among them a way for another page on the same machine to start a payment, and bookkeeping that could undercount after a restart; all are fixed in 0.1.15. Nobody outside the project has reviewed the fixes, and there has been no independent audit. The win that pays itself waits for a cryptographer's reading. Treat it all as unaudited software.
Next
A small test with people outside the project, by invitation, with amounts they can afford to lose; then a paid buy on StartOS, and the work under Coming next.
Trade-offs
Money moves a ticket at a time, and a dishonest shop can keep a ticket or two per answer it is sending, plus a small allowance per request, before it is caught and blocked; one that cheats inside that bound is not caught, which is why each shop has a daily cap. A web app over a relay on a slow path starts slowly: 15 to 25 s for a 4K film in our lab. Unused held tickets are locked until cancelled or expired, and unspent prepaid credit stays with a seller until the buyer returns. A seller needs an lnd-family Lightning node with room to receive, online while it serves; a Core Lightning node cannot sell held tickets today. Paid by lottery, income and cost are uneven in the short run. The Lightning nodes on both sides hold hot keys. XBT's Lightning network is young and small, so a route may not exist; a direct channel to the shop always works.

2Released in 0.2.0

In the app
  • The wallet and its spending rules: budgets, per-shop daily and weekly caps, an approval threshold, allowed sellers only, all signed by the owner with an approval key; safe starter rules; a confirmation before it pays with real money.
  • Tickets: prepaid and held, metered to the millisatoshi, with a signed receipt for every answer, paid as you use it, and credit kept with a seller across restarts and address changes. Several requests to one seller run side by side in one session, each exactly accounted.
  • Buyer protections: a shop is paid no more than its listing shows, for every service; a file is never paid past its listed size; an AI reply never past its quoted price; a shop caught over-charging is blocked until the owner lifts the block with the approval key; a shop that loses requests is held to what they could have cost; each shop has a daily cap. A busy service refuses new buyers before they pay.
  • Services to sell and buy: a seller's own web app, such as Jellyfin with its full interface and an account for each buyer; Files, a shared folder sold per GB to download or open in your own player (Umbrel's Downloads, StartOS's File Browser, any folder on Linux); an AI model per token, with an OpenAI-compatible address on the buyer's box; hashrate, rented into the Stream Gateway (DATUM-compatible) that comes with the app, which masks every job so a rented miner can't withhold a block, mining solo or on Lazarus Pool and paid as the work arrives, with a paid test slice and a signed history; and VPN exits, by the GB, with exits checked for the country they claim. The built-in player is gone.
  • Shops without a web address: a shop reached by its key alone over an encrypted link, vouched for by its Lightning node, with no domain, certificate or port forward; relays where the two ends cannot meet, which never see what they carry; a private mode that uses relays only; four link keys per shop so relayed buyers share several connections. A relay is built into the app, off by default and free.
  • Agents: the same wallet over MCP, and the box's own AI address.
Built, not in the app's everyday path
The lottery, in the form where the buyer pays after a win, run on a regtest with 100 sellers paid at once (The lottery as built). Pay with work, where a miner pays with pool shares.
Not built
The win that pays itself: not before a cryptographer has reviewed the argument it rests on. Fair exchange on held tickets. A seller's software for a Core Lightning node.

3Coming next

None of this is released. The order is the one we have agreed; each item ships when it is built and checked.

  1. Paid relays, in an update. A shop pays the relays that carry its traffic, by the GB. Relays stay free until then.
  2. Paying over Nostr Wallet Connect: buying from a wallet the buyer controls, instead of a Lightning node of one's own.
  3. AI sellers that are data vending machines on Nostr (NIP-90), as another source for the box's AI address.
  4. Blossom: media on a Blossom server, sold per MiB through a Stream gateway in front of it.

Later ideas, not yet ordered: ranking and search on Browse; a guard that stops a hashrate rental whose work stops following the public chain, against a majority attack; local links for TV and phone apps; remote miners reaching a DATUM Gateway without a port forward; ticket sizes that follow how fast a buyer spends; paid torrent seeding; and files checked piece by piece as they download.

4Packages for node boxes

Most people who run a Lightning node run it on a home box. Lightning Stream is one app on each: it buys, sells and rents hashrate, beside the box's own Knots-BLAKE2b and Lightning Fork, which come from Paul's store and registry. The images it runs are published on GitHub's container registry for three kinds of processor, and each package names its images by digest, so a box gets exactly the image that was checked.

Umbrel
From our community store. The app makes its own narrow keys on the box's node, so there is nothing to paste. An update keeps your keys, rules and settings.
StartOS
From our registry, with Lightning Fork from Paul's registry, https://start9.paulscode.com/. The app asks Lightning Fork for its own key through Lightning Fork's Grant app access, which Paul built: the owner approves it there, and can revoke it there. The key can pay and read, and nothing more. Selling still needs the shop's invoice keys pasted on the Sell page.
Linux
Docker Compose beside your own Knots and Lightning Fork, from the same images, with a guide in the source tree (docs/LINUX.md). On a Raspberry Pi 4 all eight of its containers started in about 10 s and idled in 18 MB of memory together, measured before a node was attached.
A shop without a web address
Since 0.2.0 a shop needs no https address: buyers reach it by its key over an encrypted link, through a relay where the two ends cannot meet. A shop can still use an https address with a publicly trusted certificate; a shop reached only over Tor cannot be paid yet.

5The earlier design

The first version of Lightning Stream did not carry payments over Lightning. It used its own one-way payment channel on the chain: Jeremy Spilman's channel of 2013 [1], in the CHECKLOCKTIMEVERIFY form that BIP 65 gives as one of its examples [2]. The buyer locked coins once in an output on the chain, signed a slightly larger running total for every piece, and the seller settled once. To reach many sellers with one channel it added a hub, with each forwarded payment locked by an adaptor signature [16][17][18]. A hub that forwards payments it cannot take was not new either: TumbleBit [19] and A2L [20] are its ancestors.

Chris Guida's review of the published code (October 2026) found the hub the weakest part. One-way channels with no revocation give a hub nothing to fall back on when a channel closes or is replaced while a payment is in flight, and that is the problem Lightning's commitment protocol [3] was built to solve. The review advised using Lightning for what a network is good at, reaching many sellers, and keeping the direct channel as a fast path. We went further and moved the whole payment path onto Lightning.

The hub is retired
Its code, tests and packages have been removed from the tree, and they remain in its history, last at commit 0911cc0. Lightning's own routing replaces it. The 59 stated limits that belonged to the hub, to the hub beside a Lightning node and to the routed client go with it.
The on-chain channel is removed
It was frozen on 11 October 2026, when the payment path moved onto Lightning, and nothing new was built on it after that. Once tickets ran end to end and the lottery was built, it was taken out of the tree, later in October 2026: tickets and the lottery do its job on Lightning, and the channel carried the open defects that were left. With it went its provider and its client, the wallet's channel rail, the light client that watched the chain for it, the fair exchange built on its states (Paying only for what checks out), the flow in which a paid call waited for the owner's approval (A wallet for agents), and their tests, vectors and scripts. The code stays in the history, last at commit 1ad0c48. The two Python reference repositories still hold the channel.
What the removal leaves behind
Three things. A wallet that was upgraded with channels on record cannot close or refund them with this version: it leaves their records and sealed keys untouched and says which revision settles them. The wallet pays sellers over Lightning only; its Umbrel and StartOS packages have since been redone to use the box's Lightning node (Packages). And the channel's one remaining case, a seller who cannot run a Lightning node, is given up: such a seller has no rail here, and pay with work is the other way in. Nobody has reviewed the removal.
What the channel did that tickets do not
It settled each piece exactly, it left nothing in flight when a buyer stopped, and its seller needed no Lightning node. Tickets give those three up, as What it gives and what it costs says. What they bring is Lightning's routing in place of a hub, and no transaction on the chain for each buyer and seller.

An earlier draft of this paper had a section, "Beside Lightning", which argued that Lightning could not hold a buyer's coins under a lock for the length of a session. Hold invoices do that, for a ticket at a time. That section no longer describes Lightning Stream.

6Changes by draft

Draft 12, 31 October 2026
For version 0.2.0. The services are web apps, Files, AI, hashrate and VPN exits, and the built-in player is gone. Shops can be reached by key, through free relays. The buyer protections are stated in full, and Tests and numbers adds the load test, relay scaling, 4K and HDR, hashrate under load and the 0.2.0 round with real sats. This page now lists what comes next, in order.
Draft 11, 27 October 2026
The app is released, and these pages say so. The whitepaper is shorter, a new page, Try it, has the setup, and Tests and numbers has the first runs of the released app on mainnet. Tickets are now about 900 sat, so a ticket and its fee fit under the starter rules' approval line.
Draft 10, 22 October 2026
The whitepaper is cut to the idea, and the detail moved to four pages: design details, tests and numbers, this page, and uses. Nothing in the design or the code changed with it.
Draft 9, 18 October 2026
Answering a second outside review, with packages for node boxes. Most of what was new came from Chris Guida's second review: the claim of "no change to the node" is narrowed to the nodes it holds for (How a ticket works); the costs are given at three fee rates, with a floor for held tickets that follows from them (Fee rates); a seller the owner has not named is paid a prepaid ticket first; the lottery's limits are tighter and its horizon is stated (The lottery); the software refuses mainnet unless it is asked for; the evidence can be checked from outside; and there are packages for Umbrel and StartOS (Packages).

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