Lightning Stream
Menu

Whitepaper

Lightning Stream: pay as it arrives

Anyone who runs a Lightning node should be able to sell a service to the network (a film, an AI model, hashrate, an API, software of their own) and be paid for it piece by piece as it is delivered, by people and by AI agents alike.

Lightning Stream does that on ordinary XBT Lightning, paid as you use it. Money moves in small tickets; the seller counts what it delivers to the millisatoshi and signs a receipt for every answer. A shop is never paid more than its listing shows, and a dishonest one can keep at most a ticket or two for each answer it is sending, plus a small allowance per request; one that charges past that is caught and blocked. For pieces too small to pay one by one, a fair roll decides which pieces are paid.

Draft 12 · 31 October 2026 · Lightning Stream 0.2.0 (source). The app is released for Umbrel, StartOS and Linux and runs on XBT mainnet: Try it says how. It has been tested on mainnet between our own nodes, with small amounts, and is not audited; see Status.

Lightning made payments fast. Stream tickets make them continuous.

1The problem

More and more of what we buy arrives over time: the tokens of a model's answer, the minutes of a film, the work of a miner, the thousandth call to an API. Machines are now buyers as often as people, and the prices are tiny.

Most ways to pay for that ask someone to trust someone. Pay up front and you trust the seller to deliver; pay afterwards and the seller trusts you; a subscription trusts a company with your card. Lightning [3] already moves small payments between strangers in a moment, with nobody holding the money in the middle. What it lacks is a way to pay for something that arrives in thousands of pieces without making every piece wait for a payment of its own. Lightning Stream adds that part, and leaves the rest of Lightning as it is.

2The idea

Pay a small ticket as the service starts. Let the seller draw it down, exactly, as it delivers. Pay the next ticket as it runs out. A held ticket that is never used comes back, and credit left over is spent first the next time.

A session with tickets: keep two small payments locked, release one each time the balance runs out and lock the next, and get the unused ones back. BEFORE THE SERVICE WHILE IT RUNS · ONE TICKET AT A TIME AT THE END 1 · Commit Buyer pays 2 tickets 2 × 900 sat 1 2 3 4 5 6 7 used · paid committed, not used 2 · Pay: when the credit runs out, the next ticket is spent. The next is ready before it is needed. 3 · Stop Unused held tickets 1,800 sat come back Held tickets the seller never cancels expire, and the money returns by itself.
Figure 1. Tickets in a session. Here the service used five tickets' worth. Only two are ever locked at a time, and the two left at the end were never the seller's to take.

That is the whole addition. Lightning Stream is built on Lightning, not beside it: Lightning's own routing, liquidity and nodes carry everything, and Lightning Stream runs no network and no hub, and never holds anyone's money. Each person pays from, and is paid to, their own node. A seller needs an lnd-family node, in practice Lightning Fork [61], the fork of lnd [62] that runs on XBT. A Core Lightning node can buy and route, but cannot sell held tickets today.

3How a ticket works

A ticket is an ordinary Lightning payment of under 1,000 sat: about 900 at today's shops. It comes in two kinds.

A prepaid ticket is a plain payment the seller collects as it arrives. The seller then serves from that credit and counts every request against it in millisatoshis. This is what most calls on mainnet use today.

A held ticket turns an ordinary payment round. Normally the seller picks the secret that unlocks a payment, so the money is the seller's the moment it arrives. With a held ticket the buyer picks the secret, so the payment sits committed along the route and nobody can take it until the buyer releases the secret.

The buyer keeps the secret; routing nodes and the seller see only its hash until the buyer releases the secret to the seller. Buyer's wallet keeps the secret Routing nodes see only the hash Seller has only the hash locked · 900 sat locked · 900 sat later, in a release: the secret Only now can the seller collect this ticket. It still cannot touch the next one.
Figure 2. A held ticket is committed along an ordinary Lightning route, and nobody can take it, because only the buyer knows the secret.
Terms
The seller answers the first request with its price and terms: its Lightning node, the size of a ticket and how long one lives.
Lock
For a held ticket the wallet sends only the hash of its secret, and the seller's node issues a hold invoice, which can be paid but not collected until the secret is shown. Hold invoices are Joost Jager's, in lnd since 2019 [5].
Pay
When the credit runs out, the wallet pays the next ticket, or releases the next secret. No request waits for a payment: the next ticket is ready in the background.
Stop
The seller cancels unused held tickets and the money is free at once. If it does not, they expire and the money returns by itself.

A payment the payer releases in a second step is Hiroki Gondo's idea, "stuckless payments" [6]; held tickets get that effect from hold invoices, which Lightning nodes already have. Its price is that the secret no longer proves payment. The proof is the seller's signed receipt, bound to each request, together with the payment on the buyer's own node.

What each side risks. A shop is never paid more than its listing shows: a price above it is refused before anything is paid, and a file is never paid past the size its listing gives. Within that, a dishonest shop can keep the credit the buyer's app has with it at that moment, a ticket or two for each answer it is sending, plus a small allowance for each request: up to 16 MiB of data at its own price, an AI reply's quoted price, or a request priced by the second up to its limit. A shop that charges past that is caught: the app stops paying it and blocks it by its node, its receipt key and its address, until the owner lifts the block with the approval key. One that cheats inside the bound is not caught, so the owner's rules also cap what any one shop is paid in a day and in a week. Unused held tickets are locked, not lost, for a few hours at most. The seller serves only from credit it has been paid or a ticket it has collected. docs/TICKETS.md states the bound exactly.

Why tickets stay small and few. A held ticket takes a payment slot on every channel it crosses, and a payment below a channel's dust limit cannot be claimed on the chain. So the wallet holds only a couple of tickets at a time, never below 546 sat, and at mainnet's fee rates it prepays rather than holding a ticket through a routing node. Kyle Santiago pointed out both limits, and the defaults follow from them. Slots and dust has the figures.

4Smaller than a ticket: the lottery

Some pieces are worth less than any payment worth sending: a tenth of a sat for one piece of a file shared by forty sellers. The answer is old, and it is David Wheeler's and Ronald Rivest's [33][34]: roll a fair die for each piece. Most rolls pay nothing; now and then one wins and pays an amount worth sending. The odds make the average the price. At a tenth of a sat a piece and a win of 64 sat, one piece in 640 wins.

Each piece is a roll made from a half the seller fixed beforehand and a half the buyer sends after the piece arrives; most rolls pay nothing and a win pays 64 sat. Seller's half fixed before the first piece + Buyer's half sent after the piece arrives The roll both sides can check it 640 PIECES AT A TENTH OF A SAT EACH · ONE WIN EXPECTED 0 0 0 0 0 0 0 0 0 0 64 0 0 0 0 0 most rolls: nothing to pay a win · 64 sat On average the buyer pays the price: 640 × 0.1 sat = 64 sat.
Figure 3. One roll for each piece. The seller's half was fixed before the session and the buyer's half comes after the piece, so neither can choose the result, and both can check it.

Neither side can steer a roll: the seller fixes its half of every roll before the session, the buyer adds its half after each piece arrives, and both can work out the result. The price is exact on average and uneven in a short run, the way a miner's income is. In the form that is built, the buyer pays after a win with an ordinary Lightning payment, so nothing is locked and a buyer can pay many sellers at once. Its weakness is plain: a buyer can see a win and not pay, and a seller stops serving such a buyer after about one win. A form in which a win pays itself, first built by Gerhart, Taylor and Thyagarajan [44], is designed and will not be built before a cryptographer has reviewed it. The lottery in detail has both.

5The wallet: paying over HTTP, within rules you sign

A seller puts a gateway in front of a web service it already runs. The gateway answers a first request with 402 Payment Required and its terms, in the shape the x402 standard gives that status [22], and signs a receipt for every answer after that.

The buyer's side is a wallet that holds the keys and pays through the owner's own Lightning node. It was made first for the hardest case, an AI agent, which should be able to spend but never to hold a key, because a model can be tricked by what it reads. The agent asks the wallet to pay, over the Model Context Protocol [26], and the wallet decides. A person uses the same wallet through the app.

  • Spending rules the owner signs. 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. Only sellers the owner allowed are paid.
  • Real money only when asked for. On mainnet the wallet pays nothing until the owner confirms, in so many words, that it pays with real money.
  • Its own books. It counts what its own node paid, routing fees included, never a number a seller sends, and a cap is a hard cap.
  • Never more than the listing. The price in a shop's signed listing is the most the wallet pays it, for web apps, files, AI, hashrate and VPN exits alike; a shop that asks more is refused before anything is paid.
  • A cheat is blocked. A shop caught over-charging is blocked until the owner lifts the block with a signed message. A shop that loses requests is held to what they could have cost. Each shop has a daily cap.

Many requests at once. A web page asks for many things at the same time. Several requests to one seller run side by side in one session, each exactly accounted, so a busy page does not wait on itself. However an answer ends (whole, cut short, or reported late), the wallet believes the seller's charge by one rule, and a charge above it is the seller's fault. A busy service refuses new buyers before they pay, and the buyers it is already serving stay served.

6What it sells

Web apps
A seller's own web app, for example Jellyfin with its full interface, opened inside the buyer's app, with an account made for each buyer. Video is priced per MiB and pages per request, paid as they are used, under a limit the buyer sets for the visit. A web app's live connections stay open for up to six hours, paid as their bytes pass.
Files
A folder on the seller's box, priced per GB. A buyer downloads a file or opens it in a player of its own (VLC, mpv, a TV app) and pays as it arrives. The app has no player of its own: media is shared as a web app or as Files.
An AI model
Priced per 1,000 tokens of its answer, counted token by token; a reply is never paid past its quoted price. The buyer's box gets an address that AI apps and agents on its network can use as they would any OpenAI-compatible service.
Hashrate
A hashmaker lists its miners and a hashtaker rents them into its own gateway, the Stream Gateway, which comes with the app and speaks DATUM [66]. It masks every job with a key it holds, so a rented miner can't tell which share is a block and can't withhold one, and it mines solo to the hashtaker's own address or on Lazarus Pool. Both sides check every share's proof of work, and the hashtaker pays as the work arrives: it never has more paid for and not yet received than a minute of the miner's hashing, or one share, one slice and one ticket if that is more, plus any start fee shown on the offer. Rentals run over the encrypted link, a hashtaker can buy a short paid test slice first, and a hashmaker publishes a signed history of what it delivered. (Names from Kilombino.)
VPN exits
A buyer's devices send their traffic out through another Stream user's internet connection, paid by the GB as it passes, with no account. An exit's country is checked, not believed, and if no exit fits a device's rules its traffic stops rather than leaving by the buyer's own connection.
Any web service
The gateway meters an answer per request, per byte, per token or per second, so nothing in it is specific to these.

Buying and selling are one app. A shop's offer is a listing it signs and publishes on Nostr relays, so buyers can find it without a directory of ours.

A shop needs no web address. It is named by its key, and a buyer's app reaches it over an encrypted link straight to the seller's gateway, through both home routers where it can: no domain, certificate, tunnel or port forward. The shop's Lightning node signs for each of its link keys, and the buyer's app checks that before it sends anything, so it knows it is talking to the shop it pays. Payment works as it does over https: the same terms, tickets, metering and signed receipts.

Where the two ends cannot connect directly, a relay carries the traffic. It is encrypted end to end, so the relay never sees what is sent, and it never carries money. In private mode a shop uses relays only, so buyers never learn its address. A shop serves on four link keys, each with its own relay connection, so its relayed buyers share several connections instead of one; through a relay limited as ours is, one, two and four keys carried 46, 91 and 182 Mbit/s (Relay scaling). A relay is built into the app, off by default, and relays are free to use. Paid relays, where a shop pays the relays it uses by the GB, come in an update.

8What it costs

A Lightning node on each side
A buyer needs a node with a channel; a seller needs an lnd-family node with room to receive, online while it serves.
Money tied up
Unused held tickets are locked until cancelled or expired, for hours if a seller vanishes. Unspent credit on a prepaid ticket stays with that seller until the buyer comes back.
Routing
Each ticket pays the usual routing fee. Held tickets take slots on every channel of their route, which is why they stay few, small and short-lived [10].
An uneven lottery
Paid by lottery, income and cost even out only over many wins, and the seller goes first by about one win per new buyer.
A relay is slower
Straight links and https add little: a 4K film started within about 1.5 s of the same film with no Stream in the path. Through a relay over a slow path it starts much later: 15 to 25 s in our lab, against 1 to 1.5 s straight from the server (4K and HDR).
What others see
Nothing on the chain ties a buyer to a seller, but nodes along a route see a run of similar payments to one seller.

The costs, stated plainly has the figures.

9Prior art

Nothing in a ticket is a new mechanism: it is the hold invoice [5], used for what "stuckless payments" were proposed for [6], bound to HTTP 402 and to a spending policy the owner signs. Tickets sit between a prepaid balance, such as L402 [23], where the buyer can lose all of it, and a payment per piece, such as podcast streaming over keysend [8][9], where every piece waits for its payment. Cashu pays per request privately, but a mint holds the money [27]; nobody holds a ticket.

Paying by lottery goes back to Wheeler and Rivest [33][34], with later forms by Micali and Rivest [35] and by Pass and shelat [36], and lotteries run today by Orchid [39] and Livepeer [40]. For Bitcoin it was raised by Mike Caldwell [41], Tadge Dryja [42] and Oleksandr Kurbatov [43]. The lottery as built adds only the same binding to HTTP and a signed policy. Prior art on the design page has the full discussion.

10Status

Released. Lightning Stream is one app for buying and selling, at version 0.2.0 since 31 October 2026: in a community store for Umbrel, in our registry for StartOS, and as a Linux package. Try it has the setup, and the changelog every version.

On XBT mainnet, between our own nodes. Since 26 October 2026 a fresh install from the published packages has bought films and AI answers from our shop, a node box of ours has bought from a second shop of ours, and a rental of hashrate has been paid. Every charge matched the meter to the millisatoshi; Tests and numbers has the figures. On StartOS, the app's access to the node through Lightning Fork's grant was tested on mainnet; a paid buy on StartOS has not run yet. For 0.2.0 a round with real sats ran on 30 and 31 October: a buyer of ours paid our demo shop, Lightning Stream Genesis, 3,600 sat in four tickets for files, its web app over a direct link and over a relay, and AI answers, and the buyer's node, the shop's node and the wallet's books agreed to the millisatoshi. A 15-minute hashrate rental paid 1,000 sat for 25 slices (202 shares accepted, none rejected), and 315 MB passed through a paid VPN exit. That round found two faults in paying, a VPN exit that charged too little and a test slice of hashrate that ran unpaid; Tests and numbers says where each stands. Nobody outside the project has used it yet. An invited test is next.

Reviewed, not audited. Chris Guida reviewed the design and the published code twice in October 2026: first the earlier design and its code, then the ticket design, the lottery and the tree (Progress and status). Kyle Santiago read the design. In October 2026, machine-assisted reviews of the payment code found further faults; all are fixed in version 0.1.15. There has been no independent audit. Treat it as unaudited software and use amounts you can afford to lose.

Coming. Paid relays, in an update. Then, in this order: paying from a wallet over Nostr Wallet Connect instead of a node of one's own; AI sellers that are Nostr data vending machines; and media on Blossom servers sold through a gateway. Later ideas, not yet built: ticket sizes that follow how fast a buyer spends, and paid torrent seeding.

Not built. The win that pays itself, fair exchange on held tickets, and a seller on Core Lightning. The full list is on Progress and status.

11References

The works cited on this page, numbered as in the full list, which also says how each was read.

  1. J. Poon, T. Dryja. "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments". Draft 0.5.9.2, 14 January 2016. lightning.network.
  2. J. Jager. "htlcswitch: hodl invoice". lnd pull request 2022, merged March 2019; released in lnd v0.6-beta, April 2019. The calls are AddHoldInvoice, SettleInvoice and CancelInvoice of lnd's invoices service. pull request, Optech: hold invoices.
  3. H. Gondo. "Proposal for Stuckless Payment". lightning-dev mailing list, 25 June 2019. archived copy.
  4. V. Wallace. "bLIP 3: Keysend". 2021. blip-0003.
  5. Satoshis Stream. "bLIP 10: Podcasting 2.0 Streaming payments, Boosts and Boostagrams". 2022. blip-0010.
  6. Bitcoin Optech. "Channel jamming attacks". Topic page. bitcoinops.org.
  7. x402 Foundation. "x402", protocol version 2, with its schemes exact (and exact on Lightning, 2026), upto and batch-settlement. Created by Coinbase; since April 2026 kept by the x402 Foundation under the Linux Foundation. Apache-2.0. x402-foundation/x402, announcement.
  8. Lightning Labs. "L402 Protocol Specification". lightninglabs/L402.
  9. Anthropic. "Introducing the Model Context Protocol". 25 November 2024. Since December 2025 the protocol is kept by the Agentic AI Foundation, under the Linux Foundation. announcement, modelcontextprotocol.io.
  10. Cashu contributors (calle and others). "Cashu NUTs", the Cashu protocol specifications; "NUT-24: HTTP 402 Payment Required". cashubtc/nuts, NUT-24.
  11. D. Wheeler. "Transactions Using Bets". Security Protocols, LNCS 1189, Springer, 1996. doi:10.1007/3-540-62494-5_7. We read its record and what Rivest and later authors say of it, not the paper itself.
  12. R. L. Rivest. "Electronic Lottery Tickets as Micropayments". Financial Cryptography 1997. author's copy.
  13. S. Micali, R. L. Rivest. "Micropayments Revisited". CT-RSA 2002. author's copy.
  14. R. Pass, a. shelat. "Micropayments for Decentralized Currencies". ACM CCS 2015. ePrint 2016/332.
  15. J. S. Cannell, J. Sheek, J. Freeman, G. Hazel, J. Rodriguez-Mueller, E. Hou, B. J. Fox, S. Waterhouse. "Orchid: A Decentralized Network Routing Market". Version 2.0, 2019. whitepaper.
  16. D. Petkanics, Y. Fu. "Livepeer Streamflow Paper". 2018. The contract is TicketBroker in the Livepeer protocol. Streamflow, contract.
  17. M. Caldwell (casascius). "Sustainable nanopayment idea: Probabilistic Payments". Bitcoin Forum, 4 February 2012. bitcointalk.org.
  18. T. Dryja. "LN as a Directed Graph: Single-Funded Channel Topology". Slides, 11 April 2016. slides.
  19. O. Kurbatov. "Emulating OP_RAND in Bitcoin". arXiv:2501.16451, January 2025, and the Delving Bitcoin thread "Emulating OP_RAND". arXiv:2501.16451, thread, Optech: probabilistic payments.
  20. P. Gerhart, J. Taylor, S. A. K. Thyagarajan. "Probabilistic Atomic Swaps for Bitcoin and Friends". arXiv:2605.04975, 6 May 2026. arXiv:2605.04975.
  21. Bitcoin Knots, maintained by Luke Dashjr. Release 29.4.1 (September 2026) carries the BLAKE2b proof of work (L. Dashjr) and the unified opt-in signature hash (K. Santiago; specified in the tree's doc/unified-sighash.md), activated at block 961,640 together with the reduced-data rules of BIP 110 (D. Ohm). MIT. bitcoinknots/bitcoin, unified-sighash.md.
  22. Lightning Fork, by Paul Lamb: lnd for the BLAKE2b chain. Measured here at tag v0.21.3-beta-blake2b.17 (commit cebc10fe), in the regtest lab of the same author, lightning-fork-lab, at commit a5cadc5. Lightning Fork is MIT; the lab carries no licence file. paulscode/lightning-fork, paulscode/lightning-fork-lab.
  23. lnd, the Lightning Network Daemon, by Lightning Labs and the Lightning Network developers. MIT. lightningnetwork/lnd.
  24. The Core Lightning fork for the BLAKE2b chain, by PrivKey, built on Core Lightning (R. Russell, Blockstream, and contributors). Measured here at release v26.06.9-blake2b.7 (commit 482c8c52), from the released binaries, as buyer, routing node and seller. Its documentation at that tag (doc/lightningd-config.5.md) gives the default of 30 pending payments in each direction of a channel. privkeyio/lightning, release, ElementsProject/lightning.
  25. OCEAN. DATUM Gateway (Bitcoin Ocean, LLC, Jason Hughes and contributors; MIT), and J. Hughes, "TIDES: Transparent Index of Distinct Extended Shares", 2024. OCEAN-xyz/datum_gateway, TIDES.

12Acknowledgements

Lightning Stream is a small addition to a great deal of other people's work. XBT is Bitcoin on BLAKE2b proof of work, and runs on Bitcoin Knots [60], maintained by Luke Dashjr, who wrote the BLAKE2b proof of work; the signature hash that keeps a payment from being replayed on the SHA-256 chain is Kyle Santiago's. Lightning on XBT exists because of Paul Lamb's Lightning Fork [61] and PrivKey's Core Lightning fork [63], built on lnd and Core Lightning. Paul also packages the node apps the app runs beside, and built the access grant that lets it connect on StartOS. Hashrate rental is built around OCEAN's DATUM [66].

Chris Guida's two reviews moved Lightning Stream onto Lightning and narrowed what it claims. Kyle Santiago pointed out the slot and dust limits the defaults are built around. Kilombino named the hashmaker and the hashtaker and runs a relay the app uses. The mistakes that remain are ours.

This page is set in Inter (Rasmus Andersson), under the SIL Open Font License.

In one sentence. Pay as you use it, in small tickets the seller draws down exactly with a signed receipt for every answer: anyone can sell anything that arrives over time, and a buyer can lose only a small, stated amount to a seller that cheats, which is then blocked.