Direct Integration with Bitcoin

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.