Fiber’s Cross-Chain Hub (CCH) is one of the coolest parts of the current Fiber stack: it allows a Fiber payment on CKB to automatically trigger and settle a payment on a completely different network, like Bitcoin’s Lightning Network.
To show how this works in practice, we built a testnet demo. A user pays using a CKB testnet xUDT called cWBTC (representing wrapped Bitcoin), and a backend Fiber CCH node automatically settles a standard Bitcoin testnet Lightning invoice via LND.
You can try it out or check the code here:
- Live Demo: https://fiber-swap.retric.uk
- GitHub Repository: https://github.com/humble-little-bear/fiber-swap-demo
(Note: This is a testnet-only developer demo).
What the Demo Shows
The user experience is straightforward. You generate a Lightning invoice, pay with cWBTC in your browser, and the backend CCH node handles the real Bitcoin settlement.
Here is the step-by-step flow:
- Get an Invoice: Generate or paste a Bitcoin testnet Lightning invoice.
- Create a CCH Order: The app requests the backend Fiber node to create a CCH order for that specific invoice.
- Pay on Frontend: The browser’s built-in Fiber node pays the returned Fiber invoice using testnet
cWBTC. - Backend Settlement: Once the CCH node accepts the Fiber payment, it immediately instructs its LND node to pay the original Bitcoin Lightning invoice.
- Success: The receiver’s LND node gets the BTC testnet sats, and the order status marks as successful.
This is not a UI simulation. In our end-to-end testing, a real Fiber UDT payment is delivered to the CCH actor, and a completely separate LND node receives an actual Bitcoin testnet Lightning payment.
Architecture
Here is a clean text-based diagram of the architecture and node relationships:
[User] ──> [React App] ──> [@fiber-pay/react Browser Node]
│ │
│ (API Requests) ▼ (Fiber Routed Payment)
▼ [Bottle Public Fiber Node]
[Express Backend] │
│ │ ▼
▼ └─────────────────> [FNN CCH Node]
[Receiver LND] │ (LND RPC)
▲ ▼
└──────────────────────────────── [Payer LND]
(Lightning BTC Payment)
We deliberately deployed two separate LND nodes:
- Payer LND: Owned by the Fiber CCH actor, used exclusively to pay outgoing Lightning invoices.
- Receiver LND: Owned by the demo environment, used to generate test invoices and receive the final BTC.
Separating these nodes keeps the demo honest. If the same LND node created and paid the invoice, it would just be an internal loop. Using two nodes proves that cWBTC goes in through Fiber, and BTC moves out across the wider Lightning Network.
Also, there is another detail worth to be noticed that the lightweight browser Fiber node cannot connect directly to our backend FNN node. Instead, it routes payments through bottle, a public Fiber node acting as a trampoline hop. Thanks to the Public node, we can serve more users because now users only need to open cWBTC channel with the bottle instead of our little backend home node.
The Value Flow
Here is how the data and value flow through the system:
[User] [React App] [Browser Node] [Express API] [FNN CCH] [Payer LND] [Receiver LND]
│ │ │ │ │ │ │
│── Paste Invoice ─>│ │ │ │ │ │
│ │── Create Order ──────────────────>│ │ │ │
│ │ │── send_btc ──>│ │ │
│ │ │<─ Fiber Inv ──│ │ │
│ │<─────────── Return Order & Inv ───│ │ │ │
│ │── Trigger Pay ─>│ │ │ │ │
│ │ │── (via Bottle) │ │ │ │
│ │ │ Route cWBTC ─────────────────>│ │ │
│ │ │ │ │── Pay Inv ──>│ │
│ │ │ │ │ │──────────────>│
│ │── Poll Status ───────────────────>│ │ │ (Settle BTC)
│ │ │─ get_order ──>│ │ │
│ │<─────────── Return Success ───────│ │ │ │
cWBTC moves from the user’s browser node, through the Bottle node, into the backend FNN CCH actor. In tandem, the backend’s Payer LND settles the invoice by sending BTC testnet sats to the Receiver LND.
Why cWBTC?
Fiber CCH needs an asset on the Fiber side to mirror the value being paid out on Lightning. For this demo, we issued a CKB testnet xUDT named cWBTC (with 8 decimals) and configured FNN to recognize it as the wrapped BTC asset for CCH routing.
The testnet Type Script for cWBTC is:
{
"code_hash": "0x25c29dc317811a6f6f3985a7a9ebc4838bd388d19d0feeecf0bcd60f6c0975bb",
"hash_type": "type",
"args": "0x9a1086531ed6dc69e0bd44cef5278e03faf3015b31aff60b08fb87663ce8507100000000"
}
While the demo is a simple proof of concept, the implications are significant. Fiber handles the high-speed, low-cost routing of native CKB assets, while CCH acts as the bridge to external settlement networks.
This layout lets developers build applications where CKB assets interact frictionlessly with the global Bitcoin Lightning ecosystem, giving users a smooth experience that feels like a single unified payment flow rather than two separate manual wallet steps.