Thank you, this is the right pushback, and you are correct that the justification has to live in the comparison rather than in a “different shape” hand-wave. Let me give the honest version, including where Fiber wins and where my earlier framing was too glib.
First, a concession that reframes the whole thing: you are right that this is not really “pool vs channels.” Any payment-channel design that lets thousands of sporadic, long-tail writers receive tips without each funding their own channel does so by introducing a hub that provisions inbound liquidity (LSP-style). So the honest comparison is non-custodial pool vs hub, and the real question is what kind of hub.
Today, the channel-free version of Fiber tipping is a custodial hub. The clearest evidence is the other Fiber-based tipping proposal on this forum, Fiber Link, which describes itself as a custodial/hosted hub with an internal ledger per user. That is a reasonable design. It is essentially what our own custodial Scryve tipping already is. Liquid Cells is an attempt to build that same “receiving is just a ledger entry” hub, but non-custodially: the operator cannot steal or inflate balances (enforced by an on-chain validity proof), every balance is reconstructable from on-chain data, and any writer can exit unilaterally if the operator vanishes.
The four models honestly, conceding Fiber’s wins:
| Axis | Fiber (channels + hub/LSP) | Liquid Cells (non-custodial pool) |
|---|---|---|
| Trust | No protocol operator for a direct channel, and a direct channel is more decentralized than us. But channel-free long-tail receiving needs a hub, and today that hub is custodial. | One operator, but provably non-custodial: cannot steal or mint (validity proof), balances reconstructable from on-chain data, unilateral exit. Adds a single upgrade key, which we are still locking down. |
| Liveness | Direct channels are peer-to-peer; safety needs you online or a (third-party) watchtower. | Operator advances checkpoints (a central liveness dependency), with unilateral exit as the floor; ordinary users carry no online burden. |
| Exit | Close a channel you already hold; cooperative close is fast. | Withdraw anytime via the operator; emergency exit only after a ~30-day operator-silence window, and it lands a cell of at least 61 CKB, so exiting a dust balance is the weak spot today. |
| Liquidity / receiving | The inbound-liquidity problem: channel-free receiving needs a hub or LSP. Lightning has these; for Fiber they are on the 2026 roadmap, not yet shipped. | Zero per-user and per-creator liquidity; receiving is a ledger entry; one shared anchor cell amortized across everyone. |
I want to scope this honestly. The argument is specifically about long-tail, sporadic, many-recipient inbound. For a single high-volume, always-online creator with two-way flow, a direct Fiber channel is the better tool, likely cheaper and more private, and we would not argue otherwise. We are also not claiming a raw on-chain-cost win: a mature hub-and-channel-factory Fiber could well be cheaper per tip than our periodic zk-checkpoints. The claim is narrower and we think defensible: for the long-tail receiving case, Liquid Cells offers the same instant “just receive” UX as a custodial hub, with strictly stronger guarantees.
One correction to something I said earlier, in case it spread: our sub-61-CKB egress via a Fiber atomic swap is design and roadmap, not shipped. The in-pool escrow leg (the hash-locked leg with a sender-side refund) is built and tested; the Fiber integration and the liquidity-provider side are not, and the receiver-side force-claim is explicitly unbuilt for now. So please read “complementary with Fiber” as intent, not a working feature.
And the honest caveats stand: testnet only and unaudited; ~7-minute settlement per checkpoint (faster proving and instant soft-confirmation receipts are planned, not shipped); the ~30-day exit window and 61-CKB exit-cell floor noted above; and the single upgrade key (a timelocked upgrade lock is built and tested, but not yet adopted on the live deployment).
Thank you for your valuable input on this.
Scryve Team