tBTC: A bumpy start, but a bright future?

Alex Manuskin
Zengo Wallet
Published in
7 min readMay 21, 2020

--

The tBTC platform set out on a quest for one of crypto’s most coveted prizes: connecting Bitcoin with Ethereum’s DeFi, building a bridge between crypto’s main continents, currently largely separated. however, its first iteration was very short-lived.

In this article we take a deeper look into tBTC, shedding light on the motivation behind it, dive into its inner workings, understand the root cause of current failure and finally speculate about its future.

Bitcoin and Ethereum: A game of mix and match

Bitcoin is the big tuna of the crypto world. It has the largest market cap, most users and the most liquidity ($170B currently), however not much of utility other than store of value and (“HODLing”).

Bitcoin dominance: two thirds of crypto value is in Bitcoin (source: Coinmarketcap)

On the other hand, decentralize finance (DeFi) innovation has really taken-off on the Ethereum blockchain, leveraging its smart contract functionality. DeFi protocols are gaining traction. Users can now swap, trade, lend and borrow tokens and ETH in a completely decentralized way, via smart contracts on the Ethereum network.

Nearly $1B is locked in DeFi apps (source: defiulse)

As a result, it makes a lot of sense to bring these currently separate worlds together, to allow users to earn on their bitcoin holdings in DeFi. While some solutions try to bring the mountain to Mohammed and build DeFi on Bitcoin, it seems the easier way would be to bring Bitcoin to Ethereum’s DeFi.

Bringing Bitcoin to Ethereum’s DeFi

The most notable solution so far for bridging the DeFi gap was BitGo’s WBTC (Wrapped BTC) Ethereum based (ERC20) token. On one hand, since it is an ERC20 token, WBTC holders can use DeFi services. On the other hand, WBTC token value is pegged to BTC, as it is promised to be fully backed by actual BTC. That is, for every WBTC on Ethereum, there is a BTC locked up to cover it. As a result, the goal of having a BTC-like token that can be used in DeFi is realized.

The problem with WBTC and solutions like it, is that the BTC is held on to by centralized custodians. A regular user cannot directly swap BTC for WBTC, it has to be minted by WBTC custodian first.

This is limiting, both in how many WBTC tokens can be produced, and by the fact that one has to trust in WBTC custodians to do a good job storing the actual BTC.

Miniting a centralized Bitcoin-pegged token

To mitigate these issues, the tBTC project was created.

tBTC decentralized approach

Decentralization is the main differentiator of the tBTC project developed by KEEP, as it gives any user with BTC (and some ETH) the ability to mint TBTC using a network of signers. Unlike previous solutions, there is no central custodian holding on the locked BTC. Signers are selected at random, and a different group of signers is selected for each minted TBTC. The signers provide a collateral (in ETH), which ensures they cannot simply run away with the funds.

The deposit is always over collateralized. For every 1 BTC deposited, the signers must provide 1.5 BTC worth of ETH as collateral. In exchange for locking up ETH as collateral, signers are rewarded with fees. The fees are paid at the time of redemption.

Another interesting aspect, is that the signers create a unique address using a threshold signature protocol. This means a single signer cannot escape with the funds. The cooperation of all assigned signers is required to perform an action.

All signers need to cooperate if they wish to deviate from the protocol and steal the locked BTC.

If they deviate, anyone can provide proof that the signers have misbehaved. In return, the accuser is rewarded with the signers’ collateral. Since signers’ bonds are overcollateralized, they have more to lose than gain by running away with the BTC.

Minting in TBTC:

  1. A depositor wishes to mint TBTC. They send a transaction to the tBTC platform, paying for gas to setup a deposit contract
  2. A set of signers are selected at random to hold the BTC
  3. Signers provide 150% of the BTC value (in the form of ETH) as collateral
  4. Signers create a threshold signature address and publish it
  5. The depositor sends BTC to the published address and awaits Bitcoin blockchain confirmation
  6. Once enough conformations have been received (6 blocks), the depositor proves a payment has completed and the contract can mint TBTC for the depositor
Miniting on tBTC decentralized Bitcoin-pegged token

Similarly, anyone holding TBTC can redeem it for BTC held by some group of signers. The process is similar to the minting process in reverse.

  1. The redeemer pays TBTC to the contract, and provides his BTC address, where the funds should be sent.
  2. Signers create a threshold signatures and generate a payment transaction, sending BTC to the address provided by the redeemer.
  3. Once funds are sent, signers provide a proof of payment to the contract, unlocking their ETH collateral.
Redeeming BTC from tBTC decentralized Bitcoin-pegged token

Proving a Bitcoin payment on Ethereum

The crux of tBTC solution is the ability to prove to the Ethereum based contract that a BTC payment was made. This is not trivial since Ethereum and Bitcoin are two different blockchains. The deposit smart contract needs to know if it is OK to mint TBTC to the user. In order to do that, the depositor must provide a proof that a payment to the signers has indeed been made. To do so a simplified BTC verification process (Similar to a Bitcoin SPV client, more details here) is executed by the smart contract. The depositor provides the hash of the payment, along with a proof that the payment has indeed been made on the Bitcoin blockchain, and has received 6 conformations. This proof is reliable due to the proof-of-work consensus mechanism of Bitcoin. The same proof needs to be provided by the signers during the redemption process. Only then will they be able to redeem their collateral.

The security incident

The official mainnet tBTC Decentralized App (DApp) was launched on May 16th. On May 18th, after roughly 48 hours of operation, the CEO of Keep-project announced that the team is using their one-time kill switch to shut down all deposits of BTC to the platform.

The underlying problem

The underlying problem, communicated by the Keep team in their elaborated post-mortem published on May 20th, lies in the redemption protocol.

As mentioned, during redemption, the redeemer provides a Bitcoin address, where the signers should send the BTC in their custody. Bitcoin has several versions for a valid address. Each version has a slightly different length, and prefix.

Example:

New format: bc1qngsulfgcudt8ztwv9quef9k5sv0ld2px0jh8nw

Old format: 1PPhYgecwvAN7utN2EotgTfy2mmLqzF8m3

Due to a bug in the redemption process of the contract, signers could not prove they correctly sent funds to an address of the older format.

What does this mean?

For the honest redeemer, there are no implications. The redeemer could provide any Bitcoin address, and they would receive their funds.
The problem is for the signers. When attempting to prove they have sent a payment to the redeemer, the contract would not accept the proof if the redeemer has used an old format address even if the signers acted honestly. Consequently, the system would consider the signers as rogue, for not providing proof of payment in due time. At this point, any user could come and blame the signers for malicious behaviour. As a reward, the accuser gets part of the signer’s collateral.

Once this bug is exploited ,the signers, the backbone of the protocol, are left with no BTC (as it was sent to redeemer) and no ETH (claimed by the accusers). A malicious redeemer aware of this fact could initiate many malicious redeem processes, and get away with both the BTC and the ETH.

Could this have been avoided?

It is very hard to write perfect code. It is even harder to write perfect code in the form of a smart contract that you upload only once and can never change.

The Keep team decided to not add “upgrade” functionality to the contracts, which definitely has its advantages, as well as much higher risks.Thus, they could not simply replace the contract with a new one and solve the problem for the future.The post-mortem extensively covers what could have been done as well as future plans for the team to avoid a similar fate for tBTC 2.0.

Judging by our experience having experimented with the protocol before it was officially launched, we believe the testnet DApp testing phase should have been up longer, with more extensive tests and use cases before the mainnet launch. For example, when we tried to redeem, we could not complete the process and were unable to progress past this screen

We experienced difficulties with tBTC DApp during its testing phase

Going forward

While the initial launch was certainly a failure, this is not the end of tBTC. No financial harm was done as 99.87% of TBTC were recovered and repaid to the holders (The rest is probably held as crypto history memorabilia.) and the tBTC team has done a great job communicating and maintaining transparency throughout the entire process.
The failure was due to a bug in the contract, and the system was shut down before there was time to test more complicated aspects of its operation (Price oracles, signer distribution, liquidation etc.)

Most importantly, the need and the potential is very much there. Eventually the bridger between Bitcoin and Ethereum DeFi will be established. And if tBTC will fail to do so, surely others will follow.

--

--

Alex Manuskin
Zengo Wallet

Open source | Blockchain | Making cool things work