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

General
156

Hi everybody! I want to share some plans for an upgrade to the ckBTC minter that DFINITY plans to propose in the coming months.

Problem

Currently, to redeem ckBTC for BTC, you

  1. do a transaction to send your ckBTC to a user-specific subaccount of the ckBTC minter, and then
  2. call “retrieve_btc” on the ckBTC minter, upon which it burns the ckBTC from the subaccount it has for the user and sends out the BTC.

This is suboptimal because it could happen that step 1 succeeds, but step 2 does not (eg, you close your browser tab killing the dapp, or the KYT checks fail, …). Now your funds are already moved, and all front ends need to have some support to resubmit step 2 in order to successfully withdraw BTC. This has already led to confusion.

Proposal

Now that ICRC-2 is a standard, DFINITY plans to propose to upgrade the ckBTC minter to use that for the withdrawal flow. So if you have ckBTC and you want to get BTC, the steps would change to

  1. do an icrc2_approve for the amount you want to withdraw, approving the ckBTC minter to transfer ckBTC out of your account
  2. call “retrieve_btc”, upon which the ckBTC minter burns bitcoin directly from the user’s account (which it can do with the approval from step 1).

This has the advantage that if for some reason a user does step 1 but not step 2, no funds are moved.

We propose to roll this out in two stages:

  1. upgrade the ckBTC minter to support both the existing (subaccount-based) withdrawal flow, as well as the ICRC-2 based withdrawal flow. This gives everybody that built front-ends to support this conversion time to switch to the ICRC-2 based flow, which should be easy (roughly, do an approve for x ckBTC instead of doing an ICRC-1 transfer of x ckBTC).
  2. after some time, we would submit a second proposal that disables the subaccount-based withdrawal flow, so using ICRC-2 would then be the only way to go ckBTC → BTC. We propose to do this because we think there are no downsides to the ICRC-2 flow, it’s easy for everybody to use, and by disabling the subaccount-based flow we keep the code as small simple as possible, which is always good for security.

One concern with disabling the old flow, some users / dapps may still send funds to the subaccount of the minter in an attempt to withdraw ckBTC, which then is no longer supported. To avoid funds getting stuck, we propose adding some functionality that funds from the ckBTC minter’s subaccount specific to principal p can always be returned to principal p.

Please let us know what you think!

Edit to clarify: This is really a heads up to developers of dapps that support ckBTC → BTC. Users and holders of ckBTC can safely ignore this and keep their ckBTC in whichever wallet they prefer, no action required.

3 Likes