Direct Integration with Bitcoin

I propose that tokens in other chains on ic begin with ic, e.g. icbtc, icdogecoin, iceth

Hey Manu, I was looking at the dashboard for Bitcoin stable memory utilization recently and saw this.

It looks to me like the state of the Bitcoin canister has grown from ~39.55GB to 40.2GB in a week, or ~93MB per day.

This would mean the canister is growing at 33.9GB per year.

Is it safe to assume that single canister stable storage limits will be continuously lifted (and can be done so safely) to stay ahead of any needs of the BTC integration?

Is there anything you envision that could speed up this storage required growth rate?


I think it can’t be predicted. It can also shrink. You can also say it grew 40GB/14 years.


They shall begin with ck{token}, ck = chain key, which is not all that bad.

In addition to Timo’s answer, I’ll also add that the Bitcoin canister is currently quite wasteful with its use of memory and there are a number of optimizations that can be done to reduce its memory footprint. These weren’t a priority prior to launch, but can become a priority depending on how the UTXO set grows.


Is ckBTC by end of Q1 realistic?

1 Like

A Zero-Knowledge Roll Up (ZKRU) for transactions is possible on the Bitcoin network.

ZKRU introduces additional code vulnerabilities. However, if done correctly enables a tradeoff of speed and cost for the security of Bitcoin network verified transactions. I am not suggesting that the ckBTC design is bad. In fact, it is cheaper and less likely to introduce code that can be hacked. Furthermore, ckBTC is a prerequisite for what I would envision as a zkBTC on the IC. However, it does not inherit the BTC network security. BTC network security is likely a large draw for BTC holders. In addition to the smart contract example provided it would also require a wallet extension which can capture self-custodied BTC signatures needed in order to transact zkBTC on the IC.

I am a beginner in this space and my next lines of investigation will be:

  • How does the ZKRU post data?
  • Will capturing bitcoin wallet signatures be sufficient?
  • How do we make it compressed (only the minimal amount of transfer required)?

I will attempt building a ZKRU on a BTC testnet and then plan to attempt to build a canister for the processes I am doing off chain. I thought I would share because I am currently in the middle of many projects.


Folks, Proposal: 98062 - IC Dashboard has been executed, which allows us to re-upload the Bitcoin testnet state in a verifiable way. Prior to this proposal, the Bitcoin testnet state was unverifiable. The Bitcoin testnet API will not be available for the next 3-5 hours until the upload is complete.

Update: The new verified state has been uploaded and the Bitcoin testnet API is now available again.


Is there a working group or something like it for Bitcoin integration, ckBTC, Ethereum integration, and generally the third-party-chain integration process more broadly?

Seeking to understand in more detail the timeline and some of the features and security assumptions to make design decisions for a protocol on the IC.

1 Like

I can’t find the Bitcoin canister in the IC Dashboard when I filter by the NNS subnet ID. Anyone know why?

It’s not part of the NNS subnet. See this post, last paragraph: Chain-key Bitcoin (ckBTC): bitcoin wrapped by a smart contract - #9 by Manu


The Bitcoin canisters (not to be confused with the ckBTC canister), are hosted on subnet w4rem.


Hey there! That’s a great question about the integration process for Bitcoin, ckBTC, Ethereum, and third-party-chains. It would be interesting to know if there’s a working group or something similar to help streamline the integration process and ensure security. Understanding the timeline and features would definitely be helpful in making informed design decisions.


Hi @Kaburaha!

First of all, welcome to the Internet Computer Forum!

Regarding your question: We are in the process of shaping a working group. Currently, the discussions are focussed on Ethereum integration and done on the forum: Long Term R&D: Integration with the Ethereum Network - #54 by Roman

If you follow this topic and the one here, you will be getting most of the current discussions related to integrations. Also, you will get the relevant information for the upcoming WG.


Hi everybody!

The bitcoin canister has been running successfully for more than half a year now. During this time, DFINITY has of course kept a close eye on whether everything was working as expected. We set up some tooling that queries the height of the Bitcoin canister, and compares it to what various block explorers have, such that alarm bells would go off if they disagree too much (which was never the case!). This monitoring currently relies on DFINITY’s involvement, and we thought we could improve things further by instead having this monitoring system run as an autonomous “watchdog canister” on the Internet Computer. We now made progress on this idea and would like to propose this more concretely to the community.

The watchdog canister (source on github) regularly queries a list of block explorers via HTTPS outcalls to obtain their view of the latest Bitcoin block height. More precisely:

  1. It queries all block explorers on the list to obtain their view of the latest block height.
  2. Some explorers may temporarily be offline, so it filters out all errors, and only continues with the successful results. If less than three blockchain explorers respond successfully, then the watchdog failed to establish the block height this time, and does not take further action until the next check.
  3. It defines its “target block height” as the median of all heights returned by the block explorers. It uses the median such that one block explorer returning an incorrect height cannot influence the target height.
  4. It compares its target height with the block height that the bitcoin canister currently has. If this differs by more than 2, something must be wrong. This would be a dangerous scenario as canisters that build on the Bitcoin integration (such as ckBTC) may now get inconsistent information from the Bitcoin canister, which can have serious consequences. We propose that the watchdog canister can pull the emergency brake in such a scenario, and temporarily pause the Bitcoin canister from responding to requests: it is better to return an error than to give information that may be incorrect. It would re-enable access whenever the Bitcoin canister and Bitcoin explorers agree again. If the divergence can only be fixed through an upgrade to the Bitcoin canister, then access to the Bitcoin canister would only be restored as soon as the upgrade proposal is accepted and the Bitcoin canister caught up to the latest Bitcoin height.

We view this watchdog canister as an additional safety mechanism, much like airbags in a car: we never expect this mechanism to kick in, and based on the historical data it would have never intervened in the half year since the launch of the Bitcoin canister, but in the unlikely event the Bitcoin canister and block explorers have a different view of the current height, it seems prudent to temporarily pause the Bitcoin canister access.

Unless there are concerns, DFINITY plans to submit proposals in the coming weeks to

  • Install the watchdog canister under NNS control
  • Update the Bitcoin canisters (mainnet and testnet) to allow the watchdog canister to pause and unpause its operations

Please let us know what you think! We’d be happy to hear your feedback and to answer any clarifying questions here.


HI.Excuse me,Is there any progress on the above proposal? What is its specific priority?
Thank you very much!

These proposals are now open for voting:


There are plans to start a working group on this topic soon, so hopefully you can follow the progress there soon.


Hey everyone! DFINITY this week has submitted two seemingly identical proposals to upgrade the “Watchdog Testnet Canister”:

  1. Proposal 127120
  2. Proposal 127121

In case you’re unfamiliar, the “Watchdog Testnet Canister” is a monitoring canister that queries external block explorers and compares their tip with the Bitcoin testnet tip that’s available on the IC. Whenever it detects a divergence, it disables the Bitcoin testnet API out of precaution. You can read more about the watchdog canister in Manu’s post above.

As mentioned in the proposal summaries, we’re upgrading the canister to make it more robust and less noisy. We’ve unfortunately made a mistake when submitting proposal 127120 - we didn’t include the canister’s initialization arguments in the proposal. We’ve corrected that in proposal 127121. Thus, DFINITY plans to reject proposal 127120 and adopt proposal 127121.

If you have any questions please don’t need hesitate to ask.


Folks, we were in the process of upgrading the Bitcoin testnet canister this week. You may have noticed that DFINITY rejected proposal 127667, as it was unintentionally proposing to reinstall the Bitcoin testnet canister, rather than upgrade it.

This proposal has been resubmitted, with the correct upgrade mode, in proposal 127681.

We’re discussing now as well how we can make the upgrade mode more visible in proposals to avoid these issues from reoccurring in the future.