Spark Program | LiquidLane: Fiber Receive Capacity Marketplace | RESUBMISSION

DAOs & Funding Spark Program
1

1. Project Overview

LiquidLane is a CKB-native marketplace where merchants and applications obtain Fiber receive capacity from independent node operators. Providers publish capacity and opening fees, fund channels from their own wallets, and retain their keys. Merchants choose an offer, verify delivery, and pay the provider directly.

The product brings provider discovery, channel provisioning, delivery verification, and fee tracking into one workflow.

2. Team Profile

FidelCoder — Developer and maintainer. Responsible for LiquidLane’s Rust backend, local connector, and Next.js application, with hands-on experience building CKB transaction flows, JoyID authentication, and Fiber channel integrations.

Contact Details

3. Project Background

A working wallet or checkout does not automatically mean a merchant can receive Fiber payments. Receiving requires sufficient channel capacity funded by peers toward the merchant. CKB held in the merchant’s own wallet does not, by itself, provide that capacity. An application can therefore be correctly integrated while customer payments still fail because the receiving path lacks liquidity.

This creates a coordination problem on both sides. Merchants and application developers need to find funded peers, compare terms, and establish when receiving capacity is usable. Node operators need a way to advertise available capital, set prices and funding limits, and reach customers who need it.

Channel creation provides the underlying mechanism. A usable capacity market also needs discovery, clear service terms, delivery evidence, and payment records. LiquidLane brings those pieces together so acquiring receive capacity becomes a repeatable service for CKB wallets, merchant tools, and payment applications.

4. Solution

LiquidLane makes a defined amount of usable receive capacity available as a priced service. Providers publish how much they can supply and the opening fee they charge. Merchants can compare offers, understand the capital required by their receiving node, and choose terms suited to their payment needs.

Each purchase has an agreement signed by both parties, binding the participants, capacity, funding amount, fee recipient, and opening deadline. A local connector enforces the provider’s funding limits before committing capital. This makes provisioning repeatable while keeping spending authority with the node operator.

Delivery checks combine committed channel funding, matching observations from both nodes, and a paid test invoice. The agreed capacity must remain available after the test payment. A signed receipt records the agreement and delivery evidence, while fee tracking distinguishes paid, outstanding, and waived amounts.

Supply comes from operators committing their own capital to native bidirectional channels. They set their prices and earn opening fees and any routing fees actually received. Merchants pay for receiving capability and retain their incoming payments. LiquidLane gives these parties a common service agreement and operational record while native Fiber handles payment routing and settlement.

5. Technical Approach

The system combines a Rust/Axum coordinator, SQLite persistence, a local Rust connector, and a Next.js/TypeScript interface with JoyID signing. The release targets native CKB on testnet and Fiber 0.9.0.

Fund control: the coordinator holds no participant signing keys. Each connector independently checks signatures, funding limits, peer identity, and agreed fees. The node negotiates native channel funding and supplies its own closing destination. Funding and settlement use Fiber’s native CKB scripts.

Capacity accounting: a 500 CKB offer requires a 600 CKB provider contribution: 500 usable capacity, 99 native reserve, and 1 for the delivery probe. The merchant funds its own reserve, and both wallets need transaction headroom. These amounts are itemized before acceptance.

Payments and recovery: customer payments move through native Fiber channels. The provider receives corresponding value in its incoming channel; the merchant owns received payments. Existing payments and native closure remain available if the coordinator stops. Recovery follows Fiber’s settlement rules and delays, with confirmed wallet outputs checked separately from channel status.

Service boundaries: this product sells initial capacity. It does not guarantee duration or replenishment. Fees follow delivery and can remain unpaid; local limits bound provider exposure. Participants remain responsible for securing their node keys and current channel state.

6. To-Do List

Milestone 1 — Marketplace and onboarding improvements · Weeks 1–2

  • Week 1: package connector releases with checksums and installation instructions; add setup diagnostics for pairing, connectivity, service startup, and funding readiness.

  • Week 2: add offer filtering by capacity, fee, and availability; implement offer renewal while preserving accepted quotes; improve mobile onboarding.

Completion: an operator can install the packaged connector, diagnose setup problems, and publish or renew an offer. A merchant can find a suitable provider through the improved interface.

Milestone 2 — Reliability and beta release · Weeks 3–4

  • Week 3: add actionable recovery guidance for interrupted setup, uncertain payments, and pending settlement; introduce order/fee activity exports and activation metrics.

  • Week 4: automate coordinator backups and verify restoration; restore hosted API connectivity and persistent storage; test machine reboot, fresh-node JoyID funding, and interruption recovery.

Completion: publish a usable testnet release with working hosted services, documented recovery procedures, and passing checks that retries do not duplicate funding or payments. The market beta begins after this milestone.

Milestone 3 — Market beta and product iteration · Weeks 5–6

  • Week 5: recruit 30–40 beta participants through Nervos/Fiber communities and direct outreach to operators, merchants, and wallet/application builders. Target at least three independently operated providers.

  • Week 6: address beta defects, refine onboarding, and publish results covering usability, transaction completion, provider economics, and repeat-use interest.

Completion targets: 30–40 participants completing a role-specific workflow and feedback; at least ten completed capacity purchases across independent providers; a released update addressing reported issues. Report registrations, active participants, completed purchases, and failed or unpaid orders separately.

7. Required Funding & Funding Breakdown

Total requested: $1,000 USD.

  • Milestone 1 — $350: $300 for onboarding and marketplace development; $50 for connector packaging and installation documentation.

  • Milestone 2 — $350: $250 for reliability improvements and recovery testing; $100 for hosting, domain, and monitoring.

  • Milestone 3 — $300: $100 for recruitment and onboarding support; $100 for structured usability sessions and feedback collection; $100 for product fixes and the completion report.

Funding supports development, deployment, and participant testing. Node capital remains participant-controlled. An external security audit and mainnet deployment are outside this scope.

8. Deliverables + How to Verify

  • M1: packaged connector and improved marketplace. Install the published release on Linux x86_64, follow the setup guide, publish/renew an offer, and filter available capacity. Provide binaries, checksums, source changes, and a short walkthrough.

  • M2: hosted testnet release and recovery package. Open the app and health endpoint, complete a purchase, and inspect its funding, probe, and fee evidence. Publish restart, backup/restore, and payment-retry results with expected outputs.

  • M3: beta release and results report. Publish participant totals, completed workflows, transaction references, feedback, costs, and resolved issues. Count participants once; project-operated nodes do not count as independent providers.

Reviewers can inspect recordings, receipts, and explorer links without running nodes. Live reproduction requires compatible Fiber nodes, a CKB RPC/indexer, testnet funds, and a separate payer route. Build instructions specify Rust 1.91 and Node 22.

Verification guides:

9. Current State vs. Funded Work

Already implemented: wallet authentication, node pairing, signed quotes, local funding limits, durable orders, automatic channel opening, delivery checks, direct fees, and merchant/provider interfaces. Both repositories use the MIT license.

Demonstrated: automatic delivery of 500 CKB, a routed probe, a confirmed opening fee, one real JoyID purchase, and outage/recovery verification. These used project-operated nodes. The normal Rust suite passes 88 tests, with two additional tests ignored.

Evidence:

Funded additions: packaged connector distribution, setup diagnostics, offer filtering/renewal, recovery guidance, activity exports, automated backups, and hosted-release improvements, followed by the participant testing specified in Milestone 3. Hosted API restoration, full reboot testing, and JoyID funding of a newly managed node remain pending.

10. CKB Alignment

LiquidLane connects Fiber’s native channels with CKB settlement and JoyID wallet signing. Its open-source connector, marketplace API, and delivery receipts give CKB developers reusable components for acquiring receive capacity. This supports wallet and checkout integrations while keeping channel operation and capital under participant control

4 Likes
CKB Ecosystem Biweekly Update
2

Hi @Fidelcoder,

Thank you for taking the time to revise and resubmit the LiquidLane proposal based on our earlier feedback. The committee has completed its review and, after careful discussion, regrets to reject the LiquidLane project at this time.

We want to be transparent about the reasoning behind this decision:

1. **Security considerations were not adequately addressed**: As an infrastructure project handling channel funding and fee distribution, the proposal does not sufficiently address the security model — including fund custody, withdrawal paths, and what happens in the event of node downtime or malicious behavior from either party. The committee believes these risks should have been identified and mitigated at the design stage.

2. **Technical implementation remains premature**: The current implementation shows signs of incompleteness — interfaces are not fully connected, and the wallet connector relies solely on JoyID without leveraging CCC (CKBers’ Codebase), which is the recommended SDK and provides a unified wallet connection layer. Given that CKB already has well-established tooling in this area, the committee expects new projects to build on the existing stack rather than reinventing or bypassing it.

3. **Lack of demonstrated long-term operational commitment**: This is an infrastructure-level project, and the committee did not see evidence of a sustainable plan for ongoing maintenance, node coordination, and user support after the initial grant period. Infrastructure projects require continuous upkeep to remain viable, and the proposal does not adequately address this.

We appreciate the work your team has put into LiquidLane and acknowledge the effort behind the resubmission. However, the committee suggests that rather than targeting bottom-layer infrastructure — which demands significant experience and long-term commitment — you consider pivoting toward **application-layer development**. There is meaningful value to be created by building user-facing payment experiences, merchant tools, or wallets that integrate with existing infrastructure such as Fiber Network, rather than attempting to build the infrastructure itself.

If in the future you plan to develop a more scoped, application-focused project with a clear security model and demonstrated technical readiness, we would welcome a new application.

Thank you very much for all the hard work your team has put in. Keep building, and feel free to reach out anytime!

Best,
xingtian
On behalf of the Spark Program Committee

2 Likes
3

Hi @Fidelcoder ! It’s great to see you are considering liquidity and Fiber.

Wanted to share some recent info about liquidity service providing on CKB. Feel free to check out the PR and share any questions!

3 Likes