tBTC: A Decentralized Redeemable BTC-backed ERC-20 Token

These approaches have a few clear benefits

However, there are downsides. The most obvious is introducing a trust model incompatible with Bitcoin.

Custodians need to be fully trusted, either as a group, as in Liquid’s model, or individually, following the Wrapped Tokens model. A malicious custodian can block withdrawals and in some cases collude to abscond with funds. Custodians may also be compelled by governments, hackers, or other forces to tamper with reserves, despite their good intentions.

The biggest benefit of a synthetic Bitcoin peg is its flexibility. A synthetic doesn’t need to follow the rules governing the pegged asset, for better or worse.

For example, a synthetic might effectively "inflate" the supply of the underlying asset, which might be desirable for some financial systems- and directly fly in the face of the purpose of a currency aspiring to be hard money.

Despite the potential reuse of Maker’s network, launching such a synthetic has other risks. A synthetic peg to a volatile asset like Bitcoin, backed by a volatile, under-diversified reserve entirely of Ether, is a dangerous combination.

The tBTC system provides a mechanism for creating a token, TBTC, on a non-Bitcoin host chain (in tBTC v1, the first host chain is Ethereum), that is 1-to-1 backed by bitcoin. Parties interested in minting TBTC request that the system provide them with a Bitcoin wallet address. The system selects a set of signers, which are tasked with generating a private/public keypair and furnishing it to the system. The interested party then becomes a depositor by sending bitcoin to the wallet (the amount of required bitcoin is discussed separately in the section on lots). The deposit cannot be maintained for free, as deposits require signers to put up an ETH bond to guarantee good behavior (see the section on deposit economics). To cover these costs, the deposit is paid for by signing fees that cover a set term of deposit redemption exclusivity for the deposit owner, discussed separately in the section on the deposit term.

Each of these steps is shown in the diagram below and discussed in subsequent sections.

The starting point for acquiring TBTC is generating a deposit request. This request is a transaction to a smart contract on tBTC’s host chain, and signals that the sender requires a signing group backed wallet, mediated by a deposit. Because signing groups have an inherent creation cost, deposit requests charge a small payment in the host chain’s native token to cover the creation of the signing group. This payment can be refunded if the signing group fails to generate and publish a public key after a timeout.

Once the tBTC system has a wallet address available for a given deposit request, the depositor can broadcast a Bitcoin transaction sending BTC from a wallet they control to the wallet address for the signing group. Once the transaction has been sufficiently confirmed^[4] by the Bitcoin chain, the depositor has to issue a transaction to the host chain proving that the deposit has been funded.

The only link between the Bitcoin chain and the host chain is the tBTC system, which runs as a set of smart contracts on the host chain. As such, the Bitcoin transaction issued by the depositor has to be proven to the tBTC system before the tBTC system allows the depositor to behave as if they have successfully deposited their BTC into the signer wallet. If the signing group fails to provide a public key within a given timeout window (the signing group formation timeout), the depositor can notify the deposit that this has occurred to receive their deposit payment back, taken out of the bonds that the signers put up as part of the signing group selection process. If a deposit proof is not received within a given timeout window (the deposit funding timeout), the signing group can notify the deposit that this has occurred to disband the group and return the members' bonds.

When creating a deposit, the deposit’s lot size must be specified. The tBTC system supports a governable set of available lot sizes (see the section on Governance for more), guaranteeing only that at least 1 BTC lot sizes will be available. v1 will launch with six available lot sizes: 0.002 BTC, 0.01 BTC, 0.1 BTC, 0.2 BTC, 0.5 BTC, and 1 BTC. Deposit requesters may only create deposits in one of those lot sizes, and the lot sizes only allow minting their corresponding amount of TBTC. If a depositor wants to deposit more than the maximum lot size the system supports, they will need to create multiple deposit requests and fund multiple deposits.

For simplicity’s sake, the rest of this spec is written with the assumption that deposits of 1 BTC are being opened; however, anything dependent on lot size (such as signing fees) will be defined as a value proportional to the lot size.

Limited lot sizes with a max cap allow each deposit to be backed by a different signing group, both simplifying the bonding of signing groups and improving the resilience of the system to signing group failure, malicious or not.

The system is designed to function with a few predefined lot sizes for all deposits, which are given as system parameter. Depositors should send the exact lot amount of BTC in the funding transaction, or expect loss of funds. Since it is not possible for the system to force users into sending any specific amount, ideally the the system would gracefully handle overpayment and underpayment. The primary impact of overpayment and underpayment is on the specific deposit’s collateralization ratio. The system treats overpayment and underpayment as faulty depositor behavior, and passes on the associated costs to the depositor.

Signers aren’t altruists—they are paid for the service they provide.

Signer fees should always be paid or escrowed up front. To achieve this, signer fees must be guaranteed by minting, and deposits must have predictable lifetimes.

A detailed treatment of signer fees can be found in its own section.

Two tokens present themselves as obvious choices for signing bond collateral—TBTC and the underlying work token. During the bootstrap phase of the network, neither is an appropriate candidate due to low liquidity.

Since signer bonds need to be denominated in a widely traded asset to avoid market manipulation, the next most obvious pick for bonding is the host chain’s native token. For tBTC v1, that means ETH. As the ecosystem matures, other bond collateral options might become feasible at the expense of a more complex implementation.

Clearly, security concerns require signing bonds that are proportional to the lot size of a deposit. To maintain a negative expected value from signers colluding, the amount forfeited by misbehaving signers must be strictly greater than the amount they have to gain. Assuming a lot size of 1 BTC, constant exchange rate between BTC and the bonded asset, and a M-of-N group of signers backing a deposit, the minimum collateral for each signer is (1 BTC)/M, denominated in the asset being bonded (ETH in the base case).

The above assumes a constant exchange rate between BTC and ETH, but in truth the two currencies fluctuate relative to each other, sometimes wildly.

Unlike popular synthetic stablecoin schemes, the tBTC system design makes no effort to stabilize the value of TBTC relative to BTC: TBTC will be priced by the market. Instead, the goal is to ensure that the TBTC supply is strictly less than its backing BTC reserves.

For this reason, the only price relationship the system needs to understand is between the signing bond collateral and BTC.

For tBTC v1, that means the price of ETH relative to BTC. Due to only needing prices for a single pair of assets, tBTC will initially use a simple price feed.

A bitcoin has 8 decimal places, the smallest unit being a satoshi, meaning 100 000 000 satoshis = 1 bitcoin. An ether by contrast, has 18 decimal places, the smallest unit being a wei, meaning 1 000 000 000 000 000 000 wei = 1 ether.

To express the price of bitcoin relative to ether, we must use a ratio of the number of wei to a satoshi. A simple design is to use x wei : 1 satoshi. Hence, for a call to getPrice when 32.32 ETH : 1 BTC (Jun 2019), the value 323 200 000 000 wei is returned.

However, if 1 wei is worth more than 1 sat, then the price can no longer be accurately encoded. This scenario of a 'flippening', when 1 ether becomes worth 10,000,000,000x as much as 1 bitcoin, we find unlikely in the very short-term. Rather than prematurely optimize, incorporating a 2 integer ratio of x wei to y satoshi and changing the call semantics, we leave this as a future exercise for governance.

The price feed is integral to tBTC’s security and in the future, will be principally governed by the tBTC ecosystem. The first upgrades will focus on incorporating a novel price feed mechanism based on reverse auction challenges that has been dubbed the "priceless feed".

The process of minting TBTC is distinct from the process of depositing Bitcoin.

By splitting minting into two phases—a zero-confirmation deposit creation yielding a non-fungible token, and an additional proof enabling trade-in of the non-fungible token for fungible TBTC—we can balance strong security against reorgs with a better user experience and more flexible use cases.

A simplified view of the deposit creation, minting, and redemption flows is in this diagram:

Note that the above diagram skips a few additional possibilities explained below in this spec, including how pre- vs at-term deposits behave differently, liquidation-related changes, as well as how a depositor might keep their TDT without minting TBTC.

After a deposit has been requested and a signing group formed, a depositor immediately receives a non-fungible token unique to the deposit called the tBTC Deposit Token, or TDT, granting them ownership of the deposit. This ownership comes with the exclusive right to redeem the deposit from the moment it is funded until the deposit term is reached, unless there is an undecollateralization issue that transitions the deposit into its "courtesy call" state.

Once the deposit is fully qualified by submitting sufficient proof of the funding Bitcoin transaction, the holder of the TDT can request redemption, and, after paying any outstanding signing fees, the holder is guaranteed the same UTXO backing the deposit. The holder of the TDT is also guaranteed compensation in TBTC via the signing group’s bonded collateral in case of fraud or collateralization issues (see liquidation), and compensation in TBTC (minus signer fees) if the deposit is redeemed by another account after it reaches term (see the section on at-term redemption) or if the deposit is courtesy called.

Once a deposit has accumulated enough work, it is eligible to be traded for fungible TBTC. The contract managing this is called the "vending machine".

There are a number of pricing models that could cover the opportunity cost of signers' bonds.

A pricing floor can be derived from a related pricing model in the cryptocurrency space: today’s centralized cryptocurrency custodians charge 50 to 75 basis points (between 0.5-0.75%) on assets under custody (AUC) per year. For each year that a centralized custodian protects a bitcoin deposit, that’s as much as 0.75% lost to the costs of custody.

A decentralized model should eventually allow a lower effective fee on custody by introducing more competition to the space. There is a caveat, however—a decentralized approach to custodianship makes legal recourse more difficult, requiring additional bonded collateral to ensure recompense in case of failure.

Applying this pricing model to tBTC’s bonding, it’s clear that a signer would need to make a similar return at a minimum on the total capital it’s protecting.

For a private key x, a message M, a hash function H, and a uniformly chosen k, an ECDSA signature is the pair (r, s), where s = k (m + xr), r = R_x, R = g(k-1) and m = H(m). Intuitively, this signature can be converted to a threshold signature if k and x are calculated via secret sharing between t of n protocol participants. Gennaro and Goldfeder’s paper describes an efficient mechanism for performing this procedure. Note that a similar mechanism was proposed by Lindell at al in the same year.

Informally, the participants perform the following actions to sign a message:

A more in-depth description of the protocol can be found in Section 4.1 and 4.2 of the paper.

Currently, when Signers misbehave, all of their security bonds are seized and burned. If the system is parameterized to use M-of-N multisigs to back deposits, this means that if M parties misbehaved, the bonds of all N parties would be slashed. This is a griefing vector which we ideally would like to avoid. Accountable-subgroup multisignatures (described in Section 4 of the related paper) allow distinguishing a signature made by a subgroup S in a M-of-N multisignature from another subgroup S'. This can be leveraged to penalize only the M misbehaving signers, removing the risk of punishing honest signers.

The threshold-ECDSA protocol described in the previous section does not support fault attribution to subgroups of signers. We will deploy tBTC without that feature, and enable it in future protocol upgrades.

In this section we explore other aggregate signature schemes we may use in the future. The described techniques are secure in the plain public key model, meaning that users do not need to prove ownership of their secret key, making them attractive for usage in blockchains. We briefly describe MuSig and BLS signatures.

The system requires that critical actions like funding and redemption occur within a fixed time after request. Failure to do so is treated as an "abort." Where fraud indicates proof positive of forbidden behavior, an abort typically represents a liveness failure from some participant. As such, while aborts are still punished, and may still result in liquidation, they are not punished as severely as fraud. For example, should the signers fail to produce a redemption signature in a timely manner, their bonds are liquidated to protect the supply peg, but any remainder is returned to them once the liquidation initiator is rewarded.

Deposits represent real Bitcoin unspent transaction outputs ("UTXOs") and are redeemable for the BTC held there. The tBTC redemption system aims to provide access to those BTC via a publicly verifiable process.

So long as a deposit is maintained in good standing, the holder of the non-fungible tBTC Deposit Token may request redemption, relinquishing their NFT and paying any outstanding signer fees associated with the deposit.

At this point, the redemption process may not be cancelled.

Once redemption has been requested, the signers must produce a valid Bitcoin signature sending the underlying BTC to the requested address. After a signature has been published, any actor may build and submit a redemption transaction to the Bitcoin blockchain using that signature.

A redemption request can be submitted in a few cases:

To request redemption, a requester makes a redemption request transaction to the smart contract on the host chain. The redemption request includes the following:

Upon receipt of the redemption request, the smart contract escrows the repayment amount (which includes the signer fee, if due), records the receipt of the request, and notifies the signers that a signature is required.

Once notified of the redemption request, the signers must wait for confirmation on the host chain. If they do not wait for confirmation, the redemption request may be dropped from the chain via a reorg, in which case any signature they produced could be used to both redeem the BTC and submit a signer fraud proof. A fraud proof created this way would appear valid to the host chain smart contract because it no longer has a record of the redemption request.

Conceptually, the repayment amount is the deposit lot size plus the signer fee of 0.005 TBTC per 1 TBTC (50 basis points). This ensures that the signers are paid upon completing redemption, that the owner can be compensated for the redeemed deposit (in redemptions by parties other than the owner), and that the Fee Rebate Token holder can receive their fee rebase (in pre-term redemptions).

After all the math shakes out, the repayment amount can vary depending on the redeeming party, the TDT holder, the FRT holder, and the deposit’s term state. The Deposit payment flow table lists the various combinations that are possible, and the corresponding repayment amounts owed by the redeemer, assuming three possible parties, A, B, and C. It also lists out the relevant disbursal upon redemption proof.

A redemption transaction has a perfectly canonical format which is embedded in the smart contracts running on the tBTC host chain. This prevents a number of complex attacks on the tBTC system, as well as simplifying contract logic. The requester may specify only 2 aspects of the transaction: its fee and its destination. All other deposit-specific information (e.g. the outpoint and the UTXO value) is known to the deposit contract in advance.

The redemption transaction has 1 input (the deposit UTXO) and 1 output (the redemption output). It does not have change outputs, or additional inputs, as none are needed. It simply transfers the underlying BTC to the sole custody of the requester. Its timelock and sequence numbers are set to 0 and its version is set to 1. Full documentation of the format and the construction of its sighash can be found in the appendix.

Because the format is simple and canonical, any observer may use publicly available information to build it. Once a signature has been published, it is simple to add a witness to the transaction and broadcast it. So while signers have a strong incentive to broadcast the transaction as early as possible, anyone may do so if the signers do not.

A redemption proof is an SPV proof that a redemption transaction was confirmed by the Bitcoin blockchain. Once a request to redeem is confirmed, the deposit smart contract expects a redemption proof within 6 hours. To validate a redemption proof, the smart contract performs normal SPV proof verification, and additionally verifies that the recipient matches the requester’s specified output script, and the value is greater than or equal UTXO Value - highest allowed fee (see Allowing for Bitcoin fee adjustment for more details).

Once redemption proof is confirmed, the signing fee is disbursed, the FRT holder receives their escrowed funds (if the deposit was redeemed pre-term), and the TDT holder receives the remainder of the repayment amount. As with the repayment amount, the amount each of the parties receives in case of a successful redemption varies depending on the TDT holder, FRT holder, redeemer, and deposit state. The Deposit payment flow table lists the various combinations that are possible, and the corresponding repayment amounts owed by the redeemer, assuming three possible parties, A, B, and C.

After the redemption request is sufficiently confirmed on the host chain, the signers MUST produce a signature on the redemption transaction signature hash as requested. They have 3 hours in which to produce either a signature, or a redemption proof before being subject to penalties. Upon submission of a valid signature a redemption proof is still required, but the deadline is extended to 6 hours in total.

As discussed earlier, the host chain smart contract managing the deposit has all information necessary to calculate the redemption transaction signature hash. This includes the signers' threshold public key. Using the public key, the signature hash, and the redemption request the smart contract can know both the cryptographic validity of the signature and that a signature on that digest was requested as part of a redemption process.

Because Bitcoin fees are determined by network congestion and other highly unpredictable factors, the requester may not select an appropriate fee. Signers are punished if no redemption proof is submitted or if they sign without explicit authorization. This could create a no-win scenario for signers, in which they could not get the requester’s transaction confirmed in the current fee climate and would eventually be punished despite honest behavior. Unfortunately, we cannot rely on the requester to stay online or update fee rates honestly. Ergo, the system requires some mechanism to fairly adjust fee rates without the requester’s explicit consent.

The simplest scheme is to allow signers to increase the fee without requester consent after a timeout. As such, we allow signers to increase fees linearly every 4 hours. Which is to say, if the fee is f, after 4 hours the signers may notify the deposit contract of a fee increase to 2f and if the transaction remains unconfirmed after 8 hours, the signers may notify the contract of a fee increase to 3f. This ensures that a redemption transaction will eventually be confirmed on the Bitcoin blockchain near the minimal fee rate given current network congestion. To prevent the signers from repeatedly requesting fee increases, they must actually provide a signature at each fee level. This ensures that each feerate is actually attempted before an increase is requested.

The governance philosophy is simple: govern as few system parameters as possible. This limited view on governance means relying on social upgrades— deploying a new instance of the system—rather than governed contract upgrades.

Social upgrades are akin to hard forks. They require an overwhelming economic consensus, as a new token contract and other new contracts will need to be coordinated and agreed upon across the market. The bar for a social upgrade is much higher than other common governance paradigms, and will become even more difficult as an instance of the system ages.

The limited governance included in the system design follows a few principles:

All governance functions and delays are enumerated below. Each MUST be callable by the contract owner alone. For functions that have time delays, there is a finalize<Function> equivalent to the begin<Function> that can finalize the change after the specified delay (e.g. beginLotSizesUpdate/finalizeLotSizesUpdate).

For a BTC lot size of 1 BTC corresponding to 1 TBTC and signer fee of 0.005 TBTC (50 basis points), the following table describes the amounts disbursed to each party at redemption time for pre- and at-term deposits, depending on who holds the TDT and FRT, and who initiates redemption. Three possible parties exist in the table—A, B, and C—and the listed scenarios cover situations where the same party holds the two tokens and initiates redemption, different parties have each role, and possibilities in between.

Note that all of these scenarios can be conceptualized as the TDT holder always receiving the 1 TBTC used to redeem the deposit; when the TDT holder redeems their own deposit, the TBTC they receive would be from themselves, so they simply owe less. Similarly, the FRT holder always receives escrow back when redeeming pre-term, so in cases where the redeemer holds the FRT, the redeemer simply does not owe the signer fee at redemption time.