Chain-key Bitcoin

Overview

Chain-key Bitcoin (ckBTC) is a token on the Internet Computer that is backed 1:1 by bitcoin (BTC) such that 1 ckBTC can always be redeemed for 1 BTC and vice versa.

Unlike other tokens pegged to bitcoin, the ckBTC token does not rely on a third-party bridge for the conversion between BTC and ckBTC, making it a substantially more secure alternative to “wrapped” tokens.

While chain-key bitcoin and regular bitcoin have the same value, the advantage of chain-key bitcoin is fast and cheap transfers: A transfer is finalized within a few seconds (a speed-up of roughly three orders of magnitude compared to transfers on the Bitcoin blockchain) and only costs 0.0000001 ckBTC (approximately two orders of magnitude lower than the Bitcoin miner fees).

Architecture

The ckBTC functionality is built upon the Bitcoin integration of the Internet Computer, which makes it possible for canisters to receive, hold, and send bitcoin.

There are two canisters, the ckBTC minter and ckBTC ledger, that together provide the ckBTC functionality. The ckBTC minter mints new ckBTC tokens whenever it receives bitcoin. Likewise, it burns ckBTC tokens whenever an owner of ckBTC tokens requests a withdrawal of bitcoin. The ckBTC ledger is ICRC-1 compliant, updating the balance accounts when ckBTC tokens are transferred and executing the mint and burn operations coming from the ckBTC minter. An overview of the basic architecture is depicted in the following figure.

High-level overview of chain-key Bitcoin.

The figure shows the main flow at a high level of abstraction: Users interact with the ckBTC minter and the ckBTC ledger to convert ckBTC/BTC and transfer ckBTC, respectively. The ckBTC minter interacts with the Bitcoin canister to retrieve information about the Bitcoin network state and send Bitcoin transactions.

The ckBTC minter further interacts with the KYT canister for "know-your-transaction" (KYT) checks. These checks are meant to ensure that the ckBTC minter only uses "clean" bitcoins to back the issued ckBTC tokens and to prevent sending out bitcoins that are considered to be associated with illicit activity. As such, these KYT checks provide an additional layer of security to ckBTC users.

Technical Details

ckBTC Ledger

The ckBTC ledger is a canister, controlled by the NNS (specifically, the NNS root canister), running on the pzp6e subnet. Since it is ICRC-1 compliant, it offers all functions defined in the ICRC-1 standard. In particular, it provides the functionality to transfer ckBTC between accounts. As mentioned above, the transfer fee is 0.0000001 ckBTC.

The minting account is the ckBTC minter’s default account, that is, the account derived from the ckBTC minter’s principal ID and the all-zero subaccount.

The initial supply of the ckBTC ledger is 0. ckBTC tokens are minted only when the ckBTC minter receives bitcoin, ensuring that the ckBTC supply managed by the ckBTC ledger is upper bounded by the amount of bitcoin held by the ckBTC minter.

ckBTC Minter

The ckBTC minter is a canister that is controlled by the NNS and running on the pzp6e subnet as well. It has a few important configuration parameters including:

• retrieve_btc_min_amount: This is the minimum ckBTC amount that can be burned and, correspondingly, the minimum BTC amount that can be withdrawn. The parameter is set to 0.001 BTC, or 100,000 satoshi.
• max_time_in_queue_nanos: Any BTC retrieval request should be kept in a queue for at most this time. Caching requests rather than handling them right away has the advantage that multiple requests can be served in a single transaction, saving Bitcoin miner fees. The parameter is set to 10 minutes, which corresponds to the expected time between Bitcoin blocks.
• min_confirmations: The number of confirmations required for the ckBTC minter to accept a Bitcoin transaction. In particular, the ckBTC minter does not mint ckBTC before a transaction transferring BTC to a Bitcoin address managed by the ckBTC minter reaches this number of transactions. The parameter was initially set to 72 but has been reduced to 12 in the meantime.
• kyt_fee: The fee that must be paid for KYT checks. It is currently set to 2000 satoshi.

The other parameters are self-explanatory and can be found in the ckBTC minter Candid file.

The ckBTC minter provides the following endpoints:

• get_btc_address: Returns a specific Bitcoin address that the caller can use to obtain ckBTC by sending BTC to this address.
• track_balance: Instructs the ckBTC minter to track a certain Bitcoin address until funds are added, which will trigger the minting of ckBTC. NOTE: This endpoint is work-in-progress and not available yet.
• update_balance: Instructs the ckBTC minter to check the balance of a Bitcoin address and mint ckBTC into the account of the owner.
• estimate_withdrawal_fee: Returns a current estimate for the fee to be paid when retrieving a certain BTC amount.
• get_deposit_fee: Returns the fee charged when minting ckBTC.
• get_withdrawal_account: Returns a specific ckBTC account where the owner must transfer ckBTC before being able to retrieve BTC.
• retrieve_btc: Instructs the ckBTC minter to burn a certain ckBTC amount and send the corresponding BTC amount, minus fees, to a provided Bitcoin address.
• retrieve_btc_status: Returns the status of a previous retrieve_btc call.
• get_minter_info: Returns information about the ckBTC minter itself.
• get_events: Returns a set of events at the ckBTC minter.

The endpoints are discussed in more detail in the following.

get_btc_address(owner: opt principal, subaccount: opt blob)

The provided principal ID and subaccount are concatenated to form the derivation path for the ecdsa_public_key function, which returns the derived public key. If no principal ID is provided, then the sender’s principal ID is used. If no subaccount is provided, then the default subaccount (all zeros) is used.

This public key is encoded as a pay-to-witness-public-key-hash (P2WPKH) Bitcoin address and returned as a text.

Note that the key derivation is not BIP-32 compliant where 31 bits are used for each derivation level. Instead, a single derivation is performed based on the full principal ID and subaccount. Since the derivation is deterministic, a canister can derive the Bitcoin address for a given principal ID and subaccount itself.

track_balance(owner: opt principal, subaccount: opt blob)

NOTE: This endpoint is work-in-progress and not available yet.

The ckBTC minter starts tracking the Bitcoin address derived from the provided principal ID and subaccount using the get_btc_address endpoint. If no principal ID is provided, then the sender’s principal ID is used. If no subaccount is provided, then the default subaccount (all zeros) is used.

The balance of the Bitcoin address is not tracked indefinitely. Tracking is stopped if either at least one new unspent transaction output (UTXO) is discovered or there is no new UTXO within a certain time interval (details about balance tracking are provided below).

If at least one new UTXO is discovered, the same amount of ckBTC tokens minus the KYT fee are minted and made available to the owner.

update_balance(owner: opt principal, subaccount: opt blob)

Instead of having the ckBTC minter track the balance of a Bitcoin address, the update_balance function can be invoked to instruct the ckBTC minter to check if there are new UTXOs for a particular Bitcoin address.

If there is at least one new UTXO, the corresponding ckBTC amount is minted, otherwise an error is returned.

The ckBTC minter effectively invokes this endpoint itself on a timer when the track_balance function is used.

estimate_withdrawal_fee(amount: opt nat64)

The endpoint returns an estimate for the fee that must be paid when retrieving the given BTC amount. Internally, a transaction is built (without valid signatures) to determine the fee, which consists of the Bitcoin miner fee, the ckBTC minter fee, and the KYT fee. If no amount is provided, it is assumed that three inputs are required to build the transaction.

If there is no change to the internal state of the ckBTC minter and the Bitcoin canister before issuing the request to retrieve bitcoins, the fee will be exactly the returned estimate.

The fee can change when a) a new Bitcoin block is mined in the meantime, which causes the Bitcoin canister to update the Bitcoin miner fees or b) another retrieval request is handled first, spending some of the outputs that were used when estimating the fee.

get_deposit_fee

The endpoint returns the fee that the ckBTC minter charges for minting ckBTC when receiving new UTXOs. Currently, this fee is simply the KYT fee.

get_withdrawal_account

The function returns the caller’s withdrawal account, which is the account derived from the ckBTC minter’s principal ID and the subaccount derived from the caller’s principal ID.

A user can only retrieve BTC by first transferring ckBTC to this particular account.

retrieve_btc(address: text, amount: nat64)

The function instructs the ckBTC minter to burn the specified amount. Once the request is picked up from the queue, a Bitcoin transaction is created containing an output that transfers the requested amount (minus fees as discussed below) to the specified Bitcoin address.

Since Bitcoin retrieval is handled asynchronously, the function returns the block index of the transaction burning the ckBTC tokens.

retrieve_btc_status(block_index: nat64)

The status of a BTC retrieval request can be checked using this function. The different possible statuses are:

• Unknown: There is no information available on the ckBTC minter because there is no retrieval request associated with the given block index or the retrieval request is old and the corresponding information has already been removed.
• Pending: The BTC retrieval request is queued.
• Signing: The BTC retrieval request is acquiring all signatures to serve the BTC retrieval request.
• Sending: The Bitcoin transaction serving the BTC retrieval request is being sent.
• Submitted: The Bitcoin transaction has been transmitted. The transaction ID is returned.
• AmountTooLow: The BTC retrieval request could not be served because the Bitcoin miner fees are prohibitively high.
• Confirmed: The Bitcoin transaction serving the BTC retrieval request is confirmed inside the ckBTC minter, which happens when the transaction has at least the minimum required number of confirmations specified in the min_confirmations parameter above.

get_minter_info

The function returns the following parameters internal to the ckBTC minter:

• kyt_fee
• min_confirmations
• retrieve_btc_min_amount

get_events(start: nat64, length: nat64)

The ckBTC minter tracks the events that change its internal state. Given a start index and a length parameter, the ckBTC minter returns all events sequentially from the event at the given start index up to the event at index start+length-1.

Note that this endpoint is used for debugging purposes and there is no guarantee that the endpoint will continue to exist in this form.

Converting BTC to ckBTC

In this section, the process to convert BTC to ckBTC is explained, making use of the ckBTC minter and ckBTC ledger endpoints.

The first step is for the user to determine the Bitcoin address where the user is supposed to transfer bitcoin for the minting process by calling the get_btc_address endpoint. Next, the user transfers the desired BTC amount to this Bitcoin address. Subsequently, the user calls the track_balance endpoint to inform the ckBTC minter that it is about to receive bitcoins at the given address.

Internally, the tracking works as follows. Since the expected time between Bitcoin blocks is 10 minutes, the ckBTC minter first checks if new unspent transaction outputs (UTXOs) are available for that address with at least the required number of confirmations after 10*min_confirmations minutes. If there is at least one new UTXO, tracking stops and the ckBTC minter instructs the ckBTC ledger to mint the same amount of ckBTC tokens into the account derived from the principal ID and the subaccount.

If no new UTXOs are discovered with sufficiently many confirmations, the ckBTC ledger checks if there are new UTXOs with at least one confirmation. If this is not the case, tracking stops as well. Otherwise, the expected time until the first new UTXO reaches the desired number of confirmations is computed, which is 10 minutes times the difference between the desired number of confirmations and the current number of confirmations. The same process then repeats until ckBTC tokens are minted or tracking stops.

It is evident from this description that it’s possible that tracking may stop before ckBTC tokens are minted, for example, if it takes an unusually long time until the transaction appears in a block. In this case, the endpoint can be invoked again. Alternatively, the user can wait until the transaction has the required number of confirmations and call the update_balance endpoint.

The following figure depicts the conversion flow using the track_balance endpoint.

Process of converting BTC to ckBTC.

In this figure, the ckBTC minter discovers the new UTXO after the waiting period by calling get_utxos on the Bitcoin canister. As mentioned above, it is possible that it may take several interactions with the Bitcoin canister until the transaction has received sufficiently many confirmations before the ckBTC minter issues the mint transaction to the ckBTC ledger. After a successful KYT check, the ckBTC ledger is instructed to mint ckBTC tokens for the user. The minted amount corresponds to the value of the UTXO minus the KYT fee.

Converting ckBTC to BTC

The first step to convert ckBTC to BTC is to transfer the amount to be retrieved to the owner-specific withdrawal account under the ckBTC minter’s control. This step is required because only the ckBTC minter can burn tokens and it can only burn those tokens in one of its accounts. The withdrawal account can be obtained by calling the get_withdrawal_account endpoint.

After the user has transferred the desired ckBTC amount to the withdrawal account, the user can call the retrieve_btc function to inform the ckBTC minter about the withdrawal intent. In addition to specifying the withdrawal amount, the Bitcoin address where the withdrawn funds are to be sent must be specified as well.

The ckBTC minter puts the retrieval request into a queue and checks the status of the queue on a heartbeat. If the oldest request has been in the queue for at least 10 minutes or at least 20 retrieval requests have been accumulated at the time of the heartbeat, the ckBTC minter creates a single Bitcoin transaction to serve up to 100 retrieval requests as follows:

1. It selects available UTXOs with a total sum of at least the sum in the retrieval requests.
2. It constructs a Bitcoin transaction with the selected UTXOs as inputs and an output for each retrieval request plus an additional output for the ckBTC minter’s fee.
3. It uses the Bitcoin canister’s fee API to determine an appropriate fee for the transaction, using the median fee rate.
4. It distributes the fee evenly among all outputs other than the output for the ckBTC minter’s fee.
5. For each input of the transaction, the ckBTC minter invokes the threshold ECDSA functionality (calling the sign_with_ecdsa function) to acquire the required signatures and puts them into the transaction.
6. Lastly, it sends the Bitcoin transaction by invoking the send_transaction function of the Bitcoin integration API.

The BTC retrieval process is depicted in the following figure.

Process of converting ckBTC to BTC.

Note that the amounts in the transfer to the withdrawal account and the retrieval request need not be the same. The retrieve_btc_status endpoint can be used to query the current status of a retrieval request.

Fees

The ckBTC canisters run on an application subnet and must be self-sustainable. Rather than charging cycles for the endpoints, the ckBTC minter accumulates a surplus of BTC over time. In the future, this surplus will be used to swap BTC for cycles to charge both the ckBTC minter and ckBTC ledger.

There is a (growing) surplus because there is a ckBTC transfer fee of 0.0000001 ckBTC and a ckBTC minter fee when retrieving BTC. The latter is determined as follows. Under the conservative assumption that 1 BTC = 10,000 XDR, 1 billion cycles corresponds to 10 satoshi (because 1 trillion cycles corresponds to 1 XDR). The cost to obtain a single EDCSA signature is approximately 21.54 billion cycles on a 28-node subnet, whereas sending a Bitcoin transaction costs 5 billion cycles plus 20 million cycles per byte.

Given these numbers, the cost to sign and send a transaction with in inputs and out outputs is

21.54b*in + 5b + tx_size*20m cycles
< 21.54b*in + 5b + (149*in + 35*out + 10)*20m cycles
< 24.52b*in +0.7b*out + 5.2b cycles
< 246*in + 7*out + 52 satoshi.

The formula 246*in + 7*out + 52 is used to determine the ckBTC minter’s fee in satoshi. Since every transaction has at least one input and one output, the fee is at least 305 satoshi.

This conservative pricing strategy is used so that the other endpoints, which are free of charge, can be subsidized. Moreover, while the retrieve_btc endpoint is relatively expensive, the fee is typically still lower than the Bitcoin miner fee.

See also

• Code Bitcoin on the Internet Computer: https://internetcomputer.org/bitcoin-integration
• Chain-key tokens: https://internetcomputer.org/how-it-works/chain-key-tokens/
• Chain-key Bitcoin developer documents: https://internetcomputer.org/docs/current/developer-docs/integrations/bitcoin/ckbtc