ckBTC: the gap
Bitcoin is the most secure cryptographic asset, and DFINITY’s Internet Computer has tapped this potential through its Bitcoin API infrastructure, allowing IC users to access and control funds on the Bitcoin blockchain. But moving value between BTC and ckBTC requires users to wait for confirmation on the Bitcoin blockchain, making fast trading and payments infeasible.
ckLightning closes that gap.
We bridge the gap between the security of the Bitcoin network and the utility of the Internet Computer by interfacing with the Lightning protocol directly from a canister on the IC. The protocol moves value between BTC on the Lightning Network and ckBTC on the Internet Computer through liquidity pools (not via mint/burn), so swaps complete in seconds. Liquidity providers deposit ckBTC (via ICRC-1) or BTC (to canister-managed addresses) into the pools and earn fees proportionally to pool depth on every Lightning-to-IC swap.
Today we are sharing that ckLightning has reached its staging milestone: We have deployed and tested end-to-end atomic Lightning ↔ ckTESTBTC swaps, which are running live on IC mainnet against ckTESTBTC and Bitcoin testnet4.
Advantage ckLightning
Our project has several advantages compared to implementations that move funds cross-chain.
No custodial trust required.
Problem: Most BTC bridges hold user funds in a centralized vault. A breach of the operator results in fund losses for users.
Solution: ckLightning’s relay is a Lightning Node that does not hold any channel secrets. All cryptographic operations that give the Lightning protocol its security are implemented on the IC canister via threshold ECDSA and Chain-Key cryptography. The relay is a routing facilitator on behalf of the autonomous canister.
Atomic settlement.
Problem: cross-chain swaps usually involve intermediate states where one side has paid and the other has not, requiring trusting nodes or escrow services.
Solution: Lightning HTLCs cryptographically tie the BTC payment to the ckBTC ledger movement.
Native IC settlement.
Problem: swaps that pass through wrapped tokens or external sequencers add latency and counterparty risk.
Solution: After a Lightning swap settles, the user holds ckBTC directly on the ICRC-1 ledger, which is immediately usable on the IC.
The ckLightning componentst
The system consists of three components, which are all written in Rust:
-
The canister (
5iwit-tiaaa-aaaau-aelaa-cai) holds the ckTESTBTC and testnet4 BTC liquidity pools, manages ckTESTBTC reserves on the ICRC-1 ledger, signs Lightning channel commitments using threshold ECDSA, and verifies Bitcoin funding TXs through the IC Bitcoin API. -
The relay acts as the link between the canister and Bitcoin-native Lightning nodes. It has the full communication capabilities of a Lightning node, but delegates all signing to the canister.
-
The client is a CLI for users to request swaps, manage LP shares, and check the status of the canister.
The canister implements BOLT-2 / BOLT-3 channel state machines and uses ICRC-2 approvals for ckBTC token transfers. ICP is used for an anti-DDoS fee (refunded on successful swaps). Channel keys are derived per-channel inside the canister, so the relay operator cannot unilaterally close a channel or move user funds.
Status
The infrastructure is live on IC mainnet (with ckTESTBTC) and Bitcoin testnet4. The full canister functionality has been validated repeatedly on the staging deployment. Integration of ckBTC with Bitcoin mainnet is the next deployment phase.
Resources
-
Canister on IC dashboard: Canister: 5iwit-tiaaa-aaaau-aelaa-cai - ICP Dashboard
-
ckTESTBTC ledger: Canister: ckTESTBTC Ledger - ICP Dashboard
-
GitHub:
-
Canister: https://github.com/perun-network/ckLightning-canister/tree/staging-april-deployment
-
Client: https://github.com/perun-network/ck-lightning-client/tree/staging-april-deployment
-
LDK Lightning Node (ldk-sample fork): https://github.com/iljabvh/ldk-sample/tree/ckLightning
-
Demo video: https://youtu.be/pJsEWC4RRiA
The Path to Lightning-DeFi
After the integration of Bitcoin of mainnet and the ckBTC asset, our goal is to establish ckLightning as a core infrastructure to facilitate IC’s broader DeFi economy using Lightning Hubs, but also IC-native building blocks.
-
More liquidity pools. Adding pools for additional IC-native assets: ICP, stablecoins, ICRC assets, so Lightning users can swap directly into anything on the IC.
-
Lightning routing. Letting users pay any Lightning node from their IC balance, turning ckLightning into a Lightning payment provider for IC-native dApps.
-
Cross-protocol liquidity. Bringing ckLightning’s pools to other IC DeFi protocols (DEXes, lending, yield) so the underlying BTC liquidity is composable across the ecosystem.
Overall, we want to make the IC’s full asset universe reachable from Lightning wallets, and Lightning’s payment network reachable from any IC-native dApp.
Acknowledgements
Thanks to the DFINITY Foundation for supporting the work, to the LDK team for the excellent Rust Lightning library that the relay is built on, and to the IC developers and reviewers who have given feedback along the way and helped us with technical questions. We look forward to community input as ckLightning continues to grow.