Architecture

BitoBridge is a decentralized application (DApp) that lives on IC and comprises a series of canisters designed to deliver omnichain bridging capabilities for Bitcoin, Bitcoin's emerging tokens, and ICRC-1 and ICRC-2 tokens. It interacts with the Bitcoin blockchain and other blockchains, such as Ethereum, Arbitrum, Aptos, etc. The BitoBridge functionality is built upon the Chain-key Bitcoin and Chain Fusion technology of IC, making it possible for canisters to receive, hold, and send Bitcoin, its tokens, and ICRC tokens and interact with other blockchains directly. Several canisters, the BitoBridge Hub and BitoBridge Relayers, and two smart contracts on each supported blockchain, the Ledger and Helper contracts, provide decentralized, secure, trust-minimized, two-way pegged bridging functionalities.

An overview of the basic architecture of BitoBridge is depicted in the following diagram.

The ICRC <> ERC20 and BTC <> bitoBTC processes are denoted by the ‘ICRC-x’ and ‘BTC-x.’ These processes involve three types of blockchains: Internet Computer, Bitcoin, and other platforms such as Ethereum and Solana.

ICRC <> ERC20

One of the critical functionalities of BitoBridge is the ICRC <> ERC20 feature, which supports the transfer of ICRC1 and ICRC2 tokens to Ethereum and potentially other EVM-compatible blockchains, enabling seamless asset transfers and their subsequent return to the Internet Computer. The basic steps of the ICRC <> ERC20 feature are listed below as "Step ICRC-x":

  • ICRC-1: Beginning at the bottom of the diagram, the user either transfers ICRC1 tokens directly to the BitoBridge Hub canister’s sub-account or grants approval for the Hub canister to transfer ICRC2 tokens on their behalf.

  • ICRC-2: The user then interacts with the BitoBridge Hub canister’s bridge() function, specifying the target_chain , token ledger_id, the token amount they wish to bridge, etc.

  • ICRC-3: The Hub canister initiates the token transfer by invoking the ICRC Ledger's transfer() function for ICRC-1 tokens and transfer_from() function for ICRC-2 tokens.

  • ICRC-4: The ICRC Ledger confirms the transaction and returns the block_index to the Hub canister.

  • ICRC-5: The Hub canister dispatches the minting task to the BitoBridge Minter canister using the dispatch() function.

  • ICRC-6: The BitoBridge Minter canister sends a minting transaction to the target chain’s RPC node using IC’s HTTPS Outcalls [5].

  • ICRC-7: The Target Chain Minter Contract on the target blockchain mints the tokens directly to the user's address.

  • ICRC-8: The RPC node returns the transaction hash (tx_hash) to the BitoBridge Minter canister.

BTC <> bitoBTC

Bridging between BTC on the Bitcoin blockchain and bitoBTC on EVM-compatible chains is facilitated through IC's Chain-key Bitcoin and our ICRC <> ERC20 module, enhancing the bridge’s interoperability. Likewise, bridging between BTC on the Bitcoin blockchain and bitoBTC on non-EVM-compatible chains necessitates the development of specialized ICRC <> Other Blockchain modules tailored for each specific blockchain environment.

The ckBTC Minter is essential in managing ckBTC tokens by minting new ones upon receiving Bitcoin and burning them during Bitcoin withdrawal requests. For security, it waits for six confirmations before minting ckBTC and burns tokens before transferring BTC back to users. The ckBTC ledger adheres to ICRC-2 and ICRC-1 standards, which ensures accurate account balance updates and effective handling of minting and burning operations. Additionally, the ckBTC Minter integrates with the KYT canister to perform ‘know-your-transaction’ (KYT) checks. This critical step confirms that only ‘clean’ bitcoins back the issued ckBTC tokens and prevent transactions associated with illicit activities to Bitcoin addresses. These KYT checks add an extra security layer for ckBTC users, safeguarding the integrity of transactions within the network [5].

The fundamental operations for the BTC <> bitoBTC feature, denoted as "Step BTC-x," proceed as follows:

  • BTC-1: The process starts with the user obtaining a Bitcoin address from the BitoBridge Bitcoin canister.

  • BTC-2 to BTC-4: The BitoBridge Bitcoin canister retrieves the Bitcoin address by calling the ckBTC Minter canister’s get_btc_address() function, which returns the address for the user deposit.

  • BTC-5 to BTC-6: The user deposits BTC into the provided address, and the transaction ID (tx_id) is submitted to the BitoBridge Bitcoin canister.

  • BTC-7: The BitoBridge Bitcoin canister updates the user's balance by signaling the ckBTC Minter canister to update the balance (update_balance()).

  • BTC-8 to BTC-10: The ckBTC Minter retrieves UTXOs from the Bitcoin network and performs KYT checks on the transaction UTXOs and addresses via the KYT canister, receiving a compliance confirmation in return.

  • BTC-11: On passing the KYT checks, the ckBTC Minter mints an equivalent amount of ckBTC corresponding to the deposited BTC (minus fees).

  • BTC-12 to BTC-13: The BitoBridge Bitcoin canister authorizes the BitoBridge Hub canister to manage the newly minted ckBTC, initiating the bridging process with the bridge() function to specify the target chain and token amount.

  • BTC-14 to BTC-15: The Hub canister executes the token transfer using the ckBTC Ledger's transfer_from() function, which validates the transaction and returns a block_index.

  • BTC-16 to BTC-19: Finally, the Hub canister dispatches the minting task to the BitoBridge Minter canister, which sends a minting transaction to the target chain’s RPC node. The corresponding smart contract on the target blockchain then mints bitoBTC tokens directly to the user's address, with the RPC node providing a transaction hash (tx_hash) back to the BitoBridge Minter canister.

This process guarantees a seamless and secure bridging of BTC to EVM blockchains, with potential adaptations for other blockchain types.

PreviousOverviewNextTechnical Details

Last updated