A comparison of Bitcoin bridging protocols

In this article, we review different existing Bitcoin bridging protocols and compare them to the Powpeg, which is the solution implemented by RSK.

The main purpose of a bridging protocol is to transfer value across blockchains. In the case of Bitcoin bridges, existing protocols usually lock BTC on Bitcoin to mint or unlock some kind of token on a remote blockchain. We refer to the process of transferring bitcoin to a remote chain as peg-in, and to the process of transferring bitcoin back to Bitcoin as peg-out.

We will use the following criteria in our evaluation of the different protocols:

• Decentralization: the amount of decentralization provided by the protocol
• Usability: various metrics related to user satisfaction, such as speed, fees, and bridging capabilities
• Security: we analyze the security of the protocol from the point of view of four properties:
  - Consistency: the ability of the protocol to guarantee that no token X can be obtained without the corresponding amount of BTC being locked.
  - Liveness: the ability of the protocol to guarantee that users can obtain token X through peg-ins
  - Redeemability: the ability of the protocol to guarantee that users can recover their BTC through peg-outs
  - Funds protection: the ability of the protocol to guarantee that locked BTC cannot be unlocked without the corresponding amount of token X being locked or burned

The RSK Powpeg

The Powpeg is the bridging protocol that connects the RSK sidechain to Bitcoin. The Powpeg consists of three main components: a pre-compiled Bridge contract in RSK, a set of federated entities called Pegnatories, and a set of security devices called the PowHSMs. The Bridge contract provides most of the functionality to transfer bitcoins from and to the Bitcoin network, the PowHSMs protect the locked BTC, and the Pegnatories oversee the correct operation of the Powpeg by acting as data relays between the other components of the bridge, and the RSK and Bitcoin blockchains.

Protocol overview

The peg-in process is the process of transferring BTC to RSK to obtain RBTC and consists of the following steps:

1. A user sends N BTC to the Powpeg address, which is controlled collectively by the Pegnatories’ PowHSMs through a multisig scheme.
2. Each Pegnatory periodically monitors the Powpeg address and keeps track of peg-in transactions.
3. After a predefined number of confirmations, the Pegnatories or the user send the peg-in transaction to the Bridge contract in RSK.
4. The Bridge validates the peg-in transaction using a representation of the Bitcoin blockchain that is updated by the Pegnatories periodically (the user can also update this representation of the Bitcoin blockchain if the Pegnatories are offline or if they refuse to do it).
5. The Bridge contract transfers N RBTC to the user in RSK.

The peg-out process is the process of transferring RBTC to the Bitcoin network to obtain BTC, and consists of the following steps:

1. A user transfers N RBTC to the Bridge contract in RSK.
2. The Bridge stores the peg-out request in a queue.
3. The Pegnatories periodically call the Bridge contract. In this call, the Bridge contract:
   - Takes the oldest peg-out request from the queue and builds a Bitcoin transaction that transfers N BTC to the user.
   - Places the Bitcoin transaction in a queue to wait for confirmations, and generates an event.
   - Checks for Bitcoin transactions with enough confirmations, and moves them to another queue to wait for signatures.
4. The Pegnatories periodically poll the Bridge to obtain Bitcoin transactions that are waiting to be signed.
5. Pegnatories take the confirmed Bitcoin transaction and send it to their PowHSMs.
6. The PowHSM validates that the Bitcoin transaction was built by the Bridge and that it is included in an RSK transaction secured by a certain amount of computational work.
7. The PowHSM signs every input of the transaction.
8. Each Pegnatory sends one signature to the Bridge contract.
9. The Bridge contract validates the signatures and produces an event once more than half of the Pegnatories have produced valid signatures.
10. One of the Pegnatories collects the signed Bitcoin transaction and sends it to the Bitcoin network. Once mined, the transaction transfers N BTC from the Powpeg address to the user’s Bitcoin address.

Decentralization

The Powpeg is a federated bridge that is not completely decentralized. The peg-in process is decentralized considering that any user can update the Bridge contract with Bitcoin block headers. However, there is a strong dependency on Pegnatories to guarantee the security of the process. The peg-out process requires the involvement of the Pegnatories, and thus, is partially centralized. The current number of Pegnatories is 13.

Usability

Peg-ins are free (apart from the cost of the Bitcoin transaction), take 100 Bitcoin confirmations (~16 hours), and have a minimum amount of 0.005 BTC. Peg-outs take 4,000 RSK confirmations (~33 hours), cost 85 satoshis per byte, and have a minimum amount of 0.004 RBTC.

Security

The Powpeg guarantees consistency as long as a majority of Pegnatories remain honest and online. The Bridge contract verifies that there is a Bitcoin transaction that sends funds to the Powpeg. However, in this verification, the Bridge relies on a view of the Bitcoin blockchain that can be provided by any user, and that is safeguarded by the Pegnatories. This view of the Bitcoin blockchain can be manipulated if a number of Pegnatories are compromised or become offline. This would allow unlocking RBTC without previously locking BTC.

Redeemability in the Powpeg also requires the intervention of the Pegnatories and their PowHSMs. This means that if a majority of Pegnatories goes offline or becomes dishonest, users are not able to peg-out. However, Pegnatories do not have direct access to the keys that control the locked BTC. The PowHSM verifies that the BTC unlocking transaction is included in an RSK transaction secured with a certain amount of computational work. This means that forcing the PowHSM to sign fraudulent transactions is extremely expensive and potentially unfeasible. In the event of a majority of Pegnatories going offline, BTC can be unlocked after one year with a set of emergency keys that belong to various actors in the community. This prevents the loss of funds, but it is not clear how the BTC would return to the users.

Finally, the Powpeg provides liveness as any user can communicate Bitcoin block headers to the Bridge contract and the peg-in process does not require the intervention of the Pegnatories.

Liquid

Liquid is a Bitcoin sidechain that provides a bridge similar to the Powpeg (although there is no evidence that Liquid HSMs use Secure Elements for private key storage, as RSK PowHSM’s do). In Liquid, there are two main groups of functionaries: the blocksigners, which are in charge of producing new Liquid blocks, and the watchmen, which are in charge of signing the peg-out transactions.

Protocol overview

The peg-in process in Liquid consists of the following steps:

1. The user sends BTC to an address controlled by the watchmen.
   - The destination address is a modified Bitcoin address linked to the user’s Liquid address.
2. After the deposit transaction reaches 100 Bitcoin confirmations, the user creates a Liquid transaction to claim the coins.
   - This Liquid transaction references the deposit transaction output, and contains among other information, the serialized Bitcoin transaction and a Merkle proof.
3. The blocksigners verify and include the Liquid unlocking transaction in the Liquid blockchain, transferring L-BTC to the defined user address.
   - Liquid users also validate the Bitcoin locking transaction when accepting the Liquid block.

In Liquid, only federation members are allowed to peg-out, and users must find an external mechanism, such as an exchange, to convert their L-BTC back to BTC.

Decentralization

Liquid is partially centralized as only blocksigners can produce new blocks. Peg-ins can be initiated by any user, but need to be included in the Liquid blockchain by blocksigners. Peg-outs require 11 out of 15 watchmen signatures to unlock the BTC, and can only be initiated by members of the federation.

Usability

Peg-ins require 100 Bitcoin block confirmations plus an additional Liquid transaction. Users need to run a full Bitcoin node and a full Liquid node to be able to peg-in, and must have L-BTC to submit the Liquid transaction.

Only federation members are allowed to peg-out, so users must find an external mechanism to get their BTC back. For example, using SideSwap takes from 20 minutes to 4 hours and costs from ~3.5 to ~1.8 satoshis per byte.

Security

Liquid guarantees consistency because both blocksigners and users validate the BTC input in Liquid transactions. It is not possible to create L-BTC without the corresponding amount of BTC being sent to the watchmen. This means that blocksigners and users must also run a Bitcoin client.

Redeemability in Liquid is not guaranteed as users cannot peg-out and must find an external service to get BTC in exchange for their L-BTC. In addition, a majority of dishonest watchmen could steal the locked BTC. In the case that watchmen become offline, the locked BTC can be recovered through an emergency withdrawal after 28 days.

Liquid provides liveness as long as blocksigners are online. That is, users cannot peg-in without the intervention of blocksigners.

Comparison to the Powpeg

The Liquid bridge is very similar to the Powpeg in terms of governance, decentralization and usability. The key differences between the two protocols are that Liquid is able to provide faster peg-outs because it does not rely on PoW consensus. However, the Powpeg provides greater security because Pegnatories do not have direct access to the keys that control the locked BTC. In the Liquid whitepaper, the authors state that not using a device similar to the PowHSM is a design choice. In addition to this, the emergency protocol to unlock funds after a period of inactivity is much shorter in Liquid. This makes a DoS attack on the watchmen more feasible than on the Powpeg.

Interlay (Polkadot)

Polkadot is a decentralized platform that enables the interoperability between different blockchains. Any blockchain can connect to Polkadot as a parachain and interact with other parachains through an established communication protocol. Interlay is a parachain that provides a bridge to the Bitcoin blockchain.

Protocol overview

The process of transferring BTC to the Interlay parachain is called issuing and requires the creation of a collateralized Vault. Any user with enough funds can create a Vault by locking collateral on Interlay (typically in the DOT token). Vaults can then mint interBTC after receiving BTC on Bitcoin. The issuing of interBTC consists of the following steps:

1. Precondition: a Vault has locked collateral.
2. The user sends an issue request in Interlay that includes the amount of interBTC the user wants to issue, the selected Vault, and a small collateral reserve to prevent Griefing.
3. The user sends the requested amount of BTC to the Vault on the Bitcoin blockchain.
   - The deposit address is derived from the Vault address and a unique identifier
4. The user, or Vault acting on behalf of the user, extracts a transaction inclusion proof of the locking transaction on the Bitcoin blockchain.
5. The user, or a Vault acting on behalf of the user, triggers the issuance of interBTC by providing the bridge with a transaction inclusion proof of the Bitcoin locking transaction.
   - This is possible because the Interlay parachain implements a Bitcoin SPV client that is updated with Bitcoin block headers by relayers or vaults
   - The bridge verifies the destination address and quantity of the deposit transaction

Transferring interBTC to Bitcoin in Interlay is called redeem and consists of the following steps:

1. The user locks an amount of interBTC with the Interlay bridge. In this function call, the user selects a Vault to execute the redeem request from the list of vaults. The function creates a redeem request with a unique hash.
2. The selected Vault listens for the redeem event emitted by the user. The Vault then proceeds to transfer BTC to the address specified by the user in the request function including a unique hash in the OP_RETURN of one of the outputs.
3. The Vault executes the redeem by providing the Bitcoin transaction from step 2 together with the redeem request identifier within the time limit. If the function completes successfully, the locked interBTC are destroyed and the user receives BTC.
4. Optional: If the user could not receive BTC within the given time (as required in step 3), the user can cancel the redeem after the redeem time limit. The user can choose either to reimburse, or to retry. In case of reimbursement, the user transfers ownership of the tokens to the Vault, but receives collateral in exchange. In case of retry, the user gets back his tokens. In either case, the user is given some part of the Vault’s collateral as compensation for the inconvenience.
   - Optional: If during the cancel redeem the user selects reimbursement, and as a result the Vault becomes undercollateralized, the Vault does not receive the user’s tokens — they are burned, and the Vault’s tokens decrease. When, at some later point, the Vault gets sufficient collateral, it can mint additional tokens.

Decentralization

In theory, Interlay is decentralized as any user can become a Collator or a Validator. In practice, at the current test stage, there are only a few Collators that work in a proof-of-authority or federated manner. Access to funds is also decentralized as anyone can stake DOT in Interlay to become a Bitcoin Vault. The level of decentralization in Interlay thus depends on the number of users willing to provide collateral to become one of these three possible actors.

A part of the protocol that can be considered partially centralized are the oracles that provide the exchange rate between the staked token and BTC. This rate is used to decide when to liquidate the vaults.

Usability

The cost of peg-ins and peg-outs is 0.5% interBTC plus the cost of the necessary Bitcoin and Interlay transactions.

The number of confirmations required for peg-ins and peg-outs is variable and depends on the Vault.

Security

Interlay does not fully guarantee consistency as the protocol is vulnerable to replay attacks. The Bitcoin SPV client in the bridge validates transaction inclusion but does not verify if the transaction has been already processed. This allows a dishonest Vault to present a peg-in transaction twice and mint counterfeit interBTC. Interlay mitigates this risk by penalizing Vaults if they move the locked BTC. However, the protocol relies on relayers or other vaults to expose misbehaviors.

Since the Bitcoin SPV client receives block headers from relayers and vaults, another way to break consistency is to present the Bitcoin SPV client with fake block headers and deposit transactions.

Redeemability is guaranteed in the sense that users get the Vault’s collateral at a favorable rate if a Vault is liquidated. However, users are not guaranteed to be able to peg-out and get their BTC back. Vaults might choose to steal the BTC at any point if the situation is economically favorable for them. In the event of a sudden drop in the exchange rate between the staked token and BTC, users are at risk of losing funds.

Interlay provides liveness as long as there are available Vaults and Collators. Since Vaults need to be overcollateralized, the protocol might have scalability issues that lead to service interruptions if many users peg-in their BTC.

Comparison to the Powpeg

Interlay provides greater decentralization than the Powpeg in theory. However, the degree of decentralization of Interlay is dependent on the number of Vaults, Collators and Validators. Also, Interlay depends on oracles that might not be as decentralized as other components. In addition to this, Interlay is currently in a testnet stage with lower decentralization than expected when the protocol is deployed in production.

In terms of usability, Interlay might be able to offer lower transfer times and fees than the Powpeg because of the competition between vaults. However, this also depends on the number of vaults, which might be limited by the fact that vaults need to be overcollateralized.

Interlay’s decentralized design comes at the cost of lower security guarantees. Compared to the Powpeg, Interlay provides weaker consistency and liveness. In the Powpeg, users can peg-in without the intervention of the Pegnatories, whereas in Interlay, users need a Vault and at least one honest Collator. Interlay also provides weaker redeemability than the Powpeg because users are not guaranteed to be able to peg-out. In the Powpeg, the risk of losing BTC is low because of the PowHSMs security and the emergency withdrawal mechanism in case a majority of Pegnatories goes offline. In Interlay, the risk of losing BTC is greater as Vaults essentially acquire an indefinite option contract to purchase BTC in exchange for their stake.

Ren

Ren is a cross-chain interoperability protocol currently in early stages of development. The main idea of the protocol is to secure BTC by consensus using multi-party computation where a predefined number of user signatures are required to unlock the funds. However, the project does not provide many technical details yet and, at the current development stage, the protocol is working as a federated bridge. Details about the number of federators or the level of security are not available either. The cost is around 0.3% for peg-ins and around 0.2% for peg-outs.

WBTC

WBTC is a protocol for creating BTC-backed wrapped tokens on various platforms, including Ethereum and Arbitrum. However, WBTC does not directly provide users with means to peg-in and peg-out. Instead, WBTC is more of a BTC-backed token that users can buy from external exchanges.

Protocol overview

The protocol consists of two main actors apart from the user: the Custodian and the Merchant. The peg-in process is as follows:

1. The Merchant sends BTC to the Custodian
2. The Custodian mints and sends the equivalent amount of WBTC to the Merchant after 6 confirmations
3. The user performs anti-money laundering (AML) and know-your-customer (KYC) processes with the Merchant
4. The user gets WBTC through an atomic swap with the Merchant or by trusting the Merchant

The interaction between the Custodian and the Merchant does not need to be at the same time as the interaction between the user and the Merchant. This means that Merchants act as liquidity providers. The exchange between user and Merchant can also be performed using a trusted exchange. The peg-out process is similar to the peg-in process and consists of the following steps:

1. The Merchant burns WBTC
2. The Custodian sends BTC to the Merchant after 25 confirmations
3. The user performs KYC and AML with the Merchant
4. The user and the Merchant exchange WBTC and BTC by any means

Decentralization

The protocol is completely centralized as the Custodian is enacted by BitGo. BitGo uses a multisignature address to control the funds, however, it is not clear who controls the different keys.

Transfers can happen in a decentralized manner as long as there is an available (and willing) Merchant. However, the protocol does not define the interaction between the user and the Merchant, and thus, transfers could also be performed in a centralized manner.

Usability

WBTC does not define means to peg-in and peg-out for users. Instead, users must rely on exchanges to buy WBTC. Most of these exchanges do not allow buying WBTC with BTC. In addition, users need to perform KYC and AML with the Merchant to peg-in and peg-out. This limits the usability of the platform as it does not respect user privacy.

Security

WBTC guarantees consistency as long as Merchants and the Custodian remain honest. The Custodian is the one in charge of minting WBTC, but the protocol requires a previous request from a Merchant. A malicious Merchant and Custodian could mint WBTC without BTC being locked.

Similarly, the protocol guarantees liveness as long as a Merchant and a Custodian are online and able to process requests. Moreover, the user needs to find a mechanism to exchange WBTC with the Merchant, which could be unavailable or not willing to sell WBTC in exchange for BTC.

WBTC provides redeemability also as long as the Custodian and a Merchant are online. Users and Merchants are not guaranteed to be able to recover their BTC if the Custodian is attacked. In this case, BitGo provides insurance up to $100 million. Moreover, users are not guaranteed to be able to get their BTC back unless there is a Merchant willing to buy WBTC.

Comparison to the Powpeg

WBTC implements a similar bridging process to the Powpeg but in a centralized manner. In the end, the whole protocol relies on the availability and integrity of BitGo. Compared to the Powpeg, WBTC is less secure because of BitGo’s single point of failure. Funds are protected by a multisignature address, but all keys are controlled by a single institution that becomes a tempting target for attackers.

In addition to this, WBTC is less usable than the Powpeg because it requires users to interact with a Merchant using an external mechanism, such as an atomic swap or an exchange. WBTC does not directly provide means to convert BTC to WBTC or vice versa. More than a bridging protocol, WBTC is a BTC-backed token. Finally, WBTC does not respect user privacy because it requires KYC and AML procedures.

pTokens

pTokens is a federated protocol to transfer value from one blockchain to another. The protocol is very similar to the Powpeg with some differences, such as using Software Guard Extensions (SGX) instead of an HSM.

Protocol overview

The pTokens white paper describes the process of transferring tokens between two blockchains with support for smart contracts. We assume that transfers from Bitcoin to Ethereum are performed in a similar manner. The peg-in process is as follows:

1. The user sends BTC to a multi-signature address controlled by a set of validators
2. The user or the validators submit the locking transaction along with the Bitcoin block to the Trusted Execution Environments (TEE) powered by SGX.
3. The TEEs validate the block and transaction and generate a signed minting transaction
4. The validators put together their signatures using a Multi-Party Computation algorithm
5. Validators transmit the transaction to a smart contract on Ethereum, which mints the pBTC

The peg-out process is equivalent to the peg-in. However, technical details about the interactions with the Bitcoin blockchain are not available.

Decentralization

The protocol is partially decentralized in theory. At the current stage, however, the bridging mechanism is completely centralized.

Usability

The cost of peg-ins and peg-outs is 0.1% and 0.25% respectively. The protocol requires only a few confirmations both for peg-ins and peg-outs.

Security

At the current stage, pTokens completely relies on a single institution. Thus, consistency, liveness and redeemability are only guaranteed as long as this institution remains honest and online. The use of SGX guarantees higher redeemability than other protocols as locked BTC are secured by proof-of-work.

Comparison to the Powpeg

The design of the pToken protocol is very similar to the Powpeg. The main differences between the two protocols are:

• pTokens is less secure because it uses SGX, which has been partially deprecated, instead of an HSM
• pTokens does not allow peg-ins without the interaction of the validators
• pTokens is less auditable because the interaction between the different validators is carried out off-chain
• pTokens only requires a few confirmations for peg-ins and peg-outs

tBTC

tBTC is a collateralized bridging protocol between Bitcoin and Ethereum similar to Interlay that uses the Keep network in an auxiliary manner.

Protocol overview

The protocol requires a set of signers that act as a BTC vault and place a bond on the destination chain (Ethereum in this case). The peg-in process is as follows:

1. The user sends a deposit request to a smart contract on Ethereum
   - The peg-in request can only be of a set of fixed amounts
2. The system selects a random set of signers to receive the BTC deposit
   - The selection of signers is performed off-chain using the Keep network
   - Signers must stake 150% of the transferred value in ETH (as collateral)
3. The selected signers produce a threshold signature address and send it to the smart contract in Ethereum
   - This process is also carried out in the Keep network
4. The smart contract gives the user an NFT representing the deposit
   - This NFT gives the user the right to claim the tBTC
5. The user sends BTC to the deposit address
6. After 6 confirmations, the user sends an SPV proof of the deposit to another smart contract to redeem the NFT for newly minted tBTC

The SPV client in the smart contract keeps track of a number of Bitcoin block headers and checks that the difficulty adjustment in these blocks is consistent with Bitcoin’s algorithm.

The peg-in process creates a one-to-one relationship between staked collateral and a deposit. The protocol does not allow transferring an arbitrary amount of BTC, it only allows peg-ins in batches of predefined quantities. Signers only recover their collateral after the user performs a peg-out (see below).

The protocol defines deadlines for the deposit and for producing the deposit address. If the involved parties do not meet their deadlines the protocol establishes compensation mechanisms. This means that the user might receive part of the signer’s collateral instead of tBTC.

The peg-out process is as follows:

1. The user makes a redemption request for a particular deposit on the smart contract on Ethereum
   - The request contains the fee and the destination address
2. The smart contract notifies the signers about the request
3. The signers wait for a number of confirmations and produce a joint signature
4. The smart contract generates a Bitcoin transaction that pays the user BTC
5. Signers send the transaction to Bitcoin paying the user
6. Signers provide the smart contract an SPV proof of the peg-out transaction to unlock their collateral

BTC deposits are linked to a particular user, and set of signers and their collateral. Deposits also define a 6 month expiration date. Before this date, only the user that requested the peg-in can recover the deposit via a peg-out. When the deposit expires, any user can perform a peg-out and claim the deposit. tBTC does not guarantee that the supply of tBTC is equal to the amount of locked BTC. Instead, the protocol tries to enforce that the supply of tBTC is less or equal to the amount of locked BTC.

Decentralization

tBTC provides significant decentralization as the number of available signers is 80. However, the oracles necessary to provide the exchange rate between BTC and ETH can become a point of centralization.

Usability

Peg-ins and peg-outs only require the number of confirmations typically considered safe in each chain (i.e., 6 in Bitcoin). Peg-outs cost 20 satoshis/byte, and users are required to submit various transactions in Bitcoin and Ethereum to peg-in and peg-out. In addition, the protocol suffers from certain usability issues, such as fixed (and very high) peg-in quantities and loss of funds in case of mistakes in the deposit transaction.

Security

tBTC provides partial consistency. The stateless SPV client in the smart contract verifies only a set of Bitcoin block headers. Although it would be difficult, a group of malicious signers could trick the smart contract into minting tBTC without the corresponding amount of BTC being locked.

tBTC guarantees liveness as long as there is a set of signers available and with the necessary collateral. In the event of an increase in users, liveness could be at risk as signers might not be able (or willing) to provide the necessary liquidity.

In terms of redeemability, tBTC suffers the limitations of other collateralized systems like Interlay. Namely, users are not guaranteed to be able to get their BTC back as signers can steal the funds at any time if it is economically advantageous for them. The protocol tries to guarantee that the tBTC supply is always equal or less than the locked BTC. However, in high volatility markets, the system is vulnerable to mass exits and vault liquidations.

Comparison to the Powpeg

Compared to the Powpeg, tBTC provides greater decentralization as there are more signers, and signers are chosen at random for each deposit. The main difference between the Powpeg and tBTC is in the protection of the locked funds. The Powpeg protects the BTC via proof-of-work, while tBTC implements a series of economic incentives to minimize the risk of malicious behavior. In addition to this, the Powpeg allows peg-ins without the intervention of the Pegnatories, whereas tBTC always requires a set of available signers.

Stacks

Stacks is a blockchain that claims to allow running smart contracts with Bitcoin. Stacks is connected to the Bitcoin blockchain through their consensus protocol, called proof-of-transfer (PoX). Miners in PoX compete against each other by transferring BTC to STX token holders. The greater the amount of BTC transferred, the greater the chances of mining a new Stacks block and claiming rewards in STX. Miners pay BTC to STX holders for a chance of getting STX and become holders themselves. However, we do not consider Stacks a real bridging protocol because it does not provide a mechanism to obtain BTC from STX and because it does not maintain a 1:1 exchange rate between STX and BTC. You can read more about Stacks here.

Summary

The following table summarizes the characteristics of the existing protocols. The comparison takes into account the current state of the project and not the potential features of the design.

Conclusions

Compared to existing approaches, the Powpeg provides the best trade-off between decentralization and security. More decentralized protocols like Interlay and tBTC are still in early stages of development and achieve higher decentralization via overcollateralization, which limits scalability and liveness, and does not guarantee redeemability. The Powpeg is less decentralized than Interlay and tBTC but protects the BTC using proof-of-work instead of just economic incentives.

Centralized protocols, such as RenVM and pBTC, provide higher usability than the Powpeg but less security. Other centralized protocols, like WBTC, do not even provide better usability than the Powpeg.

Liquid is the protocol that is more similar to the Powpeg. Liquid provides better consistency than the Powpeg because Liquid nodes also validate the Bitcoin blockchain. However, the Powpeg provides better protection of the locked BTC, better usability, and better redeemability as Liquid does not define a mechanism for peg-outs.

One of the major limitations of the Powpeg when compared to other protocols is higher transfer times. This is addressed by the Flyover protocol, which reduces the number of confirmations required by the Powpeg without weakening the security of the process. In addition to this, the Powpeg could achieve a similar degree of decentralization as tBTC or Interlay by increasing the number of Pegnatories.