Bitcoin Layers Review of ckBTC

Came across a thread on X by Bitcoin Layers that has a security review of ckBTC. Here is the thread.

Link to the full write up. Hopefully Dfinity can provide some thoughts.


I am old enough to remember the promise that Bitcoin integration to IC would be a game changer for IC. As of today, after 1 year and half, there are 281 bitcoins on IC and we are learning today they may not be as safe as we were told they would be.
Is that the level of success Dfinity and DW were looking for?
I am not giving up on IC but it does not look that good anymore.
I expect the FUD screamers team to jump in but it will not change the reality of where IC stand now and that the future still only stand on promises and vision, not on real things.


I think they did a good job reviewing ckBTC. It may be surprising to see them say “high risk” for certain areas, but I think it’s important to look at the methodology of bitcoin layers. They have clear rules defined on what they consider high risk. I personally think those rules are a bit too strict, because for example every single bitcoin layer they reviewed (other than lightning) has received a “high risk” rating in the custody category. However I do think they review the different layers fairly and hold each to the same standard.

Comparing with how they rated other projects, ICP/ckBTC received the same rating as Stacks, and most projects they reviewed were considered higher risk by them than ICP and stacks.


Manu how feasible is it for 10/28 node operators to collude? My understanding was that even if they wanted to, it would be next to impossible due to node shuffling.

We think it’s very unlikely. Note that we dont automatically shuffle nodes between subnets, but the key is regularly reshared among the participants. So these 10 node providers would need to actively collude (while being identified and having signed a statement of good intent etc) or some hacker would need to manage to break into 10 of 28 node machines at the same time.


Sorry I meant key resharing not node shuffling. Thanks for clarifying.

Are there future features that might make it impossible even for collusion to take place. Perhaps VetKeys?

I made few comments on x and I’ll repeat them here:

  1. Was any thought given to making the output script on the ckBTC utxo have a secondary emergency lifeline key like maybe a governance subnet Dapp that could via governance be used in an emergency to unlock the UTXOs if the pxxxx subnet was compromised or blown away?(This may increase risk in other areas like making an NNS governance takeover more likely).

  2. When the value on one of these subnets gets super high, is there any plans or thoughts for a slashing scheme to keep nodes honest? At some $ value($1B? $10B? $100B?) can we expect a 28 node subnet with no slashing to stay secure without them having to put up some kind of additional collateral at risk? And how do we compensate them for that collateral?


At the growth pace that IC is adding bitcoins since 18 months, my calculation is that it will take 92.6 years before reaching $ 1B. Useless to talk about 10 and 100B.

This is the reality now and nothing indicate that this growth will change anytime soon.

So I wouldn’t care much about that for now if i were Dfinity.


No one is here for the current reality.


What I find interesting is that most of these L2s don’t use anywhere near as secure a protocol as threshold ECDSA. It’s really like comparing a space ship to a lifeboat.


Sooner or later, the reality will catch up. Until then, have fun and good luck!

Hi everyone, this is Janusz from the Bitcoin Layers team.

Firstly, I want to thank @Manu for acknowledging our intention to do these reviews fairly. We have a bias, but we review everything directly against our framework. If we make changes to this framework, we acknowledge it publicly.

We developed this framework in the open, and held numerous open discussions to gather community feedback prior to publishing it. Our bias is that Bitcoin L2s directly inherit security from Bitcoin, ensure anyone can contribute to the integrity of a two-way peg, and/or ensure that users have the option to retain sovereignty over their assets.

There’s additional risks and nuances that are not directly covered in our assessments. As mentioned in the methodology page, this is a living document. We have been actively discussing ways to improve it, especially as we review more diverse protocol designs.

If you have feedback, the best way to provide it is via submitting an issue in our GitHub. We’ll address honest feedback. Our website is also free and open-source. Anyone is welcome to contribute to reviews.