FiberDevs

We shipped Fiber Dashboard. Why? Because we kept getting asked: "Is Fiber dead?"/"Anything actually happening?"/"Hello??" ...fair questions, honestly. Fiber is running, but to most people, it's just invisible. Data is scattered across on-chain txs and individual nodes, with no unified view. Getting a clear picture of the real state has always been a challenge. We believe a truly usable L2 shouldn't just live in code, logs, or RPC interfaces. It should be seen, understood, and trusted. So here is the dashboard, a real-time view of the network: node distribution, channel activity, overall health, etc. Now check out what's happening on Fiber: dashboard.fiber.channel and the notes from one of the builders: talk.nervos.org/t/fiber-networ… @NervosNetwork

🚴Fiber Dev Log 25 🚴 Security & reliability level-up - We added expiry safeguards to stop funds from getting stuck if a node goes quiet. - Cross-Chain Hub (CCH) can now run as its own service, meaning better scalability for those high-traffic routing nodes. Architecture upgrades - We've unified the storage layer with native SQLite support, keeping things light and efficient. - RPC layer got refactored and now uses Public Keys instead of peer IDs Better efficiency - Several heavy background processes were replaced with more efficient task spawning Now prepping RC for acceptance testing → v0.8.0 coming soon! Features include onion routing and inbound flood protection. github.com/nervosnetwork/… @NervosNetwork

While the team is heads-down on the protocol, the community is where the magic really happens. 🪄 We're kicking off Pulse—a new bi-weekly check-in to track community contributions, milestone deliveries, and everything cool being built on Fiber. Check out Pulse 01: docs.fiber.world/blog/pulse/iss…

An installer that matches #fiber networks energy. Launching a fiber node on #nervosnetwork just got abstracted into 2.5 minutes including an internal interactive dash with OTA updating. Tested on windows 10 and Ubuntu 24 on aarch64 (orange pi zero 3). Mac script untested. $CKB

🚴Fiber Dev Log 24 🚴 A major focus recently has been on channel reliability. We've hardened our TLC settlement handling to prevent duplicate states and dangling TLC in invoice flow. Also persisted the TLC commitment replay state so channel recovery after restarts is deterministic, preserving strict replay ordering. On the architecture side, we're splitting core types into standalone crates like fiber-types and fiber-json-types. This means: - Developers can reuse Fiber's protocol, channel, payment, and invoice data structures without embedding a full node - Easier SDK and tooling integration for external Rust projects Also working on external wallet signing, where users can keep keys securely in their own wallets while still using Fiber channel workflows. Check out the full breakdown in the DevLog: github.com/nervosnetwork/… @NervosNetwork

Just dropped two demos showing how Fiber eliminates trust dependencies by routing payments directly between nodes. 🚀 A fully decentralized architecture where the backend never touches user funds: 🎮 fiber-game: P2P wagering where an Oracle + adaptor signatures act as the ultimate ref. The winner claims the pot directly. Zero intermediary custody. 🤝 fiber-escrow: Escrow without escrow agent. Payments are held by the network via Hold Invoices, released on delivery, and arbitrated if things get weird. You can launch both demos locally with a single command! github.com/quake/fiber-de… @NervosNetwork

Fiber v0.7.1 just dropped. We've introduced observable channel opening and improved network safety with configurable CORS and smarter balance checks to catch payment issues before they start. 🚀 v0.7.1 Release note: github.com/nervosnetwork/… It's the follow-up to the major work of the previous version 0.7.0. This release brings significant structural changes, including trampoline routing and improved data privacy for debug outputs. We managed to boost payment performance by about 60% this time—mostly by being more efficient with how we handle secp256k1 contexts and pathfinding. Beyond routing, we've also overhauled the Cross-Chain Hub (CCH) with a proper finite-state machine to make order handling much more resilient. It feels good to see these architectural pieces finally click into place! You can check out the full breakdown in the DevLog: github.com/nervosnetwork/… @NervosNetwork

🚴Fiber Dev Log 22 🚴 We're getting v0.7.0 ready, with one-way channels and trampoline routing. Here's a quick look at what's new in Fiber over the past two weeks: Trampoline routing payments are now merged and coming in the next release. Instead of calculating the entire payment route upfront, senders only need to reach a trampoline node. From there, the rest of the route is carried hop-by-hop inside an inner onion. The receiver only sees their own payment — nothing about the path it took. The result is simpler routing, better privacy, and fewer failure points as the network scales. Path finding got faster. We discovered that path finding was slowed down by repeated pubkey comparisons. Each comparison triggered expensive serialization work, and since routing checks many channels, this overhead added up quickly. By switching to map-based lookups and storing already-serialized pubkeys, we replaces the sequential iteration with map indexing. The result: 10x faster with map indexing, plus 2x faster with serialized pubkey storage. For a deeper dive into all the changes and fixes, take a look at the full dev log: github.com/nervosnetwork/… @NervosNetwork

🚴 Fiber Dev Log 21 🚴 Just dropped the latest dev log: github.com/nervosnetwork/… In this sprint, we shipped v0.6.1 and finished the draft implementation of two new features: one-way channels and trampoline routing — both are now under testing. Most of the other work went into corner cases, concurrency fixes, Cross-Chain Hub order persistence, and some dashboard improvements as well. Also linking the 2025 review & 2026 outlook here, in case you missed the Nervos Talk post 👇 talk.nervos.org/t/fiber-protoc… @NervosNetwork

🚴 Fiber Dev Log 20 🚴 We've been working on making payments, cross-chain swaps, and the dashboard more reliable and maintainable: Payment Actor Decoupling We identified a performance bottleneck in the path routing algorithm that could block the Network Actor. To address this, we moved the send payment logic into a dedicated Payment Actor. This decoupling ensures that routing and payment execution no longer delay core network message processing. Additionally, we improved the performance of the MPP routing algorithm. Cross-Chain Hub (CCH) CCH has been refactored around a clear FSM-based architecture, making order handling and state transitions deterministic and easier to reason about. Backend-specific effects (Fiber/LND payments, invoice tracking, settlement) are now properly encapsulated and driven by persisted actions instead of ad-hoc handlers. We also strengthened input validation for cross-chain swaps, adding checks for expiry timing, hash consistency, and invoice compatibility to prevent unsafe or failing swaps early. This improves correctness, reliability, and debuggability across the CCH flow. Other improvements Dashboard backend updated for new frontend structure, more logging added for debugging, and routing logic is being fine-tuned for flexibility and scalability. Full dev log & PRs here 👇 github.com/nervosnetwork/…

Just got back from CKCon in beautiful Chiang Mai🌴! Our dev gave a talk on Fiber and hacked an interactive visual simulation to show how it works. If you couldn't make it, below is a shorter version. But first, try playing with the dots yourself! 👉 fiber-world.vercel.app/simulate.html Why Layer 1 Isn't Enough We all love Layer 1 blockchains like Bitcoin or CKB for their security, but let's be honest: they aren't exactly built for speed. Every transaction has to be shouted out to the entire world and written down by thousands of nodes. On CKB, you're waiting about 8 seconds for a block; on Bitcoin, it's 10 minutes! Plus, the fees can get nasty if you're just trying to buy a coffee. ☕️ So how to fix this? Lightning Network 101 The Lightning Network is a scalable, low-fee, and instant micro-payment solution for P2P payments. The secret sauce isn't actually new. Even Satoshi Nakamoto hinted at this "high-frequency" magic in an early email: "Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network." (@mail.gmail.com/" target="_blank" rel="nofollow noopener">gnusha.org/pi/bitcoindev/…) A Lightning Network consists of Peers and Channels. A peer can send, receive, or forward a payment. A Channel is used for communication between two peers. Imagine you and a friend want to trade money back and forth quickly: 1. Opening the Channel: You both put some money into a pot and sign a Funding Tx. This goes on the blockchain (L1). 2. The Fun Part (Off-Chain): Now that the channel is open, you can send money back and forth a million times instantly! You just update the balance sheet between you two (using HTLCs and signatures). No one else needs to know, and no blockchain fees are paid yet. 3. Closing the Channel: When you're done, you agree on the final balance, sign a Shutdown Tx, and tell the blockchain. Everything in the middle? That's off-chain magic. ✨ The Power of the Network Now, if Fiber was just about paying your direct neighbor, it would be boring. The real power comes from the Network. This means Alice can pay Bob even if there's no direct channel between them. The payment can travel through one or more intermediate nodes. As long as there is a path with enough liquidity, the payment will reach its destination instantly. All data is wrapped in Onion Packets (yes, like layers of an onion). The nodes in the middle serve as couriers, but they are blindfolded: - They don't know who sent the money. - They don't know who is receiving it. - They only know "pass this to the next guy." They simply follow a basic rule: they forward the Hash Time Lock, and if the payment succeeds, they earn a tiny fee for their trouble. Easy peasy. The Not-So-Easy Part 😅 While the idea is simple, building it is... well, an engineering adventure. We're dealing with cryptography, heavy concurrency, routing algorithms, and a whole jungle of edge cases. But hey, that's what makes it fun! We've poured the last two years into building Fiber, and I'm proud to say it’s finally GA-ready. If you want to geek out on the details, check these out: - Mastering the Lightning Network (github.com/lnbook/lnbook) and Basis of Lightning Technology (github.com/lightning/bolts) - Fiber's GitHub: github.com/nervosnetwork/… Here is the full presentation from the Chiang Mai talk CKB Fiber Network Engineering Updates: docs.google.com/presentation/d… @NervosNetwork @Cryptape

Wonderful to be back in Chiang Mai — great energy at this year's CKCon! 😎🥥 Our Fiber dev presented the latest engineering updates, and it's always a joy to reconnect with other Nervos teams and share what we've been building. ⚡🤝 Thanks @RunningCKB @matt_bitcoin @c_hongzhou for hosting this amazing ecosystem event!

🚴 Fiber Dev Log 19 🚴 Quick rundown of what we've been building this sprint: Cross-Chain Hub (CCH) can now to process multi-hop payments directly. We've unified order management: SendBTC and ReceiveBTC orders are now a single CCH Order, simplifying BTC-CKB swaps. We've also added settle_invoice RPC and error handling to manually settle hold invoices when needed. On the reliability side, we improved monitoring and observability: added monitoring and observability to the large-scale test environment, fixed migration checks to behave consistently across OSes, exposed pending_tlcs in the list_channels RPC to better track in-flight payments, and enabled three Rust actor metrics to monitor concurrent task performance. Full details here: github.com/nervosnetwork/… @CKBDevrel @CKBdev @NervosNetwork

If the text style looks off for you on X, please check here: yakihonne.com/article/naddr1…

🧪 Curious how Fiber handles liquidity? Here's a complete survey of all the solutions we've reviewed and what we plan to implement. Surveyed Solutions 01 Shaduf++ Paper: Shaduf++: Non-Cycle and Privacy-Preserving Payment Channel Rebalancing (eprint.iacr.org/2022/388) The intermediate user can shift funds between adjacent channels. Say there're two channels. Channel Beta is between Alice and Bob with the distribution: (Alice: 10, Bob: 20). Another Channel Gamma is between Bob and Carol with the distribution: (Bob: 1, Carol: 19). Bob can shift 10 from (Alice, Bob) to (Bob, Carol) and the distributions become: - (Alice: 10, Bob: 10) - (Bob: 11, Carol: 19) Limitations: - Users can only shift funds between channels after recording the binding via an on-chain transaction. - Channels binding will specify the max allowed shifted-out amount in both channels. - For each channel, the sum of all max allowed shifted-out amount in all recorded bindings should be no greater than the channel capability. All the information is available on-chain so anyone can verify this. This is also the reason that shift requires an on-chain transaction to record the binding. How to use: - It can be used as a fallback that when a forwarding node has no enough balance in the outbound channel. If it has enough fund in the inbound channel, it can try to shift funds between channels. - A node can scan its channels and schedule shifts in advance to improve the funds distributions in these channels. 02 Split Paper: Study and Implementation of Split Multi-Channel Rebalancing Strategy for Off-Chain Payments (ijns.jalaxy.com.tw/contents/ijns-…) This paper has brief introduction to Revive and Shaduf as well. B→C→D→B are performing Revive, C→E→F are performing Shaduf Split is a rebalancing planning algorithm. It monitors the traffic in the network and generates a rebalancing plan to shift funds between channels. In simple words, it automate the execution of Shaduf. The planning algorithm is based on another paper: P. Li, T. Miyazaki, and W. Zhou, Secure balance planning of off-blockchain payment channel networks (dl.acm.org/doi/10.1109/IN…). The core contribution is PnP, a balance planning service that determines how much funding should be initially deposited into payment channels given estimated payment demands among network nodes. 03 Horcrux Paper: Horcrux: Synthesize, Split, Shift and Stay Alive Preventing Channel Depletion via Universal and Enhanced Multi-hop Payments (eprint.iacr.org/2024/1338) This protocol is like an automatic Shaduf++ on payments. It establishes a Virtual Channel along the payment path to implement funds shifting. Other virtual channel designs: 1. Stefan Dziembowski, Lisa Eckey, Sebastian Faust, Julia Hesse, and Kristina Hosátková, Multi-party virtual state channels (eprint.iacr.org/2019/571) 2. Stefan Dziembowski, Sebastian Faust, and Kristina Hosátková, General state channel networks (eprint.iacr.org/2018/320) 3. Aggelos Kiayias and Orfeas Stefanos Thyfronitis Litos, Elmo: Recursive virtual payment channels for bitcoin (eprint.iacr.org/2021/747) 4. Lukas Aumayr, Pedro Moreno-Sanchez, Aniket Kate, and Matteo Maffei, Breaking and fixing virtual channels: Domino attack and donner (eprint.iacr.org/2021/855) 04 Musketeer Paper: Avarikioti, Z., Schmid, S., & Tiwari, S. (2023). Musketeer: Incentive-Compatible Rebalancing for Payment Channel Networks (eprint.iacr.org/2023/938) All users submit their liquidity and bid. - Liquidity: How much sellers are willing to allocate for routing/rebalancing. - Bid: How much buyers are willing to pay for rebalancing the channel. The protocol generates rebalancing plan based on the global liquidity and bid submissions. 05 Starship Paper: Xu, M., Yu, W., Shang, G., Qi, G., Duan, D., Wang, S., Li, K., Zhang, Y., & Cheng, X. (2025), Starfish: Rebalancing Multi-Party Off-Chain Payment Channels (doi.org/10.48550/arXiv…) Shaduf requires N on-chain transactions to submit bindings. Starship batches these transactions in a star topology, where a central hub connects to N peers. However, the batch requires synchronous consensus from all N+1 parties. The paper uses atomic broadcast, but other BFT consensus algorithms also work. 06 Cycle Paper: Hong, Z., Guo, S., Zhang, R., Li, P., Zhan, Y., & Chen, W. (2022). Cycle: Sustainable Off-Chain Payment Channel Network with Asynchronous Rebalancing. (doi.org/10.1109/DSN534…) Rebalancing for a cycle topology. All parties in the cycle maintain a global offset Delta via a consensus algorithm using off-chain messages. In all the channels in the cycle, it is assumed that amount of Delta balance has been transferred from the sender to the receiver. For example, for the cycle consisting of 3 channels: - Alice to Bob: Alice 0, Bob 200 - Bob to Charlie: Bob 0, Charlie 200 - Charlie to Alice: Charlie 0, Alice 200 After applying the global offset Delta = -100, the balance becomes: - Alice to Bob: Alice 100, Bob 100 - Bob to Charlie: Bob 100, Charlie 100 - Charlie to Alice: Charlie 100, Alice 100 Instead of sending real payments to rebalance the channel, Cycle turns the problem into how parties reach consensus on the global offset Delta. 07 Lightning Pool Paper: Osuntokun, O., Fromknecht, C., Paulino, W., Gugger, O., & Halseth, J. (n.d.). Lightning Pool: A Non-Custodial Channel Lease Marketplace. (github.com/lightninglabs/…) Lightning Pool solves liquidity problem using an auction on inbound channel bandwidth. Sellers promise to create channels with the required duration, and buyers pay the lease fee to these inbound channels. To support the channel lease market place, fiber must support following features: - Single funded channels. The inbound channel is fully funded by the seller. - A mechanism to ensure sellers pay the lease fee. Sellers can pay the fee off-chain or promise to pay when they receive funds from the lease channels. - A mechanism to ensure a channel is open for the required duration. See also: - 闪电网络：技术与用户体验（五）：流动性获取(btcstudy.org/2024/03/01/lig…) - Liquidity Advertisement by Blockstream (blog.blockstream.com/setting-up-liq…) - Amboss Space Magma (amboss.space/magma) 08 Submarine Swap Atomic swap between L1 (CKB) and L2 (Fiber). If Alice wants inbound channel, she can pays the service provider Bob on Fiber (so Bob will have balance to forward payments to Alice), and Bob will pay back the received funds to Alice on CKB. See also: - Loop | Builder's Guide: docs.lightning.engineering/lightning-netw… - 闪电网络：技术与用户体验（五）：流动性获取(btcstudy.org/2024/03/01/lig…) 09 Zero-Conf Channels When users trust the service provider, users can send funds to the service provider on chain and the service provider will open channels to users and transfer the funds after deducting the fee immediately. Users can confirm the channel immediately after receiving the fund tx without waiting for confirmations on-chain. 10 JIT (Just-In-Time) Channels When the service provider forwards HTLC to a user and the user has not enough inbound bandwidth, the service provider will open a new channel to provide inbound bandwidth for the user. The service provider can ask users to pay the fee via other channels using the same payment hash. 11 Liquidity Ads Liquidity Ads (dl.acm.org/doi/10.1109/IN…) create a decentralized marketplace where nodes advertise their willingness to sell liquidity at specific rates. Buyers can discover these offers through the Lightning gossip protocol and request liquidity when opening dual-funded channels or performing splices. This eliminates the need for centralized liquidity marketplaces and provides market-driven pricing for channel capacity. The specification introduces a `payment_type` field enabling multiple fee payment methods. Some examples: - `FROM_CHANNEL_BALANCE`: Fees deducted immediately from the buyer's channel balance during the funding negotiation. - `FROM_HTLC`: Fees deducted from future HTLCs routed through the channel, enabling zero-balance onboarding - `FROM_FUTURE_HTLC`: Deferred fee payment from subsequent payment flow - `EXTERNAL_PAYMENT`: Out-of-band payment mechanisms Planned Solutions ☑️ Submarine Swaps Submarine swaps enable atomic exchanges between on-chain CKB and off-chain Fiber channels, providing a trustless mechanism for users to manage liquidity without custodial risk. Why Most Suitable for Fiber: - Leverages existing HTLC infrastructure already implemented in Fiber - Provides immediate liquidity access without protocol changes - Non-custodial and trustless, aligning with decentralization principles - Solves the critical inbound capacity problem for new users Implementation Plan: - Develop submarine swap service provider infrastructure. The commitment lock script may just work for the on-chain part of the swap. - Create both normal swaps (on-chain to Lightning) and reverse swaps (Lightning to on-chain) - Establish competitive fee structures (base fee + percentage) ☑️ Liquidity Ads Why: Easy to implement ☑️ JIT (Just-In-Time) Channels JIT channels allow users to receive Lightning payments immediately without pre-established channels, with the sender opening channels on-the-fly when first payment arrives or receivers have no enough inbound capacity. Why Most Suitable for Fiber: - Dramatically lowers user onboarding friction - Reduces upfront capital requirements for end users - Proven successful in Lightning Network ecosystem Implementation Plan: - Research LSPS2/bLIP-52 - Report on how to build LSP infrastructure with automated channel management - Implement fee deduction mechanism from first received payment - Implement single-funded channel support if not already available - Implement zero-conf channel support if not already available - Create standardized API for wallet integrations ☑️ Liquidity Pool Marketplace A channel lease marketplace where liquidity sellers auction inbound bandwidth to buyers needing receiving capacity. Why Most Suitable for Fiber: - Creates sustainable economic incentives for liquidity providers - Addresses the "inbound liquidity" problem systematically - Enables price discovery for liquidity services Implementation Plan: - Implement single-funded channel support if not already available - Implement zero-conf channel support if not already available - Design and implement smart contracts to support lease channels - Design marketplace API for buyers and sellers - Design auction mechanism for channel leases (duration-based pricing) Solutions to Watch These solutions are inefficient and costly to maintain; we can monitor them for future developments. - Shaduf++ - Cycle - Split