[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.
16 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

3 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

6 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.

5 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.

5 Likes

Lightning-payjoin-kit PoC Complete — Update for the Fiber Community

Hi everyone,

Following the feedback from neon.bit and the community in May, we committed to delivering a tried-and-tested Lightning implementation before pushing the Fiber proposal forward. That implementation is now complete.

lightning-payjoin-kit current state:

The PoC now includes a real two-node LDK harness (tests/ldk_two_node_harness.rs) where two actual LDK ChannelManagers complete the full channel-open lifecycle through a collaboratively-funded transaction — FundingGenerationReady → collaborative PSBT construction → LdkManualFunding → FundingTxBroadcastSafe → usable channel. The transaction is also accepted and mined by a real Bitcoin Core regtest node via Docker.

Implementation notes are here: github.com/ILE-Labs/lightning-payjoin-kit/blob/main/IMPLEMENTATION_NOTES.md

On Nervosanno’s question from May 21 — how this differs from payjoin/nolooking:

payjoin/nolooking is a server-side LSP model requiring a centralized node operator. lightning-payjoin-kit is a client-side library using LDK’s manual funding API directly, with an explicit commitment-safety boundary (enforcing FundingTxBroadcastSafe before broadcast) that the LSP model does not address at the protocol layer. The CKB port differs further because there is no PSBT standard on CKB — coordination uses unsigned CellInputs, and Cell-Deps validation requires different logic than Bitcoin’s UTXO model.

On Fiber team alignment:

We opened a GitHub discussion on the Fiber repository asking about roadmap compatibility with collaborative channel funding. We have not received a response yet. If any Fiber contributors reading this can point us to the right contact or confirm whether this direction fits the current roadmap, that would help us move this forward.

fiber-payjoin-kit PoC remains complete and the architecture document is at the same link shared in June.

What is the right next step — is this sufficient to move to the voting stage, or does the committee need additional technical review first?

1 Like

Hi ILE_Labs, 首先感谢您们持续的建设,其次由于 [DIS] fiber-payjoin-kit: Collaborative Privacy for the Nervos Fiber Network 这次提案并没有在7天内得到30赞,没有通过讨论阶段

因此,如果您们在吸收各方反馈后,认为已经在原提案的基础上做出实质性改进,欢迎重新提交新的提案,并接收社区的审议

1 Like

Thank you for the clarification, this is very helpful. We will prepare a revised proposal incorporating the community feedback and the completed Lightning PoC as the foundation. We will reach out to community members who engaged with the original before resubmitting to ensure we have incorporated all concerns. Is there a recommended timing or format for resubmission?

1 Like

目前DAO规则对修订后的再次提交没有明确规定

另外,虽然我作为协调员,对于修订提交的提案会在同步信息时对比原始提案和新提案,但我建议提案人可以主动在新提案中包含对比的部分,方便社区更好的进行审议

1 Like

Personally, I think we’re navigating some rough waters right now. Do you want to run some benchmarks on the post-quantum implementation? Are SPHINCS+ transactions that are not covered by this privacy-enhancing solution also processed in a block at the same time? So that there is little additional computational overhead?

Quantum-resistant signatures are significantly larger than classical ones, which directly impacts transaction size and fees.

  • ML-DSA (Dilithium): ~2.5 KB (~40x larger)
  • SPHINCS+: 8 KB – 49 KB (~125x - 760x larger)

Grouping inputs that share the same Lock Scripts, allowing multiple inputs to be verified with a single signature stored in the transaction’s Witnesses.

Edit:

  • PayJoin requires both sender and receiver wallets to support the protocol.
  • PayJoin is used during an actual payment.
  • PayJoin involves only two parties (sender and receiver) and makes a payment transaction look normal while breaking the assumption that all inputs belong to the sender.
  • read spark.money bitcoin-privacy-tools-comparison

@vriveraPeersyst

Hi everyone, following all the feedback from this thread and the CKBuilder review, we have submitted a revised proposal with a reduced scope and budget.

The Lightning equivalent (lightning-payjoin-kit) is now complete with a working two-node LDK harness. The new proposal is scoped to Phase 1 only, with two concrete end-to-end demos against a real Fiber node addressing the fee-contribution and funding privacy pain points highlighted.

New proposal here: link

Any support would go a lot during the 7-day vote window.