The payments inversion — building a Lightning revenue-share loop where the app pays the user

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3895137) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } Luke Posted on Apr 28 The payments inversion — building a Lightning revenue-share loop where the app pays the user #webdev #showdev #lightning #bitcoin In the last post I argued that Stripe — and the card network underneath it — can’t serve certain payment shapes, no matter how good the developer experience around it gets. Sub-dollar payments don’t work. Agent-to-agent payments don’t work. Today’s post is about a third shape that breaks on the same rails, and the most interesting one to me, because it’s an inversion of how almost every app on the web handles money. Most apps take money from users. The one I want to walk through pays users instead. The architecture that makes that possible is small enough to fit in one post, but the economic implications are bigger than I expected when I started building it. The app is Sats Channel, currently shipping on QuackBuilds. The premise is straightforward: you watch classic movies and television, and you earn Bitcoin (denominated in sats, the smallest unit of BTC) for the time you spend watching. There are no accounts in the traditional sense — you connect a Lightning wallet and a session starts accruing sats against your address as the video plays. The ad network running against the video pays in Bitcoin, the platform takes a cut to stay alive, and the rest is split back to viewers in proportion to attention. The whole loop is closed in BTC, which turns out to be the part that makes the math work. Walk through why traditional rails can’t host this. A user watching a forty-minute episode might generate, very roughly, somewhere between a few cents and a few dimes of ad revenue depending on fill rate and CPM. Their share of that, after the platform’s cut, is fractions of a cent per minute. To pay that out via Stripe Connect or PayPal, you’d hit minimum withdrawal thresholds (usually a few dollars), per-transaction fees (often a fixed component plus a percentage), and KYC overhead per recipient that vaporizes the unit economics before the first payout clears. The model only works if the cost of paying a user is meaningfully smaller than the amount you’re paying them. On card rails, for sub-dollar payouts, it isn’t. The bundling tax I mentioned in the last post shows up here in its purest form — every “watch and earn” product on the legacy web ends up being a points system that converts to gift cards at $5 increments, because that’s the smallest payout the rails will tolerate. Lightning collapses that constraint. A Lightning payment — assuming a healthy channel — costs effectively nothing to send and settles in milliseconds. Paying a user one sat is economically rational. Paying them ten thousand sats is the same cost. The accrual model can therefore mirror reality: as a viewer watches, a counter ticks upward in their balance, and they can claim that balance to their wallet by submitting a Lightning address at any time, as long as the 100-sat minimum is met. The counter only ticks while the viewer is actively watching — the player checks for engagement signals and pauses accrual if it looks like the tab is idle or the user has walked away. That’s not friction for legitimate viewers, it’s the…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.