Receive-first payments on Fiber: what I learned from exploring a Lightning-style LSP path

Applications & Ecosystem
, , ,
1

Hi everyone,

I have been thinking about the receive-first payment problem on Fiber, and I wanted to share my findings rather than present this as a finished proposal.

The idea came from looking at how the Lightning Network ecosystem handles a common UX issue: a new wallet, merchant, or app user may want to receive a payment before they have inbound liquidity. On Lightning, this led to LSP patterns where a service can help provide liquidity just in time, so the user does not need to understand channel management before receiving their first payment.

I wanted to understand whether a similar direction makes sense for Fiber.

The short version of what I found

A Lightning-style LSP direction seems useful for Fiber receive-first UX, but two Fiber-specific issues matter a lot:

  1. Native payment interception / hold-payment support

  2. Recipient-side CKB cells or capacity requirements

1. Receive-first is really a UX problem

For normal users, “you need inbound liquidity before you can receive” is not an intuitive starting point.

A user expects:

  • I install a wallet

  • I share a payment request

  • I receive money

But channel-based payment networks often need another layer of setup:

  • Do I have a channel?

  • Do I have inbound capacity?

  • Who funded the channel?

  • Can this payment actually reach me?

That is where the LSP idea becomes interesting. A service could help with just-in-time liquidity so that the recipient can receive without manually opening and funding inbound channels first.

In plain language: the user should not have to become a channel operator before receiving a first payment.

2. What maps well from Lightning

The broad LSP shape seems to map conceptually:

  • sender wants to pay

  • LSP sees payment demand

  • LSP provisions or reuses recipient-side liquidity

  • recipient gets paid

  • sender-facing payment settles only after recipient delivery succeeds

That pattern is useful because it separates the user experience from the liquidity plumbing.

The user sees: receive payment

The infrastructure handles:

  • channel state

  • liquidity

  • settlement ordering

  • failure handling

That seems like a direction worth exploring for Fiber wallets, merchants, and hosted payment services.

But when I tried to reason through it against actual Fiber behavior, two challenges became very clear.

3. Challenge one: native interception matters

The first challenge is payment interception.

A clean receive-first LSP flow probably needs a native way for the LSP to react when payment demand appears.

In an ideal version, Fiber would expose something like:

  • payment received / held

  • payment needs routing decision

  • invoice reached hold state

  • channel/payment event subscription

  • intercept callback

  • settle or fail after downstream action

Without that kind of native surface, an LSP can still orchestrate around the node by polling invoice state, watching channels, opening liquidity, sending the recipient payment, and then settling.

But that is not the same as first-class protocol or API support.

The difference matters. Polling and external orchestration can prove a concept, but a production-quality LSP needs a safer event boundary. It needs to know exactly when it can act, what state is final enough to rely on, and how to avoid settling the sender side before recipient delivery succeeds.

So my first question is:

Should Fiber expose native payment interception, hold-payment callbacks, or stronger event subscriptions for LSP-style services?

This is not just a convenience feature. It affects correctness, risk, and how cleanly wallets and services can build receive-first flows.

4. Challenge two: receive-first does not mean “no CKB needed”

The second challenge is more CKB-specific.

It is tempting to say: “The recipient does not need to fund anything.”

But that is not quite honest.

A more accurate statement is:

The recipient may not need to pre-fund inbound Fiber liquidity, but the recipient may still need CKB-side cells or capacity for current channel acceptance mechanics.

That distinction matters.

Inbound liquidity is payment capacity in a channel. If an LSP provides that, the recipient is not pre-funding inbound liquidity.

But CKB capacity and cells are a different resource. Current Fiber and CKB mechanics still touch CKB cells when channels are accepted or maintained. So even if the LSP is providing the payment liquidity, the recipient side may still need enough CKB capacity to participate in the channel mechanics.

For users, this can be confusing: “Why do I still need CKB if the LSP is giving me inbound liquidity?”

The answer is that these are not the same thing.

One is payment liquidity. The other is CKB cell and capacity requirement.

For wallets and onboarding flows, this distinction should probably be made very explicit.

5. Why I think this matters

If Fiber wants good payment UX, receive-first onboarding seems important.

  • A merchant should be able to start receiving without studying channel topology

  • A wallet user should not need to understand inbound liquidity before receiving a first payment

  • An app developer should have a clear pattern for “user receives through Fiber” without inventing unsafe settlement logic from scratch

The Lightning ecosystem has already shown that LSPs can become important UX infrastructure. Fiber may not need to copy Lightning exactly, but the user problem is similar enough that the pattern is worth discussing.

The Fiber-specific part is that the design should respect CKB’s cell model instead of hiding it.

So I would summarize the finding like this:

A Fiber LSP can potentially improve receive-first UX, but a rigorous design must separate:

  • inbound Fiber liquidity

  • recipient-side CKB cell and capacity requirements

  • sender settlement safety

  • native event and interception support

6. Questions for the community

I would love feedback on these questions:

  1. Does a Lightning-style LSP model make sense for Fiber receive-first payments?

  2. Should receive-first support live mostly in wallets and services, or should Fiber expose stronger native hooks?

  3. What would the right native interception or hold-payment API look like?

  4. Is polling invoice and channel state acceptable for early services, or should production LSPs wait for event-driven support?

  5. Can the recipient-side CKB cell and capacity requirement be made easier to reason about for wallets?

  6. Is there a way for wallets or LSPs to sponsor, abstract, or standardize that recipient reserve without making misleading claims?

  7. What should a wallet honestly tell a new user? Something like: “You do not need to pre-fund inbound Fiber liquidity, but you may still need a small CKB reserve for channel mechanics.”

  8. Are there route hints, LSP advertisements, or discovery mechanisms that Fiber should eventually support for this flow?

7. Where this came from

I ran into these questions while exploring a small hackathon prototype, but the broader point is not the prototype itself.

The useful part was that testing this path forced me to separate the UX claim from the protocol mechanics.

The UX claim I think is interesting:

A new user should be able to receive before managing inbound liquidity.

The honest technical boundary I found:

That does not remove all recipient-side CKB requirements, and a clean version probably needs stronger native Fiber interception and event support.

4 Likes