The Use Cases of Decentralized BTC on Ethereum

Initial Thoughts on tBTC

Bitcoin DeFi has been a dream for bitcoiners and for the crypto industry in general. Bitcoin is the most liquid, familiar, and decentralized cryptocurrency in the world. Although there are multiple pathways to bring Bitcoin into the DeFi realm, bringing Bitcoin into the Ethereum ecosystem seems like the easiest approach at the moment. Ethereum has been the home for all the major DeFi protocols; MakerDAO, Compound, and Uniswap. Using BTC within these protocols instantaneously brings more liquidity and opens the door for multiple use cases.

Understanding the potential, the Keep team recently released a 53-page spec on what can be considered, to date, the most trustless bridge to peg Bitcoin on Ethereum. The project, a 10-month joint effort between the Keep team and Summa, is called tBTC. The tBTC system builds on multiple concepts such as Multisig custody, SPV, and MakerDAO’s bonding system to build a more decentralized Bitcoin peg than the solutions we have today.

How is tBTC different?

The simplest way to create a Bitcoin peg in Ethereum is to deposit BTC into a trusted-party wallet and the trusted party will issue an ERC-20 token representing the pegged BTC. This is exactly how WBTC works. Users deposit BTC to BitGo, Kyber or other project partners, and get issued WBTC on the Ethereum blockchain. Though the design is simple, the counterparty risk is high. If any WBTC issuers are hacked or lose access to their BTC wallet, the issued WBTC has no backing. Additionally, there’s a limited number of possible custodians, only trusted brands can be a custodian in the WBTC system.

The tBTC system solves these two issues, i.e., the need for trusted entities and the counterparty risk, by borrowing the concept of native bonds from MakerDao. Simply speaking, any person or entity can be a custodian for BTC backing if they deposit a bond in the Ethereum blockchain that is higher in value than the custodied BTC. The provided bond removes the trust, i.e, centralization, requirement and also minimizes the counterparty risk. If the custodian, aka “Signer” in the tBTC system, becomes insolvent, the provided bond will be used to make BTC depositors whole.

Another advantage of the tBTC system comes from the use of multisig wallets. Each BTC deposit is secured not by a single custodian, but by a group of custodians. The system randomly selects a group of signers who collectively create a multisig wallet that is used to custody the deposited BTC. The funds in the wallet cannot be moved unless a threshold of signers agree to move the funds. If suspicious movement of custodied BTC is detected, anyone can submit a fraud proof and cause the associated signers to be liqiuidated and penalized.

What Are The Weaknesses of The tBTC System?

1. Price Feed Oracle

Bond-based pegging systems such as tBTC need a way to know the price of the bonded asset to ensure the bond value is higher than the custodied BTC. This is known as the price oracle problem.

The tBTC system would initially support BTC as a bond asset and require an appropriate overcollaterization. Hence, the price oracle needs to frequently update the ETH-BTC price to make sure the bond is always at least 1.5x of the value of custodied BTC. The oracle problem is one of the hardest problems to solve. MakerDAO’s solution, that is also used in tBTC, depends on a number of trusted accounts, Price Feeds, to report on the bond asset price periodically or when a change of 1% or more occurs in the asset price.

This approach for implementing the price oracle introduces an element of centralization and a need for trust in the price feed accounts. For example, these accounts may collude to submit a wrong price, cause Signers to get liquidated for under collateralization, and earn liquidation rewards. The limitations of this design of the price oracle has spurred interesting discussions on alternative ways to implement the oracle. Solutions like descending price auctions or time-limited order books could be viable alternatives to the feed-based price oracle.

2. Multisig Gaming Risk

Another weakness in the current tBTC spec is that in cases of liquidation, a majority of the BTC deposit transaction signers can steal the BTC deposit.
The tBTC system doesn’t, and probably cannot, protect Signers from this attack vector. The spec states: “What the unresponsive signers do with the BTC outside the tBTC system design is for them to decide — it might be split up, stolen by a signing majority, or lost permanently”

For example, let’s consider a deposit of 1 BTC in a 3-of-5 multisig. The tBTC system requires each Signer to deposit an ETH pond equivalent to ⅓ BTC. The collateralization ratio, in this case, is ~ 166% or equivalent to 1.66 BTC. If the bond value suddenly drops to 1.5 BTC. The majority of signers ( 3 in this case) can steal the whole deposit (1 BTC) and effectively avoid any losses from the liquidation process.

To avoid this problem, the first version of tBTC will require n-of-n signatures, i.e., all the signers need to agree to spend the transaction. In addition, a Courtesy call goes to Signers who are at risk of liquidation to urge them to redeem the deposit before it is force-liquidated.

In conclusion, the released tBTC spec is an initial draft and there is a significant room for improvement regarding the system’s decentralization and security. Generally, the topic of chain interoperability is getting increased traction and the quality of projects in this area is significantly improving.

This article was initially published as part of the free Token Daily newsletter. For updated regular insights subscribe to the newsletter below.