[DIS] fiber-payjoin-kit: Collaborative Privacy for the Nervos Fiber Network

[DIS] fiber-payjoin-kit: Collaborative Privacy for the Nervos Fiber Network

Executive Summary

As the Nervos ecosystem rolls out the Fiber Network (CKB’s native Lightning Network equivalent), establishing robust privacy and payment primitives early is critical. While Fiber enables high-throughput, low-cost off-chain payments, standard payment channels suffer from blockchain surveillance heuristics (input/output mapping).

fiber-payjoin-kit is an open-source, asynchronous Rust library that brings collaborative Payjoin privacy natively to the Nervos Fiber Network. By allowing the receiver to contribute inputs to the funding transaction of a state channel, it completely breaks the common-input ownership heuristic, ensuring off-chain CKB payments remain entirely private.

This proposal seeks a $25,000 Development Grant

Funding Request

Component Amount Purpose
Development Grant (Phase 1) $25,000 Core Rust library, Fiber Network integration, CLI, and Documentation

1. The Problem: Off-Chain Privacy Leaks

The Fiber Network is designed to scale CKB transactions. However, when users open payment channels on UTXO-based chains, blockchain analytics firms use the “common-input heuristic” to assume that all inputs in the funding transaction belong to the channel initiator. This permanently links the identities of the sender and receiver before the off-chain payment even begins.

Without protocol-level privacy primitives built into the Fiber Network SDKs early on, institutional capital and privacy-conscious users will hesitate to route significant volume through the network.

2. The Solution: Collaborative Funding (Payjoin)

fiber-payjoin-kit solves this by introducing collaborative transaction building.

Instead of the sender funding the entire Fiber channel opening themselves, the receiver also contributes input Cells to the transaction. To an outside observer on the CKB L1, the funding transaction looks like a standard multi-party coinjoin or an unrelated script execution. It becomes mathematically impossible to determine who funded the channel, who is the sender, and who is the receiver.

Key Features:

  • Asynchronous Rust API: Designed to drop cleanly into existing Fiber node implementations and wallets.
  • Non-Interactive Fallbacks: Seamlessly falls back to standard channel openings if the receiver’s node goes offline.
  • Cell-Model Native: Optimized specifically for CKB’s UTXO and Cell-Deps architecture, avoiding the heavy computational overhead of EVM-based mixers.

3. Why Now? (The Timing)

The Nervos ecosystem is actively rolling out the Fiber Network. If robust privacy primitives are not established before significant liquidity migrates to these off-chain channels, user privacy will be permanently compromised by early blockchain surveillance indexing. Building this now ensures privacy is a native, default option from day one of the Fiber Network’s lifecycle, rather than an afterthought patched in later.

4. Why Us? (Direct Prior Work)

We are not building this from scratch. We are porting an architecture we have already successfully built.

Our team (ILE Labs) maintains the lightning-payjoin-kit—an open-source Rust library that performs this exact collaborative privacy function for the Bitcoin Lightning Network. We intimately understand the complex state-machine logic required to coordinate asynchronous, multi-party channel funding.

Furthermore, because CKB’s Cell Model is a generalized extension of Bitcoin’s UTXO model, the cryptographic and structural assumptions we solved for Bitcoin map perfectly to CKB.

5. Development Roadmap & Milestones

Note: In compliance with the CKB Community Fund DAO Rules for budgets exceeding $10,000, the initial down payment is set to 20%.

Total Budget: $25,000 USD (payable in CKB)

Initial Down Payment (20%) — $5,000

  • Project kickoff, repository setup, and initial architecture mapping of the PSBT-equivalent for CKB Cells.

Milestone 1 — The Core Rust Primitive (Weeks 1-4) — $8,000

  • Port the core Payjoin state-machine logic from lightning-payjoin-kit to support CKB Cell structures.
  • Implement the secure passing of unsigned Cell payloads between sender and receiver.

Milestone 2 — Fiber Network Integration (Weeks 5-8) — $8,000

  • Build the integration layer connecting the Payjoin library directly to the Nervos Fiber Network SDK.
  • Develop the asynchronous communication protocol over the Fiber P2P layer to coordinate the collaborative funding.

Milestone 3 — CLI, Examples, and Audit (Weeks 9-10) — $4,000

  • Deliver a developer CLI (fiber-payjoin-cli) to demonstrate local testing of collaborative channel openings.
  • Publish comprehensive documentation and integration examples for wallet developers.

5. About the Team (ILE Labs)

We are a veteran Web3 infrastructure and Rust development team specializing in cryptography, payment primitives, and low-level execution environments.

Core Team:

Proof of Work:
Our GitHub (ILE Labs) contains deep, production-ready infrastructure spanning multiple ecosystems:

  • lightning-payjoin-kit: The exact architectural predecessor to this proposal, built in Rust for the Lightning Network.
  • foc-devkit & mx-tx-simulator: Complex local testing environments for Filecoin and MultiversX.
We look forward to feedback from the committee and members of the Nervos ecosystem.
14 Likes

Since the lightning-payjoin-kit isn’t finished yet, what happens if you hit a major roadblock on that side? Will a bug or delay with the Lightning build automatically stall the Fiber build too, or can they keep moving independently?

6 Likes

It’s a good part of lightning network, although, I didn’t think it got priority in current time. However, I’d like to support it until below concerns are settled:

This proposal may contain interaction between your team and Fiber developer team, I wander how this SDK built upon? still on Fiber source code or it’s an independent project that can be seamlessly integrated into Fiber source code?

2 Likes

Hi @Werd_Lost,

ILE Labs operates as a collective of engineers. We do not use the same engineers for every project. We have a completely separate, dedicated team of 3 engineers and a Cryptographic researcher who are exclusively assigned to the Nervos fiber-payjoin-kit project and operate entirely independently from our other ecosystem teams

2 Likes

Hi @Ckroamer,

Thank for your feedback,

fiber-payjoin-kit is designed to be an independent helper library that integrates seamlessly with the official Fiber codebase.

Structurally, it will import and build directly on top of Fiber’s native API types and transaction structures. By keeping it as a modular, standalone library (crate), we ensure that:

  1. We don’t introduce unnecessary codebase complexity or technical debt into the core Fiber repository (fnn).
  2. Node operators and wallet developers can easily add it as a optional dependency to enable Payjoin features.

We plan to coordinate closely with the Fiber developer team to align on interface standards and ensure it integrates smoothly into their development workflow.

3 Likes

Hello @ILE_LABS

This is a wonderful development, I would love to support but I have the following Questions:

-What is the name of the Person in your team who posted this article?

-How do I verify that you are the Real ILE LABS?

-Your Work is dependent on the support from FiberDevs, are they aligned with your timelines?

-What are your assurance of the future support to this implementation?

- Is this payjoin active on the Lightining Side?

Thank you

5 Likes

Please get contact of Fiber team in their Github repo beforehand, I believe it’s an essential part of this proposal. If the collaboration didn’t go well with them, it’ll be hard for you to conduct this project.

1 Like

Two clarifications worth getting on the record before this advances.

First, the lightning-payjoin-kit repo currently shows 8 commits, no src/ or Cargo.toml, and a status table with M1 in progress and M2/M3 planned ,so what does “an architecture we have already successfully built” refer to in concrete terms?

Second, how does this differ from payjoin/nolooking, which has done BIP-78 channel-funding payjoin on LN since 2021, and how does it integrate with the privacy work already shipped in Fiber 0.6.0?

1 Like

Hi everyone, thanks for the questions and engagements.

I’m Charles Emmanuel, Project Lead at ILE Labs. You can verify me on LinkedIn (https://www.linkedin.com/in/emmanuel-charles-0b0023250) and GitHub (CodexEmmzy (Charles Emmanuel) · GitHub).

ILE Labs is a small engineering collective focused on infrastructure and protocol tooling, and this proposal is specifically for the CKB Fiber Network rather than Lightning itself.

The current repository reflects our architectural groundwork and ongoing proof-of-concept work for adapting collaborative Payjoin-style channel funding to the CKB Cell model. We are not presenting the implementation as complete today.

We agree that alignment with the Fiber team is important, and we are already reaching out to better understand roadmap compatibility, particularly around the 0.6.0 privacy updates, before finalizing implementation details.

This proposal is not intended to reinvent payjoin/nolooking. Our goal is to adapt the BIP-78 collaborative funding approach to the unique structure of CKB Cells and the Fiber Network.

We also commit to 6 months of post-delivery open-source maintenance, with milestone-based delivery and standard KYC/KYB requirements where applicable.

3 Likes

Hi @ILE_LABS

Firstly, welcome to the forum and to the community. The thought given to this proposal and how it could benefit Fiber Network is commendable! Privacy enhancement for Fiber is a great question to address.

My feeling is that the proposal would have benefitted from a few things

  • A tried-and-tested Lightning Network implementation. This would give the community confidence that the team has experience in delivering a working and polished solution. The repository provided is relatively new and still in development.
  • A smaller grant request and limiting your delivery to an initial proof of concept/MVP. This again would allow you to start with the core primitives and allow the community to become better accustomed to your work. This could then be shared on the forum for feedback and review before moving forward with a larger grant.

Those things said I would love to see more progress made on this topic and look forward to seeing more from your team

5 Likes

Thanks again for the thoughtful feedback and guidance shared so far.

@neon.bit , based on the discussions and recommendations from the community, the team is currently moving toward a smaller proof-of-concept implementation focused around the core Lightning/Fiber primitives first, with the goal of strengthening the broader proposal through practical and publicly reviewable progress.

Our intention is to validate the architecture incrementally, gather technical feedback early, and demonstrate execution before expanding into the larger proposed scope.

We’d also appreciate understanding whether this phased proof-oriented direction aligns with what the committee and Fiber contributors would generally prefer to see moving forward.

4 Likes

Update: Functional Proof of Concept and Technical Specification Completed

Hi Nervos community,

Following the earlier discussion( @neon.bit , @baclaire), we focused on building a smaller, functional proof of concept to validate the core idea first.

We have now completed fiber-payjoin-kit, a working Rust PoC for collaborative channel funding on CKB Fiber, and we also simultaneously(with other team) working on the Bitcoin Lightning equivalent, lightning-payjoin-kit, to validate the same collaborative state-machine pattern across both environments.

We have also prepared a technical specification document, and included a demo showing the standalone middleware performing local negotiation, cryptographic validation, and broadcasting a collaborative transaction to a local CKB devnet node, with also a demonstration video in the document.

The current PoC is deliberately narrow: it runs as local middleware, keeps Fiber node code unchanged, and demonstrates the core collaborative funding flow in a way that is easy to review and extend.

We would love to get feedback from the Fiber team and the community on the architecture and on the best next step for moving this toward a fuller implementation.

2 Likes