Direct Integration with Bitcoin

I see. So you want a lightning channel to be established between a user and a canister on the IC. Or, alternatively, between one of the big lightning nodes that offer routing and a canister and then the user can indirectly route Btc to the canister.

First of all I would love to see this implemented just because it is cool. But we also have to think if it really gives you the benefits that you think it does. The user already has to have the Btc locked in the lightning channel in advance before the need for a real-time trade occurs. Then the user might just as well lock the Btc in the canister-DEX directly. With centralized exchanges you want to take funds off the exchange as quick as possible to reduce risk but with a DEX in a canister the situation is different. So the need for a lightning channel may be reduced.

With lightning in general the problem is always the other direction, taking funds out, because the exchange cannot keep channels with all its users that are all funded on the exchange side.

Technically I think there are still some open question if this can really be done in both direction. There is some problem with the way that HTLCs work. The IC can do threshold signing but cannot create hashed secrets in a distributed way that are later to be revealed. This has to be investigated in detail. Maybe there are future lightning version that use a different hash function who’s computation can be distributed. Or there might be some hybrid solution that runs almost but not entirely on the IC. That’s TBD.


I was thinking between one of the big nodes and then a canister.

I’m not sure how much BTC liquidity is in lightning, but if it grows to be a significant portion of BTC, it would be good to be connected to it.

And yes, I think you are right in some sense the IC is and can become a replacement for lightning - isn’t that exciting!

DEXs may not need to be lightning fast, but if we could improve the speed of getting into the IC from BTC, it would help drive adoption IMHO.

The hashed-secret thing does seem to be a challenge, unfortunately. Feels doable with secure enclaves rather than MPC??

Our engineering efforts are now fully focussed on the end-of-January release of the Developer Preview. We are on track to realistically ship this preview of the feature by the end of the month. This will allow users to implement canisters against the API that will be (very close to) final.
The following points regarding the API are currently discussed:

  • Should we provide a separate convenience API for getting the balance for a BTC address? This would mean that users will not need to go through the library, but can directly call this method and receive the balance.
  • Should we implement pagination already now for the get_UTXOs method? This will not be important for the large majority of use cases, but addresses with huge amounts of UTXOs might lead to the get_UTXOs response hitting the technical limits of multiple MBs. Any opinions on the relevance of this? Requirement or rather a theoretical issue? Are there any Bitcoin addresses where the corresponding UTXO set would be so huge that it would hit a multi-MB limit?

Should we implement pagination already now for the get_UTXOs method?

My very limited personal experience tells me that pagination is important and should be implemented earlier rather than later, since it could affect the choice of data structures as well as other implementation details.


Thank you for sharing your thoughts on this - much appreciated! This gives us a first hint at how to resolve this question. :slight_smile:

Is Dom talking about 2-second finality on ETH Tx w/ the integration? did I misunderstand him? the Tx throughput is still subject to the ETH’s native limitations, isn’t it? Would this be the same for BTC; still subject to native limitations?

First of all, @memetics, welcome to the Developer Forum!

Let me clarify the aspect of transaction finality: Every transaction for Bitcoin or Ethereum that happens on the Bitcoin or Ethereum networks has the finality and cost of those networks, of course. No one can change that with any form of integration. But, you can transfer BTC or ETH over to the IC once with the native integration, then wrap it on the IC, and use the wrapped BTC or ETH token on the IC with the 2-second transaction finality.
Thus, most BTC and ETH transactions could happen on such wrapped tokens with low finality time and low transaction cost. Only the initial transfer of BTC and ETH into the IC and a settlement transfer back out need to happen on the BTC and ETH blockchains with their respective finality and cost.
Does this answer your question?


Yes, cheers! Looking forward to seeing the ic blossom!

1 Like

wrapped tokens with low finality time and low transaction cost.

The way I understand it these wrapped tokens should still be be safer than the alternatives on other chains, cause nobody knows the private keys, so they’d work more like renBTC rather than WBTC, If thats the case the only risks of using the wrapped version rather than the native one are potential vulnerabilities in the canisters that handle the tokens or the remote possibility the NNS decides to shut down the canister. Is that correct?

1 Like

I like to look more on YouTube for reviews on this topic. Can someone tell me when ICP will integrate with Bitcoin?

That’s my understanding. This is in stark contrast to WBTC on Ethereum, where the private keys needed to mint new tokens are held by a centralized custodian, i.e. BitGo.

The types of interesting, intra-chain DeFi applications that were made possible by Ethereum will now be possible cross-chain. Pretty exciting stuff.


Should we implement pagination already now for the get_UTXOs method?

Pagination is definitely needed. Even if not, for now, but for sure in the future.

1 Like

what is the difference between this bitcoin direct integration and wrap bitcoin on ethereum?

The direct integration does not require any intermediaries, such as trusted bridges, which would lock up the received Bitcoin and mint the wrapped tokens. In the direct integration, smart contracts directly can hold Bitcoin as they can have their own threshold ECDSA private key that is secret shared among the replicas of a large subnet. So, the direct integration features a much stronger trust model than a bridge-based solution.

A developer preview that allows people to use the API will be available already by around end of January. The release of the feature on IC mainnet is planned to happen by the end of Q1.


What’s the difference between the Bitcoin smart contracts IC can achieve with the direct integration and the Bitcoin smart contracts Stacks STX provides?

IMHO …When I took a look at Stacks, it appeared to be similiar to about 90% of the crypto space. A bunch of vaporware mumbo jumbo. Perhaps though your research will offset the following criticism…

No scientific paper describing consensus protocol.
No soundness or liveness proof.
All I found was a rather light explanation of the PoX consensus. (Proof of Transfer) . What is the connection to miners? Who knows! Block producers bid for the right to create blocks by transferring bitcoins to another group called stackers. The motivation is STX but it gets convoluted when you dig further. I do like the ‘Hard Fork to Proof of Burn’ scenario. Sounds like film noir.

The Stacks 2.0 native currency is not Bitcoin. There is not even a wrapped-BTC token as far I can tell.

There is a STX token and the developers want folks to lock it for a long period… obviously.

They do use ‘Bitcoin technology’ to secure consensus so they have a Bitcoin blockchain oracle I think.

But I give a thumbs down to their ‘built on Bitcoin’ shtick …


Thanks for your thoughts. This is apparently Stacks’ Bitcoin DeFi platform

Maybe more technical details will be released after the coin goes up another billion.

1 Like

Progress update:
We have made lots of progress towards the Developer Preview release of the Bitcoin integration feature. This release will come out next week and allow people to use the Bitcoin API already now.

Let me briefly summarize below what you get with this preview release:


  • Bringing the (close to final) APIs to our community; this should allow folks who want to use the API to already do so now in their development environment
  • Main goals
    • Bring the API to the people so they can play around already now, thereby bridging the gap between the original release date end of 2021 to the new release date end of Q1 2022
    • Facilitate smart contract development by community members already now
    • Get community feedback for the API for the final release
    • The Bitcoin-related logic is almost completely available
    • Almost zero engineering waste created by the DP release
  • This release does not use the final architecture for the integration, but does it in the following simplified way (this does not matter for the local environment and the intended goals):
    • APIs will be exposed as a regular canister (BTC Canister) running locally, not as a system API, for now
    • bitcoind in regtest mode is used instead of the Bitcoin mainnet or testnet (this makes sense for the lowest-level dev/testing stage anyway)
    • The IC stack integration is shortcut via ingress messages and queries, the full IC stack integration with consensus is being finalized in parallel and will be released in the Q1 release
    • Users start the Bitcoin adapter, integration shim, bitcoind, and BTC canister with a script
    • There’s no threshold ECDSA yet in this release
  • We will provide small sample dApps in both Rust and Motoko that make use of the interface

The following is not in scope and will not be available in this release. Non-scope:

  • Threshold ECDSA (in this release, people need to use an ECDSA library in the canister for now to sign transactions)
  • Bitcoin testnet and Bitcoin mainnet integration
  • Library to abstract the interface and make it more convenient for the users
  • Full IC stack integration through Consensus