Lightning’s Liquidity Market: Who Actually Supplies It

The Problem Lightning Never Quite Solved

Lightning Network payments are fast and inexpensive. That part of the pitch has held up for years. What most explainers leave out is that the speed and the low fees only materialize if the node receiving the payment already has enough inbound liquidity sitting in an open channel. A brand new Lightning wallet, or a merchant node that just came online, cannot receive a single satoshi over Lightning until somebody else commits capital to a channel pointed at it. Sending is easy. Receiving is the hard part, and it always has been.

That asymmetry has quietly shaped how Lightning actually gets built in 2026. Behind the more visible story of channel capacity and dollar-denominated stablecoins moving across Bitcoin’s payment rails, a separate and mostly invisible industry has grown up around one narrow job: selling liquidity to whoever needs it, priced and delivered like any other wholesale commercial service. This is that industry. It has its own vocabulary (LSPs, JIT channels, liquidity leases), its own marketplaces, its own publicly traded company, and its own uncomfortable question: how much of Lightning’s “trustless” pitch survives once a handful of well-capitalized firms become the landlords everyone else rents liquidity from.

None of this is meant to undercut the genuine progress documented elsewhere: capacity has held up for months, dollar stablecoins now move over Lightning rails, and large exchanges route a growing share of customer withdrawals through it. Almost none of that works without the liquidity layer holding up first, and that layer runs on decisions made by a small number of companies most Lightning users have never heard of.

Inbound Liquidity, Outbound Liquidity, and Why the Difference Matters

A Lightning channel is a two-party ledger backed by a single Bitcoin transaction. When two nodes open a channel, one or both commit bitcoin on-chain, and that total splits into a balance sheet with two sides: how much the local node can send, its outbound liquidity, and how much it can receive, its inbound liquidity. If a node funds a channel entirely on its own, one hundred percent of that channel’s capacity starts out as outbound. The node can pay out immediately. It cannot receive anything until the balance shifts, either because it spends some of that outbound liquidity, which flips into inbound capacity on the other side, or because a counterparty pushes funds in from their side. A node that opens a two hundred dollar channel to a friend, for instance, starts with two hundred dollars of outbound capacity and nothing to receive with until some of that gets spent back the other way.

For someone who mostly spends bitcoin, that is not much of a problem. For a merchant, an exchange, or a wallet provider that needs to receive payments from day one, it is the whole problem. Voltage’s own explainer on the subject calls acquiring inbound liquidity the single most discussed operational challenge on Lightning, and the description holds up: it is a structural bootstrapping issue, not a bug a software update quietly fixes. Splicing, the ability to resize an existing channel without closing and reopening it on-chain, has made the mechanics less painful over the past two years, but it still requires a counterparty willing to add capacity, which is exactly the constraint that created the market this piece is about.

The Cold Start Problem and Why a Market Had to Form

For Lightning’s first few years, the fix for inbound liquidity was mostly social. You asked a friend running a node to open a channel to you, or you paid a small amount out first so a counterparty would have a reason to route funds back. That approach scales fine for a few thousand hobbyists. It does not scale for a wallet app onboarding tens of thousands of new users a week, or an exchange that needs to route withdrawals to customers who have never touched a node in their life and never will.

Wherever a real coordination problem persists with actual money on the table, a market tends to show up to solve it, and Lightning liquidity is no exception. Over the past several years a specific category of business has formed around exactly this gap: firms that run large, well-connected, well-capitalized nodes and sell access to that connectivity the way a bank sells an overdraft facility or a cloud provider sells burst compute capacity. In Lightning’s own vocabulary, these firms are called Lightning Service Providers, or LSPs, and by 2026 they have become as load-bearing to the network’s day-to-day usability as any single protocol upgrade.

What a Lightning Service Provider Actually Does

An LSP is, in the simplest terms, a business that operates capacity on other people’s behalf. Instead of asking a new user to find a peer and negotiate a channel manually, an LSP sells that channel as a product, sized and priced for whatever the customer needs, and often runs the underlying node infrastructure too, so the wallet or merchant on the other end does not have to.

In practice, LSPs sell liquidity two different ways. The first is a standing channel: a customer pays upfront, in bitcoin, for a channel of a given size opened directly to their node, and that capacity sits ready whenever they need it. The second is the just-in-time, or JIT, channel: nothing is provisioned in advance, and the moment an incoming payment actually arrives that the customer’s node cannot yet accept, the LSP opens a channel on the spot, funds it, forwards the payment, and deducts its fee from that same payment. JIT channels are what let a brand new mobile wallet receive its very first payment with zero setup, which is why almost every consumer-facing Lightning wallet relies on one behind the scenes, usually without the user ever seeing the word LSP.

Most wallets pick a single default LSP and never surface the choice to users at all, which keeps onboarding simple but means the wallet’s own product decisions, not the user’s, determine who ends up holding that trust relationship on their behalf.

Standardizing the Handshake: LSPS0, LSPS1, LSPS2

For years, every LSP spoke its own dialect. A wallet that wanted to offer customers a choice of providers had to write custom integration code for each one, which meant most wallets just picked a single default LSP and left it at that, a quiet form of lock-in that ran against Lightning’s whole premise of open, permissionless routing.

That changed with a formal specification effort now maintained on GitHub by the BitcoinAndLightningLayerSpecs organization. Three specs, finalized as community bLIPs, Bitcoin Lightning Improvement Proposals, numbered 50 through 52, now define a common language between wallets and LSPs. LSPS0 sets up the transport layer the other two ride on top of, running over the same encrypted peer-to-peer messaging Lightning nodes already use to talk to each other. LSPS1 lets a client order a standing channel from any compliant LSP and pay for it in bitcoin. LSPS2 defines the JIT channel flow described above, including how the fee gets deducted from the inbound payment itself.

Adoption followed the spec rather than waiting for it. The Lightning Development Kit team built a dedicated lightning-liquidity crate implementing LSPS0 through LSPS2 in Rust, which any LDK-based wallet or node can pull in directly rather than writing provider-specific integration code from scratch. The practical effect is that a wallet can, in principle, shop between multiple LSPs for the best price on a given channel, the same way a shopper compares prices across retailers instead of being stuck with one store.

Inside Amboss Magma, Bitcoin’s Largest Liquidity Marketplace

Standardized specs made it possible to build an actual marketplace on top of them, and the biggest one is Amboss’s Magma. Magma is not itself an LSP; it is an exchange where any node operator can list liquidity for sale and any node operator can buy it, without Amboss ever taking custody of either side’s funds. The original design used what the company called a HODL invoice: a Lightning payment construction that only completes once the seller actually opens the promised channel and it clears on-chain confirmation, functioning as trust-minimized escrow rather than a simple upfront payment. A built-in reputation system tracks whether sellers deliver what they promised, filtering out operators who take payment and then stall or renege, a real risk in a market where the product being sold is a promise to lock up bitcoin correctly.

The reputation system exists because that failure mode is real and specific: a seller could, in theory, accept a buyer’s escrowed payment intent and then simply never open the promised channel, or open one far smaller than advertised. Making that behavior visible and costly to repeat is most of what separates an actual marketplace from an informal forum thread where node operators used to arrange channel swaps by hand.

Magma has kept iterating. Magma v2, which shipped in August 2025, simplified the buying flow down to pasting a node’s public key and paying a single Lightning invoice, no account or signup required, and added AI-assisted matching, branded Amboss Intelligence, that pairs buyers with well-performing peer nodes instead of leaving that choice to guesswork. It also broke subscriptions open into one-time purchases, so an operator who needs capacity once does not have to commit to a recurring plan. Under the current flow, channels typically arrive after six on-chain confirmations, the point at which Magma considers the trade settled.

Amboss pushed the automation further with Magma AI, a machine-learning channel recommender launched in December 2024 that analyzes network data to suggest which peers a node should connect to and how big those channels should be. Amboss co-founder and chief executive Jesse Shrader described the goal in blunt infrastructure terms when the tool launched: “Making Bitcoin practical for digital commerce starts with getting the fundamentals right. Magma AI brings intelligence to channel management, helping Lightning Network nodes operate more efficiently today while building toward a future where Bitcoin can handle millions of automated transactions and becomes the backbone of the coming machine economy.”

Lightning Labs Runs a Marketplace Too

Amboss is not the only liquidity venue, and it is not the one built by the team that maintains LND, the node software running most of Lightning’s public capacity. Lightning Labs operates its own non-custodial liquidity system through Lightning Terminal, called Pool. Instead of an open order book, Pool runs as a sealed-bid batched auction, where node operators looking for inbound capacity submit bids, liquidity providers submit asks, and the market clears periodically on-chain rather than trading continuously. Lightning Labs’ own documentation positions Pool as infrastructure for operators who want channel liquidity priced by a transparent auction mechanism rather than a fixed listing price.

The mechanism differs from Magma’s instant-purchase order book, but the underlying economics are the same: liquidity is scarce, someone has to price it, and a formal market does that more efficiently than informal, one-off arrangements between node operators who happen to know each other. That two competing venues, one built by an independent company and one built by the team that maintains the network’s dominant node implementation, both converged on a marketplace model says something about how real the underlying demand is.

For most ordinary users this distinction never surfaces; wallets abstract it away entirely. It matters more for node operators and businesses deciding how to provision capacity at scale, where an auction can produce a fairer clearing price than a fixed marketplace listing, at the cost of speed, since a batched auction settles on its own schedule rather than the moment a buyer wants capacity.

Meet the Liquidity Providers

Marketplaces need sellers, and a specific cast of firms supplies most of the liquidity moving through them. Voltage is probably the best known: a node hosting and infrastructure company that also acts as an LSP in its own right, and the firm whose infrastructure carried Secure Digital Markets’ reported one million dollar Lightning payment to Kraken, the largest publicly reported single Lightning transaction to date. Megalith runs one of the largest individual routing nodes on the network, with capacity spread across more than two hundred channels. LNBIG, an operator that has run under aliased Hub node names since Lightning’s early years with its operators’ identities never publicly confirmed, remains one of the largest and oldest sources of liquidity on the network, a reminder that some of Lightning’s most important infrastructure is still provided by people nobody can name.

Then there is LQWD Technologies, which is different in kind from the rest of this list: a publicly traded company built specifically around owning and deploying Lightning liquidity as its core business, rather than a side product bolted onto node hosting or block explorer services. Where Voltage, Megalith, and LNBIG treat liquidity provision as one line of business among several, LQWD’s entire balance sheet strategy is built around it.

Beneath that top tier sits a long tail of much smaller sellers, hobbyist node operators who list modest amounts of capacity on Magma for extra yield on bitcoin they were already holding. They rarely move the needle on total network capacity, but collectively they are part of why the marketplace model has stayed more competitive than simply defaulting to a single provider.

Case Study: LQWD Technologies and Bitcoin as “Productive Capital”

LQWD Technologies is a Canadian company, dual-listed on the TSX Venture Exchange under the ticker LQWD and on the OTCQX in the United States under LQWDF, with offices in Vancouver and Lugano. Its pitch to investors is straightforward: rather than simply holding bitcoin on a balance sheet the way a growing list of corporate treasuries now do, LQWD deploys its bitcoin directly as Lightning routing and channel-lease capital, earning fees on the liquidity it provides instead of leaving it idle. The company calls this “productive network capital,” and as of a May 2026 disclosure it reported roughly 267 unencumbered bitcoin held this way, against a debt-free balance sheet and roughly 32.3 million shares outstanding.

In 2024, LQWD formalized a partnership with Amboss to become one of Magma’s premiere liquidity providers, seeding the arrangement with an initial ten bitcoin contribution and committing to deploy more over time. Chief executive Shone Anstey described the logic behind the deal at the time: “This partnership enables LQWD to deploy more of our company-owned Bitcoin while potentially capturing significant transaction volume and generating yield on our Bitcoin holdings. Importantly, we maintain full sovereignty and custody throughout the process.”

That last line does a lot of work. LQWD is explicit that it is not lending its bitcoin out or taking on counterparty credit risk the way a centralized lender would; the capital sits in Lightning channels the company itself controls one side of, earning routing and lease fees rather than interest. Publicly traded bitcoin treasury companies have generally been valued on some multiple of the bitcoin they hold; LQWD is effectively asking investors to also underwrite the operational risk of running Lightning infrastructure well, a different kind of bet than simply buying and holding. Whether public markets end up rewarding that model the way they have rewarded pure bitcoin-holding treasuries is still an open question, but LQWD remains the clearest example of Lightning liquidity provision moving from a technical niche into something a public company can put in an investor deck.

The Economics: What Liquidity Actually Costs

Buying Lightning liquidity involves layering several distinct costs:

• A one-time on-chain fee to open, and eventually close, the channel, driven by whatever Bitcoin’s mempool is charging at that moment
• The LSP’s or marketplace’s own markup for sourcing and delivering the capacity
• An ongoing routing fee charged every time the channel actually forwards a payment, typically a small base fee plus a proportional rate measured in parts per million

Amboss has been vocal about how that stack compares to traditional payment rails. Jesse Shrader made the comparison directly in an interview with Bitcoin Magazine: “We’re supplying liquidity at less than 0.5%. As a user of big payment card networks, I’m paying 4% for all that payment processing, and the money doesn’t show up for days to weeks after the payment is made. With Lightning, your payment processing fees drop by almost 10x.” That is a company describing its own product in the best possible light, not an independently audited benchmark, but the underlying comparison points, card network interchange running in the low single digits and multi-day settlement, are well known well outside of crypto, and they explain why merchants and exchanges have kept experimenting with Lightning rails despite the added technical complexity.

The table below lays out the rough comparison Shrader is drawing, alongside where plain on-chain Bitcoin sits for context.

The Centralization Question: Who Actually Holds the Liquidity

An efficient market for anything tends to concentrate around whoever prices risk best and has the deepest balance sheet, and Lightning liquidity is not an exception. Academic researchers have been documenting this for years. A widely cited study covering the network’s structure through mid-2019, published in New Journal of Physics and available on arXiv, found a Gini coefficient of roughly 0.88 for how bitcoin was distributed across nodes, on a scale where 1.0 represents total concentration in a single node, and calculated that the top 10% of nodes by capacity held around 80% of all bitcoin committed to the network, with the top 50% holding nearly all of it. The paper described Lightning as exhibiting a “core-periphery” structure: a small number of well-connected hubs doing most of the work, surrounded by a much larger periphery of small, thinly connected nodes.

That finding is now several years old, but more recent topology research covering the network’s evolution through the early 2020s has continued to describe the same basic shape, even as total capacity and the identities of the largest hubs have shifted. It is worth being precise about what kind of centralization this is, because it is easy to conflate with a separate, already well documented critique: a large share of Lightning nodes running on Amazon Web Services and Google Cloud infrastructure, a hosting-concentration problem. Liquidity concentration is a different axis entirely. It is not about where a node’s software happens to run; it is about who a user is financially depending on when they need a channel funded, which is precisely the question an LSP or a marketplace like Magma exists to answer, and precisely why the answer keeps narrowing toward the same handful of names: Voltage, Megalith, LNBIG, LQWD, and a long tail of much smaller sellers who supply the rest.

For an individual wallet user, none of this concentration is visible day to day; a payment either goes through or it does not, and the app rarely explains why. But it matters at the margin in ways that echo other parts of crypto: if a small number of liquidity providers ever had to withdraw capacity at once, whether from regulatory pressure, a security incident, or simply a business deciding Lightning liquidity was not worth the balance-sheet risk, large parts of the network’s practical capacity to receive payments could tighten quickly, even if the underlying protocol kept working exactly as designed.

None of this makes Lightning unusual among crypto’s capital markets. The same pattern, open and permissionless infrastructure that nonetheless concentrates capital around a small number of well-capitalized players once real money gets involved, has played out in institutional restaking, where a handful of operators and asset managers now account for an outsized share of deployed capital. Lightning’s liquidity market looks less like an exception to that pattern than a confirmation of it.

Custody in Disguise? The Trust Model Behind “Non-Custodial” Liquidity

Buying a channel from an LSP is, in the strict technical sense, non-custodial. The funds sit in a two-of-two multisig address on the Bitcoin blockchain that both parties co-control; the LSP never has unilateral access to the customer’s share, and the customer can force the channel closed on-chain at any time using nothing but their own key. That is a real and meaningful difference from handing bitcoin to a custodian.

In practice, though, the customer is trusting the LSP for as long as that channel stays open: trusting that the provider’s node stays online so payments can actually route, trusting that it will not attempt a stale-state force-close designed to cheat the customer out of funds, and trusting that the customer, or a watchtower acting on their behalf, is actually watching the chain closely enough to catch it if it tries. None of that is custody in the legal sense. All of it is a dependency on a specific counterparty’s behavior, which functions a lot like what custody is trying to describe.

This is not a new tension in Lightning’s broader design, just a version of it that shows up specifically in the liquidity layer. Lightspark co-founder and chief executive David Marcus made a version of the same point when explaining why his company built Spark as an alternative to running plain Lightning channels, arguing in comments reported by Bitcoin.com that “if you want full support for non-custodial Lightning with offline receive and want to make it economically viable, you have to accept some form of compromise on the trustlessness level of the solution.” Swap out “offline receive” for “liquidity on demand” and the same logic describes what happens every time a wallet leans on an LSP: usability gets bought with a small, specific compromise on trustlessness, not eliminated, just relocated to a different part of the stack. It is the same pattern that shows up in wallet security more broadly, where nominally non-custodial systems keep reintroducing trust through whichever layer users cannot easily verify for themselves.

Institutions Are Becoming Liquidity Destinations, Not Just Buyers

The liquidity market’s customer base has been shifting. Retail wallets were the original use case, since a mobile app needs a JIT channel so a new user can receive their first payment, but exchanges have become some of the largest single destinations for inbound liquidity on the network. Coinbase alone was already routing more than 15% of its Bitcoin withdrawals over Lightning by mid-2025, according to Spark’s research, which makes an exchange sending customer withdrawals one of the biggest wholesale liquidity customers Lightning has, the kind that negotiates direct capacity relationships with LSPs like Voltage rather than buying retail-sized channels off a public marketplace. The practical difference between a fast, cheap Lightning withdrawal and a slow, expensive on-chain one is now part of the picture in head-to-head comparisons of how major exchanges actually handle withdrawals.

The dollar figures involved are still modest next to traditional payment rails, but they are no longer trivial. Secure Digital Markets’ reported one million dollar Lightning settlement to Kraken, carried over Voltage’s infrastructure, remains the largest publicly reported single Lightning payment, and it required exactly the kind of pre-positioned, institutional-grade liquidity this piece has been describing, not a channel opened on the fly. Kraken and Coinbase have both continued expanding Lightning support for withdrawals and deposits since, treating the rail less as an experimental feature and more as standard plumbing customers expect.

That institutional pull raises a regulatory question this piece can only gesture at: none of Lightning’s liquidity-provision activity has been treated as a securities offering to date. A channel lease is a commercial agreement to route bitcoin for a fee, not, on its face, an investment contract. But as more of this activity gets wrapped in yield-like language, LQWD’s “productive capital” framing among them, it edges closer to territory regulators have scrutinized elsewhere in crypto. Readers who want the fuller regulatory backdrop against which any of this would eventually get evaluated can find it in HOGE Wire’s rundown of the SEC’s new crypto ETP and market structure rules.

Where the Liquidity Market Goes Next

Two forces are pulling on this market at once. The first is automation: Magma AI already recommends peers and channel sizes algorithmically, and LQWD markets its own infrastructure using similar AI-agent language, aiming toward a world where liquidity gets rebalanced across a node automatically rather than by a human watching a dashboard. The second is splicing, now standard in Core Lightning and increasingly available elsewhere, which lets an existing channel get resized instead of closed and reopened, potentially reducing how often a node needs to buy a brand new standing channel at all, even as it increases the value of fast, reliable JIT channels for the moments when resizing is not fast enough.

Both forces point toward the same destination: liquidity that a human never has to think about, provisioned automatically the instant something, a person, a merchant, or increasingly a piece of software, needs to receive a payment. That is precisely the problem Lightning Labs is trying to solve one layer up the stack with Wavelength, its toolkit aimed at letting AI agents hold and receive bitcoin without running any Lightning infrastructure themselves. Wavelength and tools like it are the application layer; the liquidity market described in this piece is the plumbing underneath that has to keep working, invisibly, for any of it to function.

None of this is guaranteed to play out cleanly. A liquidity market built on reputation scores and escrow mechanics is still new enough that it has not been tested by a genuine crisis: a major provider failing, a marketplace bug, or a coordinated attempt to game the reputation system at scale. Lightning survived its own early skeptics by simply working, day after day, for small payments. Whether the liquidity market underneath it stays a genuinely competitive market with dozens of sellers, or consolidates around two or three winners the way so much of the rest of crypto’s infrastructure has, is arguably a more consequential question for Lightning’s future than whether total network capacity sets another record next quarter.

Frequently Asked Questions

What is a Lightning Service Provider (LSP)?

A Lightning Service Provider is a business that runs a well-connected, well-funded Lightning node and sells access to its liquidity and routing capacity, typically as a channel opened directly to a customer’s wallet or node. Most consumer Lightning wallets rely on an LSP behind the scenes so new users can receive payments immediately, without manually finding a peer or funding a channel themselves.

How does a marketplace like Amboss Magma work?

Magma lets any node operator list liquidity for sale and any node operator buy it, without Amboss taking custody of either side’s funds. The trade settles through an escrow-style mechanism that only releases payment once the seller actually opens the promised channel and it clears several on-chain confirmations, backed by a reputation system that tracks whether sellers deliver what they list.

What is a just-in-time (JIT) channel?

A JIT channel is a channel an LSP opens automatically the moment an incoming payment arrives that a wallet cannot yet accept, rather than one provisioned in advance. The provider funds the channel, forwards the payment, and deducts its fee from that same payment, which is what allows a brand new wallet to receive its first payment with no setup at all.

Is buying Lightning liquidity from an LSP custodial?

Not in the strict sense. Channel funds sit in a two-of-two multisig address that both the customer and the provider co-control, and the customer can force the channel closed with their own key at any time. In practice, the customer is still trusting the provider’s uptime and honest behavior for as long as the channel stays open, a dependency that functions a lot like custody even though it is not custody in the legal sense.

How much does Lightning Network liquidity cost?

Costs stack in three layers: the one-time on-chain fee to open the channel, the provider’s or marketplace’s markup for sourcing the capacity, and an ongoing routing fee charged whenever the channel forwards a payment. Amboss has publicly described its own liquidity costs as running under 0.5%, well below the roughly 2 to 4% many merchants pay in card network processing fees, though that comparison comes from the provider itself rather than an independent audit.

Written by Elena Vasquez, HOGE Wire bitcoin desk.