Over the past few months, the Fiber community has explored several demos around streaming payments, pay-as-you-go services, and small instant payments.
These demos prove that the protocol can work. But for everyday users, merchants, and developers, the protocol is only one part of the experience. Around payment channels, there still needs to be wallets, liquidity support, merchant tools, routing reliability, SDKs, and clearer product language.
To better understand the gap between demos and real-world products, I started looking into the Lightning ecosystem. Lightning has spent years exploring what kinds of infrastructure need to grow around payment channels before they feel usable in daily life.
As a product designer, I am not trying to make a technical comparison between Lightning and Fiber. I am more interested in looking at it through a UX lens: how did Lightning’s protocol constraints become product opportunities, and what can Fiber learn from that?
Intro to Payment Channels
A payment channel is an off-chain payment relationship backed by funds locked on-chain. After a channel is opened, participants can update balances off-chain without publishing every small payment to the blockchain.
This is what makes payment channels useful for fast, low-cost, repeated payments. The blockchain still matters because it anchors the channel and settles the latest agreed state when needed. But most payment activity can happen off-chain.
From a protocol perspective, this design is powerful. From a UX perspective, it introduces questions users do not usually need to think about:
1. Channel Setup: Why Do I Need To Open Something Before Paying?
User problem
In a normal wallet, the user’s mental model is simple:
I have money, so I should be able to pay.
Payment channels interrupt that model. Before making fast off-chain payments, funds usually need to be available inside a channel first.
From the protocol’s point of view, this makes sense. From the user’s point of view, it can feel like extra preparation before the benefit is clear. If users need to think about peers, channels, funding, or liquidity before they experience a successful payment, the product may lose them before the aha moment happens.
How the Lightning ecosystem responds
Lightning products have responded by hiding or simplifying channel setup in different ways.
Phoenix is a good example of a self-custodial wallet designed for everyday users. It still uses Lightning channels, but channel management feels mostly automatic. Phoenix manages channels, handles inbound liquidity, and uses ACINQ’s infrastructure to make sending and receiving feel closer to a normal wallet experience.
Cash App takes a more mainstream approach. For many users, Lightning is simply a payment rail behind the app. The user scans a Lightning invoice, chooses a funding source, confirms, and pays. They do not need to know which channel is being used, which peer is connected, or how liquidity is managed behind the scenes.
These examples solve the same UX problem in different ways. Phoenix makes self-custodial Lightning feel more approachable. Cash App hides Lightning almost completely inside a familiar payment flow. In both cases, users experience the value of the payment before they are asked to understand the channel.
Insight for Fiber
For Fiber, the first product experience should focus on payment value, not protocol mechanics.
Many Fiber builders come from a developer background, so it is natural to use protocol language like “open channel,” “connect peer,” “fund channel,” or “liquidity.” But for everyday users, these words can make the product feel like infrastructure before they understand what it enables.
The product should not make users feel that the first step is “open a channel.” It should make them feel that they can add funds, scan, pay, receive, or start using a service quickly. The channel can still exist underneath, but it should not be the main object users must understand upfront.
This does not mean Fiber should hide everything forever. In the spirit of Web5, users should be able to choose their level of control. Everyday users may prefer a simple mode where channels and liquidity are mostly abstracted away. Advanced users, merchants, and node operators may want a more transparent mode where they can inspect channels, peers, capacity, routes, and fees.
2. Channel Liquidity: How Much Money Should I Put In?
User problem
Once a product asks users to open a channel, it also asks them to make a budgeting decision:
How much should I put in? Do I need to close it and open another one if it runs out?
This is harder than a normal wallet balance because the user is not just holding money. They are placing liquidity somewhere, and that liquidity affects whether they can send or receive later.
If channel funding feels like a scary one-time commitment, users may hesitate before trying the system at all.
How the Lightning ecosystem responds
Lightning does not completely remove this question, but tools like Loop and Autoloop make liquidity more adjustable after a channel is already in use.
Lightning Loop lets users move funds between on-chain Bitcoin and Lightning channels. Loop In can move on-chain funds into Lightning and help refill spendable channel balance. Loop Out moves funds out of Lightning to an on-chain address, which can also help free up inbound capacity so a node or merchant can receive more payments.
In product terms, Loop partially solves the “what if I put in the wrong amount?” problem. It does not perfectly predict the right balance upfront, and it still involves on-chain movement. But it gives users and operators ways to adjust later instead of treating every liquidity problem as “close the channel and start over.”
Autoloop goes further by turning Loop swaps into a rules-based liquidity-management system. Node operators can define liquidity targets, set thresholds for incoming and outgoing capacity, and give Autoloop a fee budget. Autoloop can then suggest or automatically dispatch swaps when liquidity moves outside those rules.
This turns liquidity from a one-time guess into something that can be monitored, adjusted, and managed over time.
Insight for Fiber
For Fiber, the goal should not be to make users choose the perfect channel amount by themselves. Products could recommend a starting amount based on the payment context, the user’s past behavior, the merchant’s expected usage pattern, or historical channel activity.
But prediction will never be perfect. So the more important product principle is recoverability.
If users put in too little, they should not feel that the only path is to close the channel and open a new one. If they put in too much, they should not feel that their funds are trapped.
Instead of exposing the native channel lifecycle as the main recovery path, Fiber products should help users add funds, move funds back, or adjust liquidity when their needs change. The experience should feel recommended when possible, adjustable when needed, and recoverable when something goes wrong.
3. Payment Failure: Why Did My Payment Fail If I Had Money?
User problem
In most payment products, failed payments have familiar explanations: not enough balance, wrong card details, network error, bank declined, and so on.
Channel-based payments are more complicated. A user may have funds, a merchant may generate an invoice, and everything may look ready. But the payment can still fail if the payer’s node cannot find or complete a route with enough liquidity in the right direction.
This is partly caused by a privacy tradeoff. The exact liquidity on each side of a channel is not public. So even if a channel appears to have enough total capacity, the payer’s node may not know how much liquidity is actually available in the direction the payment needs.
That helps protect privacy, but it also makes routing less predictable. From the user’s perspective, the failure feels counter-intuitive:
Why didn’t my payment go through?
If the product does not explain this well, users may simply think the payment system is unreliable.
How the Lightning ecosystem responds
Because reliability is such a core issue, Lightning has built several product and infrastructure responses around it.
LND Mission Control addresses the routing side. Since exact channel balances are not fully known, LND learns from previous payment successes and failures. Over time, it uses that history to make better routing decisions. In other words, the node turns past payment attempts into routing intelligence.
Multi-Path Payments (MPP) and Atomic Multi-Path Payments (AMP) approach reliability from another angle. If one route does not have enough liquidity, the payment can be split across multiple paths. Instead of depending on one perfect route, the payment has more ways to succeed.
Lightning Pool responds to the receiving side of the problem. Merchants and node operators may need inbound liquidity to receive payments reliably. Pool creates a marketplace where liquidity can be bought and sold without giving up control of funds.
Together, these examples show that payment reliability is not solved by one feature. It needs routing intelligence, retries, multi-path support, liquidity management, and liquidity markets.
Insight for Fiber
For Fiber, payment reliability may be even more complex because the network is not only dealing with liquidity, but also asset-specific liquidity. A route may have enough capacity in general, but not enough capacity for the asset the user wants to send or the merchant wants to receive.
That means reliability is not only about whether a route exists. It is also about whether the right kind of value can move through that route.
Fiber products could reduce uncertainty before users hit confirm by checking route confidence, expected fees, supported assets, and receiving capacity. The estimate will not always be perfect, but it can help users understand the risk before the payment fails.
When a payment does fail, the product should not expose a raw JSON response or a dead-end error. It should explain the failure in human language and suggest what the user can do next. For example, the fee may be above the user’s limit, the receiver may lack inbound capacity, or no route may currently support the required asset.
Receivers also need this visibility before failures happen. They should understand how much they can receive, in which assets, and when they may need more liquidity support. If Fiber eventually has liquidity marketplaces or LSP-like services, receivers could acquire the liquidity they need instead of waiting for the network to naturally provide enough receiving capacity.
Fiber does not need to make routing uncertainty disappear completely. But it should turn that uncertainty into something users can understand, recover from, and trust more over time.
4. Asset UX: What Value Am I Paying With, and Can the Merchant Receive It?
User problem
After setup, balance, and routing reliability, users and merchants still care about one basic question:
What value is actually moving?
For everyday payments, most users and merchants think in stable amounts. A coffee is $5. A rental service charges by the hour. An API call costs a tiny fixed amount. A merchant wants to know how much revenue they received today.
They usually do not want to think about price volatility while making or receiving small payments.
In cross-border or multi-asset scenarios, another question appears:
What if I have one asset, but the merchant wants another?
If the user has to manually swap assets, choose routes, compare liquidity, and understand which nodes support which asset, the payment experience quickly becomes too complicated.
How the Lightning ecosystem responds
Lightning is BTC-native. That is powerful for Bitcoin-native settlement, but it also means many everyday payment experiences need fiat denomination, conversion, accounting, or settlement layers around the network.
Cash App shows how Lightning can be hidden inside a familiar payment flow. Eligible users can pay Lightning invoices from a USD Cash balance, while the app handles the conversion into bitcoin and sends the payment over Lightning. The user experience can feel like paying from dollars, even though Lightning is the rail underneath.
OpenNode packages Lightning for businesses that mainly want to accept payments. A merchant can accept Bitcoin or Lightning payments, but choose how settlement works. They can keep bitcoin, convert to local currency, or split settlement between bitcoin and fiat. This helps merchants accept Lightning without taking full BTC price exposure or rebuilding checkout, invoicing, and payout flows from scratch.
There is also another direction emerging through Taproot Assets. Instead of only adding fiat conversion around Lightning, Taproot Assets explores how issued assets, including stablecoins, can move through Lightning-style infrastructure.
So Lightning’s response has two layers: make BTC-native payments feel more stable and familiar through product layers, while also exploring whether more assets can move through shared payment infrastructure.
Insight for Fiber
This is where Fiber may have a meaningful advantage. Lightning started from BTC-native payments, so stable-value and multi-currency experiences often need to be added around that base. Fiber, because it is built on CKB and can support UDT assets, has the opportunity to think about stable-value and multi-asset payments from the beginning.
To turn this protocol advantage into real adoption, I think there are two important product directions.
First, stablecoins should become first-class payment assets in Fiber. If everyday payments still start from a volatile CKB balance, users and receivers may face the same pricing and accounting friction that many Lightning products had to solve later. Reliable stable-value assets on CKB could help Fiber payment experiences start from the value users already understand.
Second, multi-asset payments should feel automatic. Users should not need to manually swap assets, choose routes, or understand which channel supports which token. Ideally, users can pay with the asset they have, while receivers get the stablecoin or preferred asset they want.
Only when stable-value payments and automatic asset conversion feel natural can Fiber’s multi-asset support become more than a technical advantage. It can become a real adoption advantage.
Closing Thoughts
There is still much more in the Lightning ecosystem that I have not touched in this post. But this exploration made more interested in where Fiber should take a different path.
Lightning started from a BTC-native network, so many product layers had to grow around it later: fiat-denominated payment flows, merchant settlement tools, liquidity services, and routing reliability infrastructure. These layers are valuable, but they also show how much product work is needed when the base payment experience does not fully match everyday user and merchant expectations.
Fiber does not have to follow the same order. Its multi-asset nature gives it a chance to make stablecoin payments part of the core experience earlier, instead of treating volatility and asset conversion as problems to patch later.
But multi-asset support also makes the liquidity problem more complex. It is not enough for a route to have capacity; it also needs the right asset, in the right direction, at the right time. That means LSP-like infrastructure, liquidity marketplaces, and automated liquidity support may become especially important for Fiber if it wants to support real-world payments reliably.
That is where I think Fiber’s product opportunity is strongest: not only making payment channels usable, but making stablecoin-first, multi-asset payments feel natural and reliable from the beginning.