Author: FidelCoder
Repositories:
-
Webview: https://liquidlane-app.vercel.app
Demo: https://drive.google.com/file/d/1jfSY4kYgRP86vftWiE-WNOmGp8CBzIRF/view?usp=sharing
Network: CKB testnet (Pudge). This proposal works against testnet and does not claim production or mainnet status.
One-paragraph summary
LiquidLane lets CKB liquidity providers pool capital in an on-chain vault that funds specific one-way Fiber channels for merchant receive capacity. Merchants receive no vault access, provider-node access, or withdrawable loan balance; they start with zero channel balance. Each customer payment atomically moves value into LiquidLane through an incoming channel while LiquidLane forwards equal value through the merchant channel. At expiry, LiquidLane rebalances or closes the relevant channels, settles its balance to a fixed recovery lock, and returns confirmed funds to the vault. This proposal asks Spark to harden that complete funding, custody, recovery, and LP-accounting path.
Project inception
LiquidLane was built during the Gone in 60ms Fiber Network Infrastructure Hackathon. The project entered as a protocol-scope prototype and missed the prizewinning positions by a margin, the hackathon results listing notes it as Highly commended, describing it as a CKB-native liquidity layer where providers supply capital to secure vaults that LiquidLane deploys into Fiber payment channels for merchants: https://pudge.explorer.nervos.org/transaction/0x1ef53454fed765a8d6d9a6c17174ef29436da68ddb9e9238bec5e302e434c4ae
That distinction matters here because it is the right way to read the project’s current state. The hackathon validated that the idea is credible and that the core funding path is real. It also surfaced the exact hardening work this proposal exists to fund.
The deployment is documented in the repository at liquidlane-core/ckb-scripts/deployments/testnet-2026-07-14-1ef53454fed7.json, which records the deployment transaction, the deployer address, and all six deployed script code hashes with their names.
The gap LiquidLane targets
Fiber channels move value between peers, but the capital that backs those channels still has to come from somewhere. In the current model, each node operator usually funds its own channels from its own wallet. That is workable for small experiments, but it does not give the network a durable liquidity layer, and it leaves a structural question unanswered: where does channel capital come from at scale, and how do LPs earn a return for providing it without handing operators an unstructured pool of funds?
LiquidLane’s answer is a vault model:
-
LPs supply CKB to an on-chain vault and receive an LP receipt position that records supplied, available, reserved, deployed, and claimed balances.
-
Merchants request receive capacity; the system reserves LP liquidity against that request and records a capacity-request cell on chain.
-
When the merchant is ready, LiquidLane submits an external-funding flow to Fiber so the reserved vault liquidity can be moved into a Fiber funding lock.
-
Fees are earned as channels become active, and LPs can withdraw available liquidity or claim earned fees through authenticated on-chain transactions.
That design targets a real infrastructure gap: a bridge between on-chain pooled capital and Fiber channel demand. It is not a consumer wallet, not a dashboard skin, and not a sandbox visualization. It is protocol-facing plumbing.
Fund security after channel funding
LiquidLane does not lend withdrawable funds to merchants.
LP vault: 200,000 CKB
→ 150,000 allocated to a one-way Fiber channel
→ LiquidLane balance: 150,000
→ Merchant balance: 0
→ Vault remains with 50,000 available
Neither the merchant nor its application can access the vault, LiquidLane’s Fiber RPC, or LiquidLane’s signing keys.
When customers pay the merchant:
Customer funds
→ LiquidLane receives value through an incoming Fiber channel
→ LiquidLane forwards equal value through the merchant channel
→ Merchant receives the payment
For example, after 120,000 CKB of payments:
Vault available: 50,000 CKB
+ LiquidLane merchant-channel balance: 30,000 CKB
+ LiquidLane incoming-channel balances: 120,000 CKB
= 200,000 CKB recoverable, excluding earned fees and costs
The value is therefore moved between LiquidLane’s channels, not borrowed and later repaid by the merchant. Fiber HTLCs ensure that LiquidLane’s outgoing payment settles only with the corresponding incoming payment.
At lease expiry:
Stop new routing
→ allow pending HTLCs to settle
→ rebalance or close the relevant channels
→ settle LiquidLane's balances to a fixed recovery lock
→ sweep confirmed outputs into the vault
→ change deployed liquidity back to available
If recovery is not yet confirmed, the amount remains deployed and cannot be withdrawn or reused. New funding stops if recoverable assets fall below LP liabilities.
LP participation and liquidity sustainability
LiquidLane will bootstrap with a capped operator-funded pool. External LP deposits will open only after the custody and settlement milestones are complete.
LP revenue comes from:
Merchant lease fees paid upfront
+ verified Fiber routing fees
→ distributed proportionally to deployed LP capital and deployment time
The current lease-fee model is:
amount × duration in days ÷ 3,000
A 150,000 CKB allocation for 30 days therefore pays a 1,500 CKB lease fee, equivalent to 1% for the lease period. Routing fees are additional revenue and are counted only after they are actually received.
Liquidity controls:
-
Maximum 80% of the pool may be deployed.
-
At least 20% remains available for withdrawals and operations.
-
New requests are capped when the reserve floor is reached.
-
Lease pricing increases as utilization approaches the limit.
-
Available liquidity can be withdrawn; deployed liquidity enters a withdrawal queue until verified recovery.
-
The model does not depend on token emissions. Long-term LP returns must come from merchant demand and routing revenue.
What exists today
The current codebase is a complete enough prototype to prove the shape of the system:
-
A Rust core exposing a REST API for wallet sessions, vault supply, withdrawals, fee claims, liquidity quotes, request intents, capacity reservations, Fiber peer attachment, deployment packaging, and operator/executor operations.
-
A Next.js console that walks LPs through supply and merchants through capacity requests, using JoyID for CKB testnet signing.
-
CKB-native scripts for vault custody, vault accounting, LP receipts, capacity requests, fee claims, and the vault-funded path.
-
A Fiber JSON-RPC client that can list channels, connect peers, submit channel opens, and participate in the external-funding handshake.
-
An executor/funding-builder path that can match an in-flight reserve to a Fiber funding callback and build a vault-funded CKB transaction.
-
A confirmed testnet transaction that moved 200 CKB from reserved vault accounting into a Fiber funding output using Fiber’s testnet funding lock.
The implementation also ships with an honest internal audit note and an explicit warning that the scripts are not production-ready. That posture is correct for a hackathon project entering a grant cycle.
Internal audit note: liquidlane-core/ckb-scripts/AUDIT.md
Live testnet artifacts:
-
Confirmed vault-funded Fiber funding transaction: https://pudge.explorer.nervos.org/transaction/0x8b54d198e9a5e8decf476af5c341f27fa43a31edfecdce7e6feced7419c27276
-
Script deployment transaction that created all six CKB scripts (vault lock, vault type, LP receipt type, capacity request type, fee-claim type, funding-intent type) is the proof that these code hashes are LiquidLane’s deployed scripts: https://pudge.explorer.nervos.org/transaction/0x1ef53454fed765a8d6d9a6c17174ef29436da68ddb9e9238bec5e302e434c4ae
What Spark support would fund
The proposal has three milestones. Each milestone is scoped to a hard dependency, not a broad wishlist.
Milestone 1 Trust and access control ($350)
Problem: The current prototype’s authentication and role model are not safe enough to expose as infrastructure. Wallet sessions and role assignment need real signature binding, server-side role policy, and a clear split between public product endpoints and internal/operator endpoints.
Deliverables:
-
Replace the current connect/challenge flows with a signature-bound verification model: the backend verifies that a signature is bound to the claimed CKB address and wallet context before issuing tokens or changing roles.
-
Enforce server-side role policy so callers cannot self-assign operator privileges.
-
Separate public product endpoints from internal/operator endpoints with explicit authentication and least-privilege access.
-
Keep the LiquidLane Fiber RPC and channel keys inaccessible to merchants and applications; public APIs must never expose payment-originating or fund-moving node methods.
-
Add an open-source license to both repositories.
Why it matters: A liquidity system that cannot reliably identify who is asking for what is not ready for the next step. This milestone closes the most basic trust gap.
Milestone 2 On-chain funding-intent enforcement and signer isolation ($350)
Problem: The current funding-builder boundary is not safe as-is. In the prototype it matches reserves too broadly, can accept caller-controlled RPC targets, and uses the executor key on a request input without binding the negotiated funding destination strongly enough on chain. The documented funding-intent proof is not yet enforced by the actual funding transaction and script execution path. That combination is the difference between we built something that happened to fund a channel and we built a system that can be trusted with pooled capital.
Deliverables:
-
Make the funding-builder callback request-specific and destination-specific: a callback should only be able to build a funding transaction for a genuine, authenticated, in-flight reserve and only toward the negotiated funding lock.
-
Remove caller control over the RPC host used to construct fund-moving transactions. Core should use a configured/allowlisted CKB RPC, not an arbitrary URL supplied by the funding callback.
-
Enforce the funding-intent proof on chain so reserved vault capacity can only be moved in a way that binds the matching request and negotiated funding lock.
-
Isolate the signer: the key that signs executor/funding actions should be treated as a least-privilege signing boundary, not implicitly shared with everything else in the process.
-
Bind every funding transaction to the request ID, amount, merchant peer, negotiated Fiber funding lock, LiquidLane-controlled recovery lock, and lease expiry.
-
Ensure the merchant begins with zero funded balance and cannot redirect the provider-side channel balance.
-
Add tests demonstrating that reserved vault capacity cannot be redirected to an arbitrary lock through the funding flow.
Why it matters: This is the core value claim. If Spark funds anything, it should fund making the funding path safe enough to be evaluated as infrastructure.
Milestone 3 Channel recovery, solvency, and settlement integrity ($300)
Problem: Hosted off-chain state can drift from the live on-chain vault, which is unacceptable for a custody-adjacent system. Settlement and release accounting also need to be tied to verifiable proof that liquidity actually returned to the vault, rather than allowing a request to be marked settled without chain-backed evidence.
Deliverables:
-
Track LiquidLane-owned value across the vault, active channels, incoming channel balances, pending settlements, and recovery outputs.
-
Implement the expiry lifecycle: active → draining → rebalancing/closing → recovered → settled.
-
Rebalance liquidity where possible and close the necessary channels where rebalancing is unavailable.
-
Credit deployed liquidity back to available only after a confirmed settlement output reaches the approved recovery lock and is swept into the vault.
-
Add a solvency circuit breaker that prevents new funding when recoverable assets are below LP liabilities or the 20% reserve floor.
-
Test an end-to-end scenario covering channel funding, customer payments, balance movement, channel closure, and vault recovery.
Why it matters: A liquidity system that loses its state or drifts from the chain is not operable. This milestone makes the system recoverable and verifiable.
Budget
Total requested: $1,000
-
Workforce: $490
-
CKB testnet node deployment for integration and verification: $130
-
Domain and deployment setup for the hardened public demo endpoint: $70
-
Verification and review: $175
-
Documentation: $135
KPIs
LiquidLane should be considered Spark-ready when:
-
Wallet actions are authenticated through real signature binding and role policy is enforced server-side.
-
The funding path binds reserved vault capital to the negotiated funding destination and cannot be abused to redirect LP capital to an arbitrary lock.
-
The system can recover and reconcile its state from the chain.
-
Settlement accounting is backed by verifiable vault-return proof.
-
The CKB scripts have meaningful transaction-level tests and an honest internal audit path.
-
The project has a clear open-source license and a reproducible demo/integration story.
-
Merchants and applications have no access to LiquidLane’s Fiber RPC or signing keys.
-
A full payment-and-recovery test returns confirmed LiquidLane-owned channel value to the vault.
-
No deployed amount becomes available from an internal status update alone.
-
Pool deployment never exceeds 80%, and funding stops below the 20% reserve floor.
-
LP earnings distinguish upfront lease fees from routing fees actually received.
A secondary KPI is ecosystem usefulness: another operator, LP, or Fiber-infrastructure builder should be able to look at LiquidLane and see a plausible model for pooled channel liquidity, not just one team’s hackathon build.
Why this is a good Spark fit
-
It is infrastructure, not a consumer skin. The primary deliverables are vault scripts, executor/funding logic, liquidity state, and operator tooling.
-
It addresses a real gap. Fiber channels need a practical path between operator demand and external capital sources.
-
It already has proof of concept. A live vault-funded Fiber transaction on testnet shows the key path is real, not a mock.
-
It has a clear hardening path. The hackathon review gave LiquidLane strong marks for scope, originality, and execution evidence, and also gave a concrete list of reliability and security issues. That makes this a strong Spark candidate: there is something real to harden, not an empty idea to speculate about.
-
It is honest about risk. The project already documents its own limitations and explicitly says the scripts are not production-ready. Spark funding should be used to move that posture from honest warning to accountable readiness.
Current state vs funded work
Already built:
-
Vault supply, reservation, request, prototype settlement accounting, and fee-claim flows; enforced channel recovery and vault-return settlement remain funded work.
-
CKB-native vault, receipt, request, fee-claim, and funding-intent scripts
-
Fiber JSON-RPC client and executor/funding-builder path
-
Next.js console with JoyID testnet signing
-
Confirmed testnet funding transaction moving 200 CKB from reserved vault capacity into a Fiber funding output
Funded by this proposal:
-
Authentication hardening, role policy, endpoint split, and licensing
-
Request-specific, destination-bound funding, RPC allowlisting, signer isolation, and on-chain funding-intent enforcement
-
Channel and chain-derived recovery, portfolio solvency accounting, and verifiable vault-return settlement
Risks and mitigations
Risk: Pooled capital increases the cost of security mistakes.
Mitigation: Treat authentication, funding-destination binding, signer isolation, settlement proof, and state recovery as hard requirements, not optional polish. Do not expose value-handling paths until they are safe.
Risk: The CKB scripts are the trust root and are still evolving.
Mitigation: Invest in transaction-level tests and internal audit preparation before any production claim; keep the live deployment on testnet while the script set matures.
Risk: The external-funding path spans both CKB and Fiber, which makes integration and debugging harder.
Mitigation: Make the funding-builder boundary explicit, authenticated, and auditable; improve logs, state reconciliation, and operator visibility so failures are recoverable and explainable.
Risk: A custody-adjacent system can be misunderstood as more mature than it is.
Mitigation: Keep language disciplined. LiquidLane is not a bank, not a guarantee, and not an audited custodian. It is an infrastructure prototype aiming for auditable safety.
Risk: Deployed funds are controlled by an online Fiber node.
Mitigation: Isolate its keys and RPC, restrict payment-originating methods, maintain durable channel backups and watchtower coverage, and cap total deployed exposure.
Risk: LP supply may be insufficient for merchant demand.
Mitigation: Begin with capped operator capital, onboard merchant demand before expanding deposits, publish transparent fee and utilization data, and use utilization-based pricing without relying on token emissions.
Closing note
The hackathon result was not the top finish, and the evaluation makes that honest to see. The same evaluation also says the project has one of the strongest protocol-level ideas and execution evidences in its cohort. That is a better starting point than a perfect score on a narrower project.
The right ask for Spark is therefore not continue the demo. It is fund the hardening path that turns a compelling prototype into infrastructure the CKB and Fiber ecosystem can actually evaluate, reuse, and trust with pooled liquidity. That is the proposal LiquidLane wants to be judged on.