ckBTC: a canister-issued bitcoin twin token on the IC, 1:1-backed by BTC

I’m not 100% sure i understand your question correctly. What I meant earlier is that you can follow my earlier post (which links to the README) to send testnet bitcoin to the ckTESTBTC minter, and the ckTESTBTC minter will in return mint new ckTESTBTC for you. Does that answer your question, or are you looking for something else?


Yea, call it BTC, because that is what it is. When you are on Binance you see BTC when it is BTC, and not binBTC.


I kind of agree with this. When looking at other blockchains (especially their explorers), wrapped Bitcoin is only labelled as Bitcoin (BTC), not Example Bitcoin (eBTC) or anything like that.

It would indeed be extremely nice if we just called it Bitcoin (BTC) and nothing more, but perhaps people could get confused? Then again, people don’t seem to be confused on other chains.

The reason calling ckBTC just BTC would be misleading is that ckBTC is an ICRC token, native to the IC, that does not exist in the bitcoin network.

There are many distinctions that can be made but the most basic one is the one between native vs (synthetic) representation.

BTC is a token native to the bitcoin network, ETH and ERC20s are tokens native to the Ethereum network, ICP and ICRCs are tokens native to the Internet Computer network.

BTC is native bitcoin that exists only on the bitcoin network. The IC can hold and move these without having to itself exist on the bitcoin network, just like you and I can without us having to exist on the bitcoin network. One can recognise this asset, BTC, in part in the fact it can only do ~7 transactions per second, has 10 minute confirmation times, shows its transactions in bitcoin block explorers, can be held and handled by bitcoin wallets, etc.

All other representations of BTC, including wBTC (ERC20), renBTC (ERC20), BTC.b (Avalanche ERC20 or OFT), ckBTC (ICRC), and so on, are representations of BTC that are not native to the bitcoin network.

The IC can hold and handle BTC, and it can hold and handle ckBTC. One exists on the bitcoin network, the other exists on the IC network.

The process of achieving that tokenisation or representation can and does vary greatly, but that’s another matter. In particular, ckBTC is an important innovation, the closest existing parallel probably being renBTC, but none is literally and exactly BTC.

To the extent that the rest of the crypto ecosystem pays attention to ckBTC, officially calling it simply BTC runs the risk of inciting ridicule, accusations of unwarranted grandiosity, and even raise questions, in the eyes of the broader crypto community, especially on a first-sight basis, about the technical literacy or degree of familiarity the team may have regarding the existing context in which it has created this important innovation.

It would also make it very difficult to distinguish in language between when an IC dapp is dealing with or referring to BTC vs when it’s dealing with ckBTC, both of which can be handled by IC canisters, leading by necessity to informal and possibly a proliferation of fragmented renaming to account for the practical and really ontological differences between those assets.


I agree, yet I see the following risk that we must not underestimate : by deciding to call it only « BTC », newcomers on IC or crypto beginners all having heard about a direct integration could try to send BTC directly from a Bitcoin address to their CkBTC address.

So if we call it only BTC, we will have to multiply the warnings and disclaimers behind any CkBTC address : « Don’t send Bitcoin BTC to this address ».

This UX aspect will have to be addressed systematically, in a way or another.

In your example, no need to distinguish the ICP held with a Ledger Nano and those held with II (calling the first one nICP and the second one iiICP) because both are on the IC, whereas BTC and CkBTC won’t be. So the distinction, not justified in the first case, can be justified in the second.

is there a wasm and did file available for download for local deployment, just like for the ledger?

IC will have ckBTC and wrapped BTC . ckBTC won’t be icrc, it will be real Bitcoin on the Bitcoin chain.


This is precisely the sort of reason why we need two names for two assets.

To be clear, @singularity, the IC can handle (transfer, hold, etc) “real” BTC, but ckBTC is not that. They are two separate things.


I think I can accept real BTC and ckBTC as our two ways of referring to it. We’re going to have do do some real work in terms of user education to make the terms clear, though


As we’re getting closer to launching ckBTC, it makes sense to provide more detail about cycle management.
Since the ckBTC ledger and minter are hosted on an application subnet, the canisters consume cycles. Naturally, we want both canisters to be self-sustainable; however, we don’t want to charge cycles for the endpoints to make ckBTC as easy to use as possible.

Our approach is the following: There is a 0.0000001 ckBTC (10 “ckSatoshi”) fee for ckBTC transfers. As there are more and more ckBTC transfers over time, the ckBTC minter will hold an increasingly large surplus of BTC.
Additionally, there is a small BTC fee when retrieving BTC (and burning the same amount of ckBTC) to cover the relatively high cost of getting the required signatures and sending the signed transaction to the Bitcoin network. The fee depends on the number of inputs and outputs of the transaction (you can check the source code here).
This additional fee is typically small compared to the Bitcoin miner fee, which is deducted from the requested amount as well.

The ckBTC canisters are initially loaded with a large number of cycles, which should sustain their operations for quite some time. The long-term plan is to use the accumulated surplus to top up the canisters, (automatically) selling BTC on DEXs to obtain the required cycles.


Thanks the the updates guys. Will ckBTC be available in the NNS dApp when it rolls out or ever?

Something vaguely related: We have often been calling ckBTC an “advanced form of wrapped Bitcoin” or the like. But talking to various people, it seems that using the term “wrapping” may be misleading and people coming from traditional blockchains may immediately think that this involves an intermediary like a bridge to perform the wrapping without even reading any further. When reading through the definitions of the first few hits for a Web search on “wrapped tokens”, it becomes clear that they all explicitly refer to an intermediary, i.e., bridge, when defining what wrapping is.

Thus, we think that it is better to avoid using the term “wrapping” in the future altogether in the context of ckBTC. It is better to explain it as an analogue of Bitcoin on the Internet Computer blockchain, based on the native Bitcoin integration and particularly chain-key ECDSA signing, which gives the token its name. This should help avoid any ambiguities and particularly misleading people coming from more traditional blockchains.


Hi everyone. I have some questions that I hope you can help me address. I’ll be very grateful if you can use simple terms that even a layman can at least partially understand.

  1. What are the key differences between ckBTC and Bitcoin Integration? And why do we need both of them?
  2. What are the key differences/pros between ckBTC and wrapped BTC (on Ethereum network for example)?
  3. For BTC integration, the assumption is that when a transaction is done/finalized (with BTC “integrated”) in the Internet Computer network, that transaction is also done/finalized in Bitcoin network. Is that assumption correct? And if the answer is YES, how does it really work when we all know that the Bitcoin network is much less efficient (esp. in terms of transaction speed and finality) than the Internet Computer network?
    Look forward to your feedback. Many thanks.
1 Like

How will upgrades be performed? What proposal topics or NNS functions will be used?

I’m trying to ascertain how decentralized the upgrades to ckBTC will be. If proposal topics or functions are used which DFINITY has a lot of voting power behind, then we can consider DFINITY as a sole operator practically speaking. I think we should avoid that.


Wrapped BTC means that one single person (or a group of people) have direct access to the BTC wallet that the wrapped Bitcoin refers to. E.g. I create a smart contract that manages a wrapped Bitcoin token; you transfer your Bitcoin to my wallet; and I give you wrapped Bitcoin in exchange; later on, you hope that if you give me wrapped Bitcoin I will transfer you actual Bitcoin out of my wallet.

With ckBTC, it is an IC canister that holds the underlying Bitcoin and issues the ckBTC. If said canister is blackholed (i.e. is no longer controlled by anyone and can no longer be upgraded); or owned by a DAO; then no single person or group has direct access to the wallet. The only middleman as it were is this canister. And the IC. So it’s smart contracts all the way down. (o:

It is not accurate, no. When ckBTC exchanges hands, only the ckBTC ledger (maintained on the IC) is updated. I.e. there’s a canister on the IC that pools all the underlying Bitcoin; and maintains a ledger of who owns how much ckBTC (or equivalently, how much of the underlying Bitcoin). This works exactly the same way as wrapped Bitcoin on other networks. It’s only when you want to convert your ckBTC into actual BTC that a transaction on the Bitcoin network must happen (a transfer from the canister’s Bitcoin wallet to yours).


Bitcoin Integration makes it possible for canisters to control and transact with Bitcoin. ckBTC builds on top of that and exposes an ICRC-1-compliant interface to transact with Bitcoin on the IC. Without Bitcoin Integration ckBTC would not be possible without bridges. Without ckBTC the Bitcoin transactions on the IC would be as expensive and slow as normal Bitcoin transactions (read: impossible to provide a solid user experience).


It will be in topic System Canister Management, so the same as NNS canisters and the Bitcoin canister are upgraded.

Thanks @free and @Severin for the response.

For Q(1), does it mean that there are actually 2 ways to transact BTC on the Internet Computer network: directly via Bitcoin Integration and indirectly via ckBTC (a “wrapped” version of BTC)?

For Q(2), does it mean that the ckBTC Canister will eventually be controlled by a DAO (as I don’t think it makes sense if it is “blackholed”?
—> If the answer is YES, what makes this ckBTC Canister “more secured” than a conventional bridge (that can issue wrapped BTC) controlled by a DAO?

Look forward to your reply. Many thanks.

The fact that no human has direct access to the Bitcoin wallet. Regardless of whether the bridge is controlled by one person or by a DAO, the private key to the Bitcoin account is held in some device (whether a computer, Ledger device, etc.) somewhere. Whoever has or gains access to said device/wallet, has access to all the BTC within it.

With bitcoin held by an IC canister, the secret key to the Bitcoin wallet is not held by any one IC replica / server. Every transaction is threshold signed by a two thirds majority of a 28-replica subnet. Intuitively, each of said replicas provides a piece of the signature and you need 19 pieces to put together a valid, signed transaction.

1 Like

Yes, and it is possible for other canisters to offer the same functionality as ckBTC.

Yes, AFAIK it will be controlled by the NNS, which is a DAO itself.

1 Like