Comparing two-way bitcoin pegs

An increasing number of projects are solving the problem of how to convert BTC into a 1:1 pegged asset on another blockchain and back: the “two-way peg”. Each has its own approach. This blog post will look at several of the different approaches and compare them. Keep in mind that this is a fast-moving space and many of the details described here are subject to change as these systems evolve.

Comparison table

With the exception of Drivechain — which is currently only available as a testnet implementation and requires soft-fork changes to bitcoin to be used on mainnet — each of these peg systems relies on either single-sig or multisig scripts to secure BTC on the mainchain due to limitations in bitcoin’s current scripting capabilities.

Several of the systems require a “bond” on the altchain side to help keep the multisig signers honest: if the signers misbehave, or if their collateral drops in value, then the bond could be slashed/liquidated. In the case of bonds that are tied to the value of the BTC held in the multisig, various types of oracles are used to constantly monitor the exchange rate between the bond collateral and BTC. And to protect against certain kinds of attacks or failure modes, a withdrawal delay is implemented before BTC is released back to an address on the bitcoin mainchain.

Each two-way peg mechanism is different, offering different trust and security models to serve different levels of risk tolerance and cost preferences. Let’s examine each of these peg mechanisms in more detail.

Drivechain

Drivechain ‘s claim to fame is the permissionless two-way peg. While all of the other two-way peg mechanisms in this post are permissioned to some degree, meaning that users need the explicit permission of a third party (or third parties) to “peg-out” and take control of BTC on the mainchain, Drivechain offers a novel permissionless mechanism for moving BTC from a peg-in address back to a withdrawal address on the bitcoin mainchain.

The Drivechain peg

Drivechain implements its two-way peg using a mechanism called a hashrate escrow . This is the first and currently only working two-way peg mechanism that is fully permissionless, meaning that no permission is required from any third parties in the system to participate in the peg-in and peg-out process.

At a high level, this is how the hashrate escrow works:

1. A user on the mainchain deposits their BTC into a hashrate escrow address known to be associated with a specific Drivechain-based blockchain (henceforth referred to as a “drivechain”).
2. A user on the drivechain later requests to withdraw their BTC back to a mainchain address.
3. A bitcoin miner will gather the withdrawal transactions on the drivechain into a bundle and mine a transaction in a block on the mainchain specifying the address(es) to which BTC held in the hashrate escrow address should be withdrawn.
4. Bitcoin miners “upvote” or “downvote” the mainchain withdrawal transaction over a specified number of blocks. If the mainchain withdrawal transaction accumulates enough upvotes within the specified number of blocks, then the coins are released from the hashrate escrow to the specified address(es).

In effect, bitcoin held in the hashrate escrow is under the shared custody of bitcoin miners. Though the Drivechain trust model is novel compared to existing peg mechanisms, it shares some similarity with the current bitcoin trust model. Even today BTC on the mainchain is, in a way, also held under the shared custody of bitcoin miners.

When bitcoin users receive on-chain payments, they are “trusting” that a majority of the hashrate will not collude to reverse their payment once it is confirmed. The reason why that trust is well-placed is because miners have made significant investments into their mining operations. If miners start reversing confirmed payments then bitcoin loses value as a payment system, threatening the value of bitcoin miners’ investment. That’s not to say that bitcoin is immune from such attacks, only that they are considered unlikely to happen.

As Satoshi Nakamoto states of possible majority hashrate attackers in the bitcoin whitepaper:

He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.

Drivechain similarly assumes that bitcoin miners prefer the additional income provided by drivechains rather than to steal from hashrate escrows, undermine confidence in the Drivechain mechanism, potentially spoil any future income they could earn from drivechains, and even potentially undermine the value of bitcoin itself (thus destroying the value of the coins they have stolen). By attacking hashrate escrows, bitcoin miners would be destroying a valuable source of revenue. In short, Drivechain assumes that miners prefer making money to losing money — a generally safe assumption.

Bond, bond amount, and oracle used

The bitcoin miners who effectively control the coins in the hashrate escrow are not bonded. Since the mainchain is not aware of what is happening on drivechains by design , it wouldn’t even be possible to implement a decentralized/permissionless bonding mechanism. Instead, Drivechain assumes that miners will be rationally self-interested enough to want to 1) continue collecting drivechain fees, 2) prevent having their malicious withdrawal transaction UASF’d out of the mainchain, and 3) protect the value of their mining hardware and future block rewards. A successful attack on a popular drivechain would likely threaten these interests, which is why Drivechain assumes that such an attack would either not happen or not succeed if attempted.

Withdrawal delay

The current implementation of Drivechain imposes a six-month delay on all withdrawals from a drivechain back to the mainchain. The reason for this is to give drivechain users and other miners plenty of time to notice a “malicious” withdrawal i.e. a withdrawal on the mainchain that does not match a withdrawal on the drivechain, and react to it. Specifically, in reaction to a malicious withdrawal 1) users would be able to implement a UASF so that their bitcoin full nodes reject all blocks building on the block the malicious withdrawal is mined in and 2) miners would be able to either support the UASF by refusing to build their blocks on top of the malicious withdrawal or, if they do not support the UASF, they can at least downvote the withdrawal transaction to decrease its chances of success.

Incognito

Incognito is a Proof-of-Stake (PoS) blockchain that implements a two-way bitcoin peg using a network of bonded custodians. These custodians are registered with a bond smart contract on the Incognito blockchain. Deposits sent to these custodians are held in single-signature P2PKH addresses.

The Incognito peg

The Incognito peg is implemented by sending bitcoin to a bonded custodian selected by the Incognito protocol. The Incognito developers call these custodians “ trustless custodians ” however in the current implementation there is still trust involved due in part to the use of a centralized oracle. After a number of confirmations on the bitcoin mainchain, a private coin or “pCoin” called pBTC is minted on the Incognito blockchain representing the amount of BTC that was sent to the custodian.

Bond, bond amount, and oracle used

Incognito custodians must submit PRV (the native token of the Incognito blockchain) equal to at least 150% of the value that they custody to a bond smart contract on the Incognito blockchain. If the value of their collateral ever drops below 110% of the value under custody then the custodian’s collateral is liquidated to re-capitalize the system. Additionally, if a custodian ever fails to honor a withdrawal request by a user, then the custodian’s bond will be liquidated and given to the user as compensation.

The value of the bonded PRV relative to the value of BTC held by each bonded custodian is determined by an oracle currently run by the core Incognito development team .

Withdrawal delay

According to a post on the Incognito blog, it takes no longer than 12 hours for either a redemption of pBTC for mainchain BTC or for the collateral of the custodian selected for the redemption to be liquidated and turned over to the user in place of the BTC expected. In a best-case scenario, withdrawals should take no more than 15 minutes .

Liquid

Liquid is a federated blockchain, meaning that block producers and multisig functionaries are selected by a permissioned federation of independent entities. The Liquid software and functionary hardware used to secure the Liquid blockchain and BTC held in the federation multisig are developed by Blockstream.

The Liquid peg

Liquid implements a permissioned two-way peg using 11-of-15 federated multisig accounts. Membership in the federated multisig is determined by Liquid Network governance . Liquid multisig members are called “functionaries”. Functionaries secure the BTC held in their multisig accounts using custom hardware security modules (HSMs) installed on “functionary” hardware nodes developed by Blockstream. This hardware is designed to autonomously sign valid withdrawals and self-destruct if evidence of tampering is detected. In the event of a consensus failure preventing multisig withdrawals over a period of time, BTC held in the federated multisig is automatically transferred to an “ emergency ” 2-of-3 multisig address controlled by Blockstream.

Bond, bond amount, and oracle used

Liquid functionaries are not bonded, and neither is Blockstream. Each L-BTC on the Liquid blockchain is backed 1:1 by BTC held in the custody of the federation multisig (or emergency multisig, if the emergency protocol has been activated), and no oracle is used or needed to enforce the peg.

Withdrawal delay

According to the Liquid documentation, “ only members of the Liquid network are able to peg-out L-BTC ” and peg-outs have “ an expected processing time of 11 to 35 minutes depending on the network conditions “. Liquid documentation further warns users to “not acquire L-BTC without having a way to convert back to BTC. L-BTC peg-outs must be performed via a Liquid member.”

RenVM

RenVM describes itself as a “trustless and decentralized virtual machine”. This description is currently more aspiration than reality. Much of the RenVM software is closed source, so it is not currently possible to independently verify claims that they make about how the software works. Therefore, for this overview, I’m going to treat the RenVM software as a black box and assume it works as advertised.

The RenVM peg

The RenVM peg is implemented using a network of computers called “Darknodes”. These Darknodes are organized into randomized, non-overlapping groups called shards. Each shard is made up of at least 100 Darknodes. Together these shards use an algorithm called Ross Zian-Loong (RZL) Secure Multi-Party Computation (sMPC) to generate an ECDSA keypair for accepting bitcoin deposits and signing off on bitcoin withdrawals. So long as two-thirds or more of the Darknodes in a shard are honest, a malicious withdrawal cannot succeed.

In addition, there is currently a shard called Greycore comprised of nodes chosen by the Ren development team. The Greycore shard must co-sign all mint and release transactions, effectively making the RenVM a 2-of-2 multisig between Darknode shards and the Greycore shard. However because shards are themselves made up of multiple nodes signing using a share of a private key, liveness of the system can be preserved even if a number of Darknodes and Greycore nodes become unavailable.

Bond, bond amount, and oracle used

Darknodes must deposit 100,000 REN, an ERC-20 token, into a bond smart contract called the Darknode Registry on the Ethereum blockchain. If Darknodes were to ever steal assets held in the custody of their shard, then “RenVM can slash the bonds of the responsible Darknodes, and use the bonds to restore the one-to-one peg by buying-back-and-burning the same amount of pegged assets.”

To report shard misbehavior, a challenger can submit a bonded challenge to an Ethereum smart contract called the Darknode Slasher. If the challenge succeeds, then every Darknode that is part of the misbehaving shard will have its bond slashed. Individual Darknodes can also have their bond slashed for various types of misbehavior .

Since the bond value is fixed at 100,000 REN, as opposed to being intrinsically tied to the amount of BTC in custody of the RenVM, no oracle is needed to track the value of bonds relative to the value of BTC held in custody.

Withdrawal delay

RenVM waits for 30 Ethereum confirmations after burning the RenBTC ERC-20 token before releasing BTC to the specified withdrawal address on the mainchain.

RSK

In January 2018, RSK launched the first federated two-way peg connected to the bitcoin mainchain. The main goal of RSK is to bring Ethereum-compatible Web3 infrastructure and smart contracting to a BTC-powered blockchain. RSK shares similarities with the aforementioned Liquid blockchain, for example both use a federated network of HSMs to secure BTC in custody of the two-way peg.

The RSK peg

Deposits of BTC to RSK are held in an 8-of-15 federated multisig account. Members of the multisig were initially selected by RSK Labs. Membership changes are first proposed by RSK Labs and then voted on by existing federation members using a transparent process coordinated by a smart contract on RSK. The private keys used to secure BTC held in the federation multisig are stored inside off-the-shelf HSM chips. Key generation and transaction signing is performed using custom HSM firmware provided by RSK Labs. The hardware and firmware are both open to auditing by federation members if they so desire.

Bond, bond amount, and oracle used

RSK federation members are not bonded. Each R-BTC on the RSK blockchain is backed 1:1 by BTC held in the custody of the federation multisig, and no oracle is used or needed to enforce the peg.

Withdrawal delay

Users convert their R-BTC back to BTC by sending an RSK transaction containing R-BTC and their bitcoin mainchain withdrawal address to the RSK bridge contract address. After a 4000 block delay on the RSK blockchain, the federation will release BTC to the specified withdrawal address.

tBTC

tBTC is a self-described “trust-minimized” two-way peg implementation that currently bridges BTC to the Ethereum blockchain. Of the two-way pegs mentioned so far, the tBTC model is most similar to being a hybrid of the Incognito and RenVM pegs, combining the best elements of both while also adding some new features to secure the peg. Of the two-way pegs mentioned so far that are currently in production on the bitcoin mainchain, tBTC comes closest to the decentralized, permissionless, trust-minimized ideal embodied in bitcoin itself.

Edit: When I first started writing this section, tBTC was in production. After a bug was discovered (but not exploited) in the tBTC smart contract system, the tBTC development team paused new deposits and existing deposits were refunded. As of the time of publishing, the tBTC dapp has not yet been re-launched.

The tBTC peg

Deposits of BTC to the tBTC system are held in a 3-of-3 federated multisig address. Federation members (“signers”) are randomly selected for each deposit from a pool of nodes staking KEEP tokens on the Ethereum blockchain. The tBTC technical specification document notes that, “tBTC is designed to be resilient even if the same entity controls all signers in a signing group.”

Once signers know they have been selected to join a group, they deposit ETH to a bond smart contract worth at least 150% of the value of any BTC they anticipate taking shared custody of. The signing group then coordinates to generate a public ECDSA key that is used to derive the multisig deposit address.

Once a deposit has a sufficient number of confirmations on the bitcoin mainchain, the depositor can generate an SPV proof and send the proof to the tBTC smart contract to mint TBTC on the Ethereum blockchain. A similar process is performed in reverse so that users can redeem their TBTC for mainchain BTC.

tBTC anticipates and protects against two different types of signer misbehavior: signer failure, and signer fraud, and each is treated differently. In cases of signer failure, where the signers fail to properly sign off on a TBTC redemption or produce an SPV proof of inclusion for a redemption, signer bonds are liquidated and auctioned off for TBTC. This TBTC is used to compensate the user whose redemption request has failed. Any ETH left over from the auction is returned to the signers.

In the case of signer fraud, where signers attempt to steal the BTC held in their custody, both the signer bond and the KEEP stake are slashed. The bond is auctioned off for TBTC, which is then used to re-capitalize the system. The KEEP tokens that are slashed are burned as punishment for fraud. Anyone can submit a fraud proof to the tBTC smart contract and receive as a bounty any ETH leftover after the bond auction.

Bond, bond amount, and oracle used

As mentioned, each signer group must submit a bond in ETH worth at least 150% of the value of the BTC in their custody. Bonds that fall below 125% of the required value enter a “pre-liquidation” phase:

The exchange rate between ETH and BTC is tracked using the MakerDAO ETHBTC Medianizer . This oracle medianizes prices reported by the Binance, HitBTC, Coinbase, Poloniex, Huobi, and Bitfinex exchanges. Worth noting is that while a manipulated price feed can harm signers by pushing bonds into liquidation, due to the high-start auction used to liquidate bonds, in a functional market a manipulated price feed cannot harm depositors or interfere with redemptions.

Withdrawal delay

After a TBTC holder has confirmed a redemption transaction on the Ethereum blockchain, the signer group responsible for processing the redemption has three hours to produce either a valid signature or a redemption proof. If the signer group does not produce the required information in time, then the signer failure protocol described above is activated to make the redeemer whole.

WBTC

WBTC is the most overtly centralized/trusted implementation of a two-way peg mentioned in this overview. Deposits and withdrawals are processed by bitcoin custody provider BitGo, and users must undergo KYC/AML checks before they are authorized to mint or redeem WBTC. However, WBTC is also the most liquid version of two-way pegged BTC, both in terms of outstanding tokens minted and market depth on exchanges, so I figured it would be worth looking at and comparing against the other options.

The WBTC peg

As mentioned, the WBTC peg is secured using a fully centralized mechanism. This makes the peg relatively simple to implement compared to the other pegs in this overview. End-users simply give their BTC to BitGo, via an intermediary called a “merchant” in the WBTC network. The merchant will forward the BTC to BitGo, along with an instruction to mint an equivalent amount of WBTC. BitGo will verify the BTC transaction and mint instructions, mint an equivalent amount of WBTC, then pass the newly-minted WBTC to the merchant, who will in turn pass the WBTC to the end-user. To convert WBTC back to BTC, users simply follow the same process in reverse.

Bond, bond amount, and oracle used

Neither BitGo nor merchants in the WBTC network are bonded, although BitGo does advertise on their website that their custody solution is insured for $100 million. WBTC is backed 1:1 by BTC held in custody by BitGo, and no oracle is used or needed to enforce the peg.

Withdrawal delay

Upon submitting a redemption request to the merchant of their choice, users must wait a minimum of 25 Ethereum confirmations before they receive the expected amount of BTC from BitGo.

Post Script

Several of these two-way peg systems are guarded by nodes selected or backed by native protocol tokens e.g. PRV in Incognito, REN in RenVM, and ETH + KEEP in tBTC. In an effort to determine just how much “skin in the game” these nodes have, a more complete analysis of these protocols would look closely at how these tokens were initially created and subsequently distributed. I will leave this as a future area of inquiry and an exercise for the reader.

Acknowledgements

Thank you to Duc from Incognito and Matt Luongo from Thesis for answering questions I had about the respective protocols they are working on. Any inaccuracies remaining in this blog post are my fault alone.

Further reading

h ttps://docs.rsk.co/Drivechains_Sidechains_and_Hybrid_2-way_peg_Designs_R9.pdf

https://blog.rsk.co/noticia/syncchain-synchronized-sidechains-for-improved-security-and-usability/

https://thedefiant.substack.com/p/it-was-almost-impossible-to-keep-26b

Email is probably the most popular decentralized messaging protocol, and I expect it to be around for a while. Add yourself to my email contacts if you would like to stay in touch! I will never sell, rent, or share your email address.