Our vision for Scryve has always been simple: let a reader reward a writer with a fraction of a CKB. True microtipping, where even a few cents of appreciation is worth sending.
A few months ago we wrote about the one thing standing in the way. On CKB, every live cell must hold at least 61 CKB of capacity, closer to 65 once you account for fees, because on CKB capacity is the right to occupy global state (this is the state-rent design that keeps the chain sustainable). Beautiful for the network, brutal for tiny payments: a 1-CKB tip would mean locking up 65. The economics are broken. The UX is broken.
So on Scryve, our long-form publishing platform, we built custodial tipping to make that fraction-of-a-CKB tip viable: a “prepaid card” where you deposit once, tip instantly off-chain, and settle to your wallet only when it is worth a transaction. It works, it feels great, it runs on testnet, and we keep developing it. We were also upfront about the catch: for now, you trust us to hold the balance. We called it a bridge, not the destination, and promised to keep pushing toward something more decentralized.
The pieces are coming together, and we want to show you what we have been building.
Introducing Liquid Cells
Liquid Cells is a new protocol developed by Luso Crypto Labs, the team behind Scryve. It is not a Scryve feature. It is a general, non-custodial microtipping and micropayment protocol for CKB that any app can build on, and Scryve will simply be the first to use it.
We will be honest about what is and is not new. We did not invent zero-knowledge proofs, and verifying a proof on CKB has been done before. What we built is the whole thing working end to end, live on a public CKB testnet, aimed at a real product: a pooled micropayment system where on-chain cryptography, not a company, keeps everyone honest. As far as we know, that makes Liquid Cells the first non-custodial microtipping protocol of its kind running live on CKB.
The goal is to keep everything that makes microtipping feel good (instant, sub-cent, fee-less) and remove the one thing that makes it a compromise: custody.
flowchart LR
subgraph THEN["Scryve tipping today (custodial, on testnet)"]
A1[Reader deposits CKB] --> A2[We hold the balance]
A2 --> A3[Tip a writer instantly]
A2 -. you trust us not to .-> A5(((steal · freeze · vanish)))
end
subgraph NOW["Liquid Cells by Luso Crypto Labs (non-custodial, coming soon)"]
B1[Reader deposits CKB] --> B2[A cell holds it, not us]
B2 --> B3[Tip a writer instantly]
B2 == enforced by CKB ==> B5(((nobody can steal · freeze · trap)))
end
Tips still live in a shared pool, so thousands of fractional payments collapse into one tiny on-chain footprint. But “pooled” no longer means “ours.” The design makes it pooled, and provably yours.
What non-custodial will mean for a reader or a writer
Three promises, and not one of them is “trust us”:
- Nobody can take your balance. Nothing moves without your signature.
- Nobody can invent or inflate balances. The books always balance, and the chain checks the math.
- Nobody can trap your funds. If the operator goes offline, disappears, or turns evil, a reader or a writer can reclaim their balance using public chain data alone. No permission, no cooperation, no middleman.
That last one is the whole game. The exit is not a support ticket. It is a property of the system.
sequenceDiagram
actor Reader
participant Pool as Liquid Cells (an on-chain cell)
actor Writer
Reader->>Pool: Deposit once
Reader->>Pool: Tip a fraction of a CKB on an article (instant, free, off-chain)
Pool->>Writer: Balance goes up
Note over Reader,Writer: thousands of microtips, one small on-chain checkpoint
Note over Reader,Pool: Operator vanishes?
Writer->>Pool: Exit, reclaim earnings from chain data alone
The same cell model that made microtips hard at Layer 1 is exactly what makes this work. CKB’s cells are programmable and can verify real cryptographic proofs on-chain, so a single anchor cell can stand in for a whole ledger of tiny balances while letting anyone prove what they are owed. The constraint became the tool.
Why this matters beyond Scryve
Liquid Cells is a protocol, not a product, and Luso Crypto Labs is building it for anyone to use. Payment channels like CKB’s Fiber Network are one great answer to micropayments; Liquid Cells is a different shape, a shared pool with no per-user channel to fund, which fits “many people sending tiny amounts” especially well. Reader-to-writer microtipping is the first home we have in mind, but the same rails fit creator payments, pay-per-read, in-game economies, and any case where the amounts are small and the volume is large. No custodian, no outside chain to trust, just CKB doing what only CKB can.
Where we are (honestly)
Same honesty as last time. Liquid Cells is highly experimental. It is live on the Pudge testnet as a standalone system: real proofs verifying inside CKB on a public chain, a chain of checkpoints landing, a checkpoint that advanced with no signature at all, and a real unilateral exit already demonstrated from chain data alone. But it is unaudited, testnet-only, and not for real funds. It is not yet live on Scryve: the tipping you use today still runs on the custodial bridge while Luso Crypto Labs keeps building, testing, and working toward an audit. A few honest edges remain on the roadmap (a smoother emergency-exit path, faster settlement, and locking down the upgrade key), and we will keep being plain about them. Liquid Cells is coming to Scryve soon.
The microtipping we shipped first was elegant, pragmatic, secure. Liquid Cells is the next step: elegant, pragmatic, and a real move toward decentralized.
The bridge got us here. This is the road ahead. More soon. 
— The Scryve team, built by Luso Crypto Labs
Further reading
