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 two main continents which are largely separated. But the platform’s first iteration has been short-lived.
In this article, we will take a more in-depth look at tBTC. We’ll dive into its inner workings to better understand the motivations behind it, the root cause of its failure, and possibilities for the future.
Bitcoin & 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 (currently $170B), however, it doesn’t have much utility other than a store of value and (“HODLing”).
On the other hand, decentralized finance (DeFi) innovation has really taken-off on the Ethereum blockchain, leveraging its smart contract functionality. DeFi protocols are gaining traction. Users can swap, trade, lend and borrow tokens and ETH in a completely decentralized way, via smart contracts on the Ethereum network.
With Bitcoin dominating crypto in terms of market cap, the number of users and liquidity, and Ethereum leading in DeFi innovation, 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 is BitGo’s WBTC (Wrapped BTC) Ethereum based (ERC20) token. On the 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 means 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 used in DeFi is realized.
The problem with WBTC and solutions like it is that 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 one has to trust in WBTC custodians to do a good job storing the actual BTC. The tBTC project was created to mitigate these issues.
tBTC decentralized approach
Decentralization is the main differentiator of the tBTC project developed by KEEP. It gives any user with BTC (and some ETH) the ability to mint TBTC using a network of signers. Unlike previous solutions, no central custodian holds onto the locked BTC. Signers are selected at random, and a different group of signers is chosen for each minted TBTC. The signers provide collateral (in ETH), which ensures they cannot run away with the funds.
The deposit is always over collateralized. For every 1 BTC deposited, 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 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 the signers’ bonds are overcollateralized, they have more to lose than gain by running away with the BTC.
Minting in TBTC:
- A depositor wishes to mint TBTC. They send a transaction to the tBTC platform, paying for gas to set up a deposit contract.
- A set of signers are selected at random to hold the BTC.
- Signers provide 150% of the BTC value (in the form of ETH) as collateral.
- Signers create a threshold signature address and publish it.
- The depositor sends BTC to the published address and awaits confirmation from the Bitcoin blockchain.
- Once enough confirmations have been received (6 blocks), the depositor proves a payment has completed, and the contract can mint TBTC for the depositor.
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.
- The redeemer pays tBTC to the contract and provides his BTC address, where the funds should be sent.
- Signers create threshold signatures and generate a payment transaction, sending BTC to the address provided by the redeemer.
- Once funds are sent, signers provide proof of payment to the contract, unlocking their ETH collateral.
Proving a Bitcoin payment on Ethereum
The crux of the tBTC solution is the ability to prove to the Ethereum based contract that a BTC payment has been 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. For this to happen, 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 payment has been made on the Bitcoin blockchain, and 6 confirmations have been received. 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 the Keep-project announced that the team would be 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 contract’s redemption process, signers could not prove they correctly sent funds to an address in the older format.
What does this mean?
For an honest redeemer, there were no implications. The redeemer could provide any Bitcoin address, and they would receive their funds.
The problem was for the signers. When attempting to prove they sent a payment to the redeemer, the contract would not accept the proof if the redeemer had used an old format address even if the signers acted honestly.
Consequently, the system would consider the signers as rogue operators for not providing proof of payment in due time. At this point, any user could blame the signers for malicious behaviour and get part of the signer’s collateral as a reward.
Once this bug was exploited, the signers, which are the backbone of the protocol, were left with no BTC (as it was sent to the redeemer) and no ETH (as it was claimed by the accusers). Malicious redeemers aware of this fact could initiate multiple malicious redeem processes, and get away with both the BTC and the ETH.
Could this have been avoided?
It’s difficult to write perfect code. It’s even harder to write perfect code in the form of a smart contract that’s uploaded only once and can never be changed.
The Keep team decided not to add “upgrade” functionality to the contracts, which definitely has its advantages, but also much higher risks as well. This meant they could not 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.
We experimented with the protocol before it was officially launched. Judging from our experience, we believe the testnet DApp testing phase should have been up for 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 undoubtedly a failure, this is not the end of tBTC. No financial harm was done as 99.87% of tBTC was recovered and repaid to the holders. The tBTC team has also done a great job of communicating and maintaining transparency throughout the entire process.
The failure was due to a bug in the contract. The system was shut down before there was time to test more complicated aspects of its operation (Price oracles, signer distribution, liquidation, etc.)
Despite all of this, the need and potential are very much there. A bridge between Bitcoin and Ethereum DeFi will eventually be established. If tBTC fails to do so, others will surely follow.
