Internet Computer
Status
Mainnet
Type
Sidechain
Fee Token
ckBTC
TVL
₿ 274
The Internet Computer Protocol (ICP) is a network of connected subnet blockchains. It has a smart contract module, known as the Bitcoin Canister, that enables ICP smart contracts to have a view into Bitcoin state and conduct Bitcoin transactions. It additionally has a bitcoin-backed synthetic, known as ckBTC, which sees signers of a multi-sig scheme custody BTC and mint and burn synthetic ckBTC tokens on ICP. Developers can deploy a variety of applications leveraging the Bitcoin canister and ckBTC.
BRIDGE
DATA AVAILABILITY
OPERATORS
SETTLEMENT ASSURANCE
Risk Analysis
Bridge Custody
High risk
🚨
ckBTC multi-sig is managed by an alternative consensus mechanism, but no slashing is in place
Users who deposit funds into the ckBTC smart contract trust a set of operators, who are elected via ICP governance, with the custody of their bitcoin. The operators of the ‘pzp6e…’ subnet manage the “ckBTC” smart contract module, which is responsible for minting, custodying and burning bitcoin-backed tokens on the ICP sidechain.
This smart contract is a part of a subnet with 28 node operators. These operators are responsible for participating as signers within a tECSDA scheme that secures the multi-sig custodying funds on Bitcoin. It would take 10/28 operators to collude and steal user funds from the Bitcoin multi-sig.
This smart contract is a part of a subnet with 28 node operators. These operators are responsible for participating as signers within a tECSDA scheme that secures the multi-sig custodying funds on Bitcoin. It would take 10/28 operators to collude and steal user funds from the Bitcoin multi-sig.
Data Availability
Medium risk
⚠️
DA requirement is fulfilled by an alternative consensus mechanism
Data regarding the state of the ‘pzp6e…’ is made available, and stored, by the 28 individual node operators running the subnet. Should nodes for this subnet go offline, and a backup of the state is not regularly made, then users would lose access to their ckBTC balance and would be unable to burn ckBTC tokens for Bitcoin locked in the respective multi-sig on the mainchain.
Network Operators
Medium risk
⚠️
Liveness guarantees vary between subnets and users cannot self-sequence
Users can leverage their ckBTC on any ICP subnet per the applications they interact with. Users would initiate a “call” to a specific application on any given subnet and a boundary node would route that call accordingly. The contract would then receive the call, initiate the transaction, and see the transaction confirmed should 2 ⁄ 3 of node operators on the given subnet accept it. This sees liveness trust assumptions vary from subnet to subnet. Bitcoin-specific applications would additionally be dependent on the Bitcoin Canister which is on the ‘w4rem…’ subnet, operated by 13 nodes. The 22 Boundary Nodes are managed by a centralized development organization, the DFINITY Foundation.
Settlement Assurance
Medium risk
⚠️
ckBTC settlement assurances provided by an alternative consensus mechanism
Settlement for ckBTC transfers is a result of consensus for the ‘pzp6e…’ subnet operators. Once a transaction is finalized, it cannot be reorged.
Bitcoin Security
Unilateral exits to Bitcoin not possible
Users cannot unilaterally exit from the ICP sidechain with an L1 Bitcoin transaction.
The protocol does not enable MEV on Bitcoin.
ICP’s Bitcoin module is a separate consensus network and has no direct relationship with Bitcoin, and thus does not introduce MEV at the base layer.
An alternative token plays a role in network security
ICP’s network security depends on a governance model that leverages the ICP token for voting. Validators are incentivized with newly issued ICP tokens to run validators. Users do not pay any fees for transactions on ICP subnets.
ICP does not directly contribute to the security budget
ICP does not currently pay fees to Bitcoin miners.
Withdrawals
Withdrawals are permitted by a specific ICP subnet
Withdrawals are ultimately processed by the operators of the ‘pzp6e’ subnet which manages the ckBTC smart contract. Users trust that at least 10 of the 28 signers will remain honest, not steal their funds, and process their withdrawals. If the Bitcoin Canister were to go offline, the ckBTC smart contract would be unable to issue withdrawals for users looking to burn ckBTC and redeem native bitcoin. Withdrawals would be paused until the Bitcoin Canister's subnet came back online.
Technology
Threshold ECDSA Signatures
The ICP network uses tECSDA signatures for ckBTC’s two-way peg with Bitcoin. This sees the private key for the Bitcoin address custodying funds split up, and shared, amongst the 28 nodes operating the relevant subnet.
Bitcoin Canister & Adapter
The ICP network maintains an integration with Bitcoin. The ICP network has a subnet dedicated to the Bitcoin Canister and Adapter. The Bitcoin Canister enables subnets on the ICP blockchain to interact with the Bitcoin network. They can have Bitcoin addresses, sign transactions and submit transactions to the Bitcoin network. The Bitcoin Adapter enables the Bitcoin Canister to access Bitcoin state by querying a randomly selected set of Bitcoin nodes periodically.
Various programming languages and modules supported
The ICP network supports a variety of programming languages and modules. Due to the multi-subnet architecture of ICP, there is no enshrined programming language. Developers can build on top of the subnet that best supports their individual use case. The two primary languages used for developing in ICP are Rust and Mokoto. ICP modules can also support more expressive smart contracts than the Bitcoin mainchain.
Use Cases
Lower fees
ckBTC transactions on ICP are a fraction of a cent as of July, 2024.
Ordinals and Runes trading
ICP supports the creation of Runes, BRC-20 and Ordinals marketplaces. Application developers can deploy on ICP for improved performance of their applications. These application modules are supported by the Bitcoin Canister and Bitcoin Adapter.
Operator
ICP node operators are selected by NNS governance system
The ICP network is operated by a number of permissioned parties who are selected by the NNS governance process. NNS is a tokenized governance mechanism where token holders lock their tokens into a governance contract and are able to vote on proposals and upgrades to the network, including adding and removing node operators from specific subnets. Votes are weighted via the amount of tokens staked in the system and the amount of time tokens have been locked. Voters can delegate their vote if they are unable to individually vote on specific proposals.
Node operators for ICP subnet’s are selected by the ICP NNS governance mechanism. Node operators do not stake any capital and are not subject to slashing, but if they were to misbehave, they would be voted out via ICP’s governance mechanism and lose out on future rewards.
Node operators for ICP subnet’s are selected by the ICP NNS governance mechanism. Node operators do not stake any capital and are not subject to slashing, but if they were to misbehave, they would be voted out via ICP’s governance mechanism and lose out on future rewards.
Source Code
Code related to bitcoin modules are open source
Modules relevant to ICP’s integration with Bitcoin are open source.