Current Status
Fiber has moved well beyond the purely design or single-channel validation stage.
On the protocol side:
- The full channel lifecycle is defined: open, update, close, and dispute
- Multi-hop payments across channels are supported at the protocol level
- State commitment, forwarding rules, and failure handling are specified with real network behavior in mind
On the engineering side:
- A working Rust-based core implementation is in place
- Channel state machines and routing-related logic are implemented
- The corresponding on-chain contracts and scripts have been implemented to support channel settlement, state verification, and dispute handling
We have been running extensive multi-node, multi-hop network tests over the past year.
They were focused on realistic network scenarios, and they exposed real issues, including:
- Fund safety edge cases
- Performance bottlenecks under load
- Node stability and recovery issues
A significant portion of recent work has been dedicated to fixing these issues and hardening the system.
As a result, Fiber today is not just protocol-complete, but increasingly network-tested.
Positioning Fiber via Lightning Network History
To help set expectations, itâs useful to compare Fiber with the historical development of the Lightning Network.
Lightning went through several phases: starting from a proposal, then making single channels usable, followed by multi-hop routing and real network engineering challenges, and only later reaching broader wallet adoption and ecosystem maturity.
If we map Fiber onto that phases, Fiber today is closer to Lightningâs early network phase.
This means Fiber is no longer just validating basic channel correctness â we are actively validating network behavior under realistic conditions.
At the same time, we are still being careful not to prematurely lock in higher-level assumptions. The key lesson from Lightning remains valid: many long-term constraints come from decisions made too early.
Our goal is to advance network capability while keeping the protocol flexible enough to evolve.
Key Challenges
There are two main challenges we are managing carefully:
-
Protocol complexity â features like routing, multi-asset support, or watchtowers introduce significant complexity and need to be approached only after the core is stable.
-
Designing for a more expressive base layer â unlike Bitcoin, CKB is Turing-complete, which gives us much more room to experiment. At the same time, this means we should be careful not to automatically copy assumptions from Bitcoin or Lightning. When designing the protocol and writing the implementation, we want to keep things flexible and avoid locking ourselves into patterns that might be unnecessarily restrictive.
Plan for This Year
This year, our work focuses on three main areas:
-
Wallet integration
We are actively pushing integration with JoyID. The goal is to make Fiber usable from a real wallet context, not just as a standalone protocol. This helps validate our API design, UX assumptions, and end-to-end flow under realistic user scenarios. -
Business-facing enablement
In parallel, we will improve documentation and build demos that clearly demonstrate Fiberâs advantages in appropriate scenarios â such as high-frequency payments, low-latency interactions, and off-chain coordination that would be inefficient on-chain.
These demos are not meant to be marketing material, but concrete references that help wallets, developers, and potential partners understand when and why Fiber should be used. -
Liquidity
Liquidity is a core challenge for both Lightning and Fiber. We will study and reuse proven liquidity solutions from the Lightning Network where they make sense, such as channel management, rebalancing techniques, and liquidity pools. At the same time, we want to explore liquidity designs that are specific to Fiber, rather than simply copying Lightning solutions, and see what works better in this environment.
