Spark Program | Fiber Submarine Swap Service
Project Name
Fiber Submarine Swap Service — A working testnet implementation of a submarine swap for the Fiber Network, solving the inbound liquidity problem that prevents new users from receiving payments on Fiber.
Team / Individual Profile
Tefro Labs.
We are a small developer team with direct, hands-on CKB development experience. We have worked against the CKB RPC and transaction model directly, and we have been actively engaging with the Fiber Network documentation and codebase in preparation for this project. We are not a team that found a grant and looked for an idea to fit it — this is a problem we identified from reading the ecosystem’s own conversations and confirmed was genuinely unsolved before writing a single line of this proposal.
The Problem
When a new user joins the Fiber Network and opens a payment channel, all of the channel’s capacity starts on their side. This means they can send payments immediately, but they cannot receive any payments until someone else has opened a channel toward them or they have acquired inbound liquidity through some other means. For most new users, this is invisible until they try to receive their first Fiber payment and nothing arrives. There is currently no service in the Fiber ecosystem that solves this.
This is not a theoretical concern. It is a structural property of how payment channel networks work, and it is the single most common friction point for new node operators on any payment channel network. On the Lightning Network, this problem has been solved for years through a mechanism called a submarine swap — a user pays on-chain, and in exchange receives inbound channel capacity, with the entire exchange secured atomically so that neither side can cheat or walk away mid-swap. On Fiber Network, no equivalent service exists. Community member janx, one of the most credible and technically engaged builders in the Nervos ecosystem, raised this directly in the Nervos Talk Idea Hunt thread and described a submarine swap service as “extremely helpful” for Fiber user onboarding. Nobody responded to say they were building it, because nobody is.
The absence of this service creates a ceiling on Fiber adoption. A developer who wants to demonstrate Fiber payments to a user, or a merchant who wants to accept Fiber payments, or a node operator who wants to participate in routing — all of them hit this wall immediately. The Fiber Network has the protocol-level infrastructure to support a solution. The community has named the gap explicitly. What is missing is someone to build it.
Why This Has Not Been Built Yet
The reason no one has built this for Fiber yet is a meaningful technical distinction that separates Fiber from Lightning and makes a direct port impossible. The Lightning Network uses Hash Time-Locked Contracts, or HTLCs, as the cryptographic mechanism that makes submarine swaps atomic and trustless. Fiber Network uses Point Time-Locked Contracts, or PTLCs, which are more cryptographically advanced and provide better privacy properties, but they require a different implementation approach. Every existing submarine swap implementation in the Lightning ecosystem — Loop by Lightning Labs, Boltz, and others — is built on HTLCs and cannot simply be dropped into a Fiber context. This is why the gap still exists despite the problem being well understood. Building a submarine swap for Fiber requires working from Fiber’s own primitives rather than porting existing code.
This is not a blocker — it is a scope clarifier. It means the first week of this project is explicitly dedicated to auditing Fiber’s RPC documentation and on-chain script infrastructure to confirm exactly which primitives are available and how the PTLC locking mechanism needs to be structured for a submarine swap. The output of that investigation will be published publicly on Nervos Talk as a standalone technical writeup, so the community benefits from the research regardless of anything else. This is the honest way to scope a project where the technical path is clear in direction but requires confirmation in specifics, and it gives the committee a concrete, verifiable first milestone that requires no trust in our claims about the subsequent work.
The Solution
The Fiber Submarine Swap Service is a working testnet implementation of the submarine swap mechanism for Fiber Network, built in three parts that together form a complete, usable, and verifiable system.
The first part is the swap backend. This is a service that runs a Fiber Network node funded with a testnet CKB liquidity pool. When a user requests a swap, the backend generates a unique on-chain CKB deposit address for that specific request and begins watching the CKB chain for a confirmed deposit to that address. Once the deposit confirms, the backend uses Fiber’s PTLC mechanism to push an equivalent amount of inbound channel capacity to the requesting user’s Fiber node. The PTLC locking ensures that the capacity push and the on-chain deposit are atomically linked — either both sides of the swap complete successfully or neither does, so neither the user nor the service can lose funds in a failed or interrupted swap. The backend is written to be straightforward to run independently, so any developer or liquidity provider who wants to operate their own swap service can do so from the open-source code.
The second part is a minimal web interface. It is a single page with a clear, simple flow. The user enters their Fiber node’s public key and the amount of inbound capacity they want. The interface displays a CKB deposit address and the exact amount to send. As the on-chain transaction confirms and the Fiber capacity is pushed, the interface updates in real time to show the swap progressing through each stage. There are no accounts, no registration, and no custody of user funds at any point — the swap is executed directly between the user’s Fiber node and the service’s Fiber node. The interface is designed to be usable by someone who has just set up their first Fiber node and is encountering the inbound liquidity problem for the first time.
The third part is the open-source repository and documentation. Every line of code for the swap backend and the web interface will be publicly available on GitHub from the first commit under the MIT License. The README will explain what the service does, how to run the testnet demo end-to-end, how to run your own instance of the swap service with your own liquidity, and what the PTLC locking mechanism looks like in practice. The goal is that any developer reading the repository can understand not just how to use the service but how it works, so this becomes a foundation others can build on rather than a black box.
Relevance to the CKB Ecosystem
The Fiber Network is one of the most important infrastructure pieces the Nervos ecosystem is building in 2026, and the committee has named it explicitly as a priority area. Several Spark-funded and community projects already serve the Fiber ecosystem — Fiber Demo Startup handles local development environments and node setup, fiber-checkout provides a React payment integration library, and Fiber Link handles forum tipping. Each of these fills a real gap. None of them addresses liquidity. This proposal fills the one remaining gap that directly limits how many users can participate as receivers on the network, which is a different and more fundamental problem than any of the existing projects solve.
Building this on Fiber testnet first, with a small fixed liquidity pool, means the scope is appropriate for the Spark program and the timeline is realistic. This is not a production financial service — it is a working, auditable proof of concept that demonstrates the mechanism works on Fiber, documents how it works, and gives the ecosystem something to build on. The code being fully open source means the Fiber core team, future liquidity providers, or any other community builder can extend it into a production service if they choose to.
The community thread where we asked about PTLC feasibility already showed that this topic generates engagement from people who care about Fiber’s development. Publishing the Week 1 technical investigation on Nervos Talk continues that engagement and gives something back to the community before the main deliverable is complete.
How to Verify
The committee can verify every deliverable in this proposal without any special setup beyond running a standard Fiber testnet node, which is already documented in the Fiber Network repository.
For the first milestone, the verifier reads the technical investigation writeup published on Nervos Talk. It should clearly identify which Fiber RPC calls are used in the swap flow, how the PTLC locking is structured on the CKB on-chain side, and what edge cases were identified. This writeup stands on its own as a community contribution regardless of the subsequent work.
For the second milestone, the verifier opens the swap web interface URL from the README, enters their Fiber testnet node’s public key and a small capacity amount, sends the specified testnet CKB to the generated deposit address, and watches inbound capacity arrive at their node. They can confirm the inbound capacity arrived by calling the Fiber RPC’s list_channels method on their own node and seeing the new inbound balance reflected. They can also clone the open-source repository, read the swap logic and PTLC locking code directly, and run the entire system locally if they want to verify the implementation beyond using the hosted testnet demo. The README provides step-by-step instructions for doing exactly this.
Requested Funding
The total requested amount is $1,000 USD, paid in CKB, which falls within the Spark Program’s pure technical budget cap. The CKB equivalent will be calculated at the time of formal approval per the program’s standard pricing-snapshot convention. Disbursement follows the program’s standard 20% / 80% split across two milestones.
Milestone 1 — $200 (20%)
The first milestone covers the Week 1 technical investigation. The deliverable is a publicly published writeup on Nervos Talk that identifies which Fiber RPC calls are used in the swap flow, how the PTLC locking mechanism needs to be structured on the CKB on-chain side, what on-chain script primitives from the fiber-scripts repository are relevant, and what edge cases or constraints were discovered during the audit. This milestone requires no trust in future delivery. The writeup either exists and answers these questions or it does not, and any community member can read it and judge its quality independently. The $200 covers one week of focused research and technical writing. Payment is requested upon publication of the writeup on Nervos Talk with a link provided to the committee.
Milestone 2 — $800 (80%)
The second milestone covers the remaining five weeks of the project and encompasses all of the building work. This includes the swap backend, which is the on-chain deposit watcher, the Fiber node integration, the PTLC locking implementation, the deposit confirmation logic, the capacity push mechanism, and the error handling that makes the service robust against interrupted or failed swaps. It also includes the single-page web interface covering node ID input, deposit address generation, and real-time swap status display. It includes the complete end-to-end testnet demo running against real Fiber testnet conditions. And it includes the open-source repository with a README that explains how to reproduce the full swap flow and how to run an independent instance of the service. The $800 reflects the fact that the swap backend and PTLC integration are the most technically demanding work in the project, that the testnet integration requires real operational effort beyond local development, and that documentation is treated as a first-class deliverable because the ecosystem value of this project depends on other developers being able to understand and extend it. Payment is requested upon submission of the completion report with links to the live testnet demo, the open-source repository, and verification instructions following the process described above.
Estimated Timeline
The project runs across six weeks. The first week is dedicated entirely to the technical investigation — auditing Fiber’s RPC documentation, reviewing the fiber-scripts repository for relevant on-chain script primitives, and writing up the findings publicly. This happens before any backend code is written, because the findings directly inform how the PTLC locking is implemented. Weeks two and three build the swap backend, starting with the on-chain deposit watcher and Fiber node integration in week two, and completing the deposit confirmation logic, capacity push mechanism, and error handling in week three. Week four builds the web interface, keeping it deliberately simple — node ID input, deposit address display, real-time status updates. Week five integrates everything on the Fiber testnet, runs the end-to-end swap flow against real testnet conditions, and handles the edge cases that only become visible when the full system is running together. Week six is documentation, polish, and a buffer for committee feedback before the completion report is submitted.
Open Source Commitment
This project will be released under the MIT License. The repository will be public on GitHub from the first commit, not just upon completion. The Spark Program committee and any community member can follow progress in real time throughout the six-week build. The repository will be structured so it can be forked into the Spark-Program GitHub organization per the program’s knowledge-base policy, and the README will explicitly invite other developers to run their own instances of the swap service using the provided code.