On Friday, May 15, the first release of tBTC went live. On the morning of May 18, the Keep team decided to trigger the 10-day pause of deposits allowed by the TBTC System contract. The team took this action after identifying a significant issue in the redemption flow of deposit contracts that could put signer bonds at risk. No depositor funds were ever at risk, and all funds are safe. Nonetheless, we have taken the issue very seriously.

The full incident analysis, including the response timeline, is available here.

Security is our top priority building tBTC. A trust-minimized bridge from Bitcoin to Ethereum is only as valuable as users are confident.

But no team of developers, no matter how talented or hard-working, can catch every bug or follow every best practice. That’s why we’ve committed to multiple security audits, and why we built the “red lever” to enact a 10-day pause on new deposits. While the initial launch challenged us on multiple fronts, we are pleased that the precautions and safeguards we put into place served their purpose. No funds were lost, and no damage was done to any community members, depositors, or contributors. The lessons learned from the launch have led us to a new release model, allowing the team to redeploy with confidence.

All funds returned safely

Since a small number of community members had already deposited BTC while the dApp was still in testing, our team acted immediately to ensure the safety of all funds in the system, and to return them to depositors and signers. As of today, 99.83% of the supply of BTC deposits have been safely redeemed to this address.

As a result of these actions, all funds are safe.

The path (back) to mainnet

Deciding when an immutable smart contract is “ready” is difficult. Security is a continuous process, but immutable smart contracts are deployed once.

For this reason, we’re shifting to a release candidate strategy.

Release candidates are versions of software that a development team believes are “ready for prime time”- but may or may not be final, based on wider user feedback. Release candidates progress from 0, to 1, to 2, onward- until a candidate is deemed final and upgraded to the stable release.

The use of designated release candidates has a long precedent in open-source software, and was recently demonstrated successfully in the cryptocurrency space by the Celo team.

The initial tBTC release, which we’ll now call rc.0, was found to have a vulnerability — leading to the pause of new deposits. In the following weeks, we’ll deploy rc.1, a new set of contracts that include a mitigation for the vulnerability, as well as other low and medium priority issues the team has discovered.

For the foreseeable future, the dApp built atop rc.1 will remain in alpha. Eventually, the dApp will have a beta release cut, and likely remain in perpetual beta as features are added.

We believe this model is a better fit for tBTC, and more generally many smart contracts that want to avoid easy upgradeability.

A graduated supply cap

Still, deciding when to graduate an immutable release candidate to “final” is difficult. There are an infinite number of precautions a team can take, and an infinite number of potential vulnerabilities.

One way to quantify readiness is money in the system.

rc.1 will feature a hard cap on the TBTC supply, starting at 100 BTC in the first month. Each month, the contracts will loosen the deposit restriction based on a pre-committed schedule.

If at any point a critical vulnerability is found in the smart contracts, the team will push the emergency deposit pause, and coordinate a withdrawal of funds- then redeploy the patched contracts as rc.2, resetting the cap schedule.

After 5 months, the supply cap restriction will lift- and after 12 months without incident, the team will disable the emergency pause button.

This graduated supply cap gives depositors and signers a measure of the ongoing risk and confidence in a system, while protecting overly enthusiastic early users from potential issues.

Expanded security audits and bug bounty program

tBTC concluded its first security audit in March, and will continue to be tested rigorously. We have communicated the rc.0 issue and the proposed fix both to our previous auditors, ConsenSys Diligence, as well as our current auditors, Trail of Bits, for confirmation and further feedback. Further, we have adjusted the scope of the already-planned Trail of Bits audit that started on Monday, May 18th.

In addition to an aggressive focus on the Go clients in the network, the audit will now devote an equal amount of attention to the smart contracts in the system. We will be working with Trail of Bits to expand and automate more integration and system tests for tBTC, as well as to add fuzz and property testing to various components where appropriate. In all of this, we will be working with Trail of Bits to identify any additional areas of the system meriting additional scrutiny.

We are also organizing a third security audit in addition to those by ConsenSys and Trail of Bits, focused exclusively on the parts of the system involving BTC transactions and cross-chain communication. The team is in active discussions with practitioners, and will share more when the details are confirmed. We have also increased the maximum reward for the tBTC bug bounty program by 10x, to 1M KEEP, for responsibly disclosed severe vulnerabilities.

As part of our ongoing rollout of the project, the tBTC stakedrop begins June 8th as previously announced. Anyone can be rewarded in KEEP tokens for acting as good stakers on the network. Sign up here for the live event.