Prior Work

Prior efforts toward a cross-chain Bitcoin peg are well-known. A Bitcoin peg is desirable for sidechains- functionality and scalability extensions to the conservatively upgraded main Bitcoin blockchain. Due to early interest in sidechains, a number of pegged Bitcoin approaches predate Ethereum.

Centralized, Provable, Redeemable

Two solutions in the wild today provide centralized pegs that rely on trusted third parties based on variants of the "federated peg" model.

In a federated peg, a multi-sig wallet is used to lock up bitcoins. Another blockchain then issues tokens representing those bitcoin. The signers of the multisig on the Bitcoin chain are expected to validate the sidechain, and only allow issued tokes to be burned in exchange for bitcoin withdrawals following the rules of the sidechain.

Liquid, a sidechain developed by Blockstream, is an inter-exchange settlement network based on a federated peg sidechain. Bitcoin is locked in a 15-signer multi-sig wallet comprised of exchanges and Liquid participants pre-vetted by Blockstream. These signers validate the sidechain in an approach the team calls "strong federation", where a majority vote to sign blocks, and agree to approve exits to the main chain.

WBTC is a Bitcoin-backed ERC-20 token using a similar approach. The token is part of a greater effort called "Wrapped Tokens".

Wrapped tokens follow the centralized model, but instead of relying entirely on one institution, they rely on a consortium of institutions performing different roles in the network.

— the Wrapped Tokens whitepaper

The WBTC consortium votes on adding and removing custodians that manage the token’s Bitcoin reserves. Each custodian operates a multi-sig Bitcoin wallet, with control of all keys. Custodians are able to move custodied bitcoin at will, and are responsible for minting WBTC on Ethereum.

Together, the custodians act similarly to a traditional federated peg. Instead of requiring a majority to sign Bitcoin withdrawals, however, a single member can withdraw their share of the Bitcoin reserves at any time.


These approaches have a few clear benefits

  • They each effectively peg Bitcoin on other blockchains.

  • Backing reserves are easily audited on-chain at any time.

  • Both are simple mechanisms, lowering the chance of operational failure as well as the total cost to operate.

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.

Decentralized, Synthetic, Irredeemable

An alternative approach to a centralized peg is to create a decentralized synthetic asset.

One approach that’s been popular on Ethereum is Maker’s Dai stablecoin.

Dai is a token synthetically pegged to the US dollar. Ether is locked up in reserves, which, coupled with a robust price feed and a number of stability mechanisms, allow for maintenance of the peg under adverse conditions.

While Maker hasn’t launched a Bitcoin synthetic, the same network maintaining Dai’s peg could easily be applied to maintain a similar Bitcoin product.


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.

Design Goals

The goal of TBTC is the creation an ERC-20 token that maintains the most important property of Bitcoin- its status as "hard money".

To maintain the "hard money" status of its backing BTC deposits, TBTC must remain

  • Censorship and seizure resistant, across friendly and unfriendly jurisdictions

  • Inflation-resistant. TBTC may only be minted after proof is provided of a backing BTC deposit.

  • Leverage-resistant. The existence of TBTC shouldn’t let a Bitcoin holder

  • Without middlemen, in the same sense as Bitcoin. The only rent extraction should be from the minimal participation of signers required to secure the network, similar to miners on the Bitcoin network.

Finally, TBTC must be redeemable. The ability to trade scrip for its backing deposit freely is what distinguishes a backed currency from fiat money.

Developing Intuition: A simple single-signer protocol

To understand how we might develop a protocol and token that satisfies those requirements, it’s useful to consider a simple, under-specified variant that could theoretically do the job.

Imagine an off-chain actor, which we’ll call Signer, an Ethereum smart contract that implements the ERC-20 interface, PeggedBitcoin, with ticker PBTC, and another contract with the permission to mint and burn PBTC called PeggedBitcoinReserve.

Another off-chain actor, Depositor, wants to mint a token on the PeggedBitcoin contract. Depositor requests the PeggedBitcoinReserve accept a 1 BTC deposit. PeggedBitcoinReserve waits for Signer to acknowledge and return a new BTC address, as well as depositing 150% collateral of the deposit’s value in ETH into the PeggedBitcoinReserve. Depositor deposits 1 BTC into the new BTC address, and provides proof to PeggedBitcoinReserve - which in turn mints 1 PBTC, sending 0.99 to Depositor and .01 to Signer for the convenience.

Withdrawals happen in reverse- any participant can send 1 PBTC to PeggedBitcoinReserve with a Bitcoin address. Signer pays that Bitcoin address 1 BTC minus any transaction fees, and provides proof of payment to PeggedBitcoinReserve, which burns the remaining 1 PBTC, maintaining a 1:1 backing of PBTC. Signer is now free to withdraw the corresponding collateral from PeggedBitcoinReserve.


While this simple design is attractive, it’s skipped over some of the more difficult issues- efficient Bitcoin proof of payment validation on the EVM and a reliable price feed implementation, for example.

It’s also based on a deeply insecure custody solution.

First, the protocol relies on a single signer. If the value of deposits ever exceeds the value of the collateral Signer has put down, there’s nothing stopping Signer from walking with the BTC. Signer can also decide or be coerced to censor particular withdrawals, removing any hope of censorship or seizure resistance.

Second, the protocol relies on a single hot wallet. As the market cap of PBTC conceivably grows, the risk due to hacking that wallet increases tremendously.

Finally, the protocol does nothing to localize failure. If there’s an issue with a single deposit or withdrawal, it could impact the entire PeggedBitcoin supply, blocking all further deposits and withdrawals.

System Architecture: Designing a robust multi-wallet multi-signer protocol

The rest of this document is devoted to specifying a protocol that addresses those flaws, providing a robust BTC-backed bearer asset on Ethereum.

At a high level, that means the protocol described must

  • have a multi-wallet architecture

  • with many geographically distributed signers

  • that removes single points of failure

This protocol must also counter the secondary effects of these requirements and the details we skipped in the single signer example, including multi-signer payment, a more complex bonding system, an approach for detecting and dealing with undercollateralized signers, a Bitcoin proof system, and robust handling of failures on both chains.

Some components necessary to this protocol are described outside this document and will be assumed. In particular, we assume the existence of

  • a well-distributed work token for signer selection

  • a random beacon for signer selection

  • an efficient distributed key generation protocol on the secp256k1 curve

  • an efficient multi-party threshold ECDSA protocol on the secp256k1 curve

all of which are implemented by the Keep network.

The architecture is broken down into

  • Deposits and signer selection

  • Bonding and price feeds

  • Custodial fees

  • Signing

  • Wallet failure

  • Redemption



tBTC provides a mechanism for creating a token, TBTC, on a non-Bitcoin host chain, that is 1-to-1 backed by bitcoin. Parties interested in minting TBTC request that the tBTC 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 bitcoin that is sent to the wallet is in two parts: one is eligible for 1-to-1 minting into TBTC, while the other is reserved as incentive and collateral for the wallet signers.

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

initiate deposit

Deposit request

The starting point for acquiring TBTC is generating a deposit request. This is a transaction to a smart contract on tBTC’s host chain that informs the tBTC system that the sender account is interested in creating a tBTC deposit. The transaction is a signal that the sender is interested in a signing group to back a wallet that will receive bitcoin from a wallet the sender controls, in order to produce TBTC. Because signing groups are not free to create, deposit requests include a small bond in the host chain’s native token to cover the creation of the signing group. The bond is refunded when a successful deposit is made to the generated wallet.

Signer selection

Once the deposit request is received, the signing group is created by randomly selecting a set of signers to back a Bitcoin wallet. This is a multi-part process described in the diagram below.[1]

signing group creation

When a request comes in to create a signing group, the tBTC system requests a random seed from a secure decentralized random beacon.[2] The resulting random seed is used to randomly select signing group members from the eligible pool of signers. Finally, these signers coordinate a distributed key generation protocol that results in a public ECDSA key for the group, which is used to produce a wallet address that is then published to the host chain. This completes the signer selection phase.


Before the selected members of a signing group can perform distributed key generation, they must agree to become members of the signing group by putting up a bond in the native token of the host chain. This bond is used to penalize the members of the signing group if an unauthorized piece of data is signed by the signing group once distributed key generation is complete; it is also used to penalize a given member if the distributed key generation fails due to an attributed misbehavior of that member.

Bonding is described in more detail in its own section.

Distributed key generation

Some small notes about the distributed key generation a signing group undergoes. The distributed key generation protocol should result in three properties:

  1. The signing group as a whole should have an ECDSA public key, which will be shared on the host chain and will correspond to the Bitcoin wallet owned by that signing group.

  2. Each member of the signing group should have a threshold ECDSA secret key share, which can be used to create a threshold ECDSA signature share for any transactions involving the signing group’s wallet.

  3. Each member of the signing group should be able to combine a threshold number of signature shares from itself and other members of the group to produce a signed version of a given transaction to be performed on behalf of the signing group.


Once the tBTC system has a wallet address available for a given deposit request, the depositor can issue a Bitcoin transaction sending BTC from a wallet they control to the wallet address for the signing group. Once the transaction has been confirmed, the depositor has to issue a transaction to the tBTC system’s host chain proving the deposit has occurred.

Proof of deposit

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 custodial wallet. To prove this, the depositor constructs a transaction for the host chain that provides proof that the transaction was accepted on the Bitcoin chain and has had sufficient work built on top of the block that included the deposit transaction.

When a deposit proof is accepted by the system, the deposit bond is refunded to the depositor. If a deposit proof is not received within a given timeout window, the signing group will disband and the system will seize the bond’s value, making it available to the signing group members to reclaim.


Deposits will be managed in fixed-size lots. Each deposit therefore will have to be of the same amount: 0.1 BTC. Thus, a depositor submitting their proof of deposit must prove that they deposited 0.1 into the deposit’s signing group wallet. If a depositor wants to deposit more than the lot size, they will need to create multiple deposit requests and fund multiple deposits. This allows 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.

TBTC Minting

Once a deposit has been made and funded, the corresponding TBTC are minted. The custodial fee rate coupled with the minimum custodial lockup period determines how much TBTC is immediately available for withdrawal by the depositor, who is now the owner of a funded Deposit.

A custodial fee rate of 1% a year with a minimum custodial lockup period of 1 year would immediately enable 99% of the Deposit to be withdrawn as TBTC.

Custodial fees are described in more detail in their own section.


Because signers are able to collude to censor withdrawals or abscond with funds, a bond is required per deposit from each backing signer.

Unlike the staked work tokens used to choose signers, signer bonds need to be a liquid asset with a large market cap. This restriction increases the cost of market-based attacks, where the price of bonded collateral can be pushed up or down by market manipulation.

Bonded signers offer depositors recourse in the case of colluding signers interfering with operation. A signing group that doesn’t sign within a timeout forfeits their bond; a signing group that provably signs unauthorized material forfeits their bond, and risks their work token stake.

Acceptable collateral

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 the initial release of tBTC, that means ETH. As the ecosystem matures, other bond collateral options might become feasible at the expense of a more complex price feed implementation.

Measuring security

Clearly, security concerns require signing bonds that are proportional to the size of a Deposit. To maintain a negative expected value from signers colluding, the amount forfeited by a misbehaving signer must be strictly greater than the amount they have to gain.

In the case of n-of-n wallets backing each Deposit, the minimum collateral from each signer is ethValue(btcDeposit)/n. In the general case of an m-of-n wallet, the minimal set of signers required to collude is m, suggesting that each signer should bond ethValue(btcDeposit)/n*(n - m + 1).

Pricing currency fluctuations

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

If the value of ETH drops precipitously relative to BTC, a group of malicious signers will realize that the expected value of theft of the BTC collateral they protect outweights the cost of loss to their bonds. For this reason, the value bonded by each signer requires a multiple on the minimum. If the value of ETH crosses a security threshold, open Deposit s will enter Undercollateralization.

This threshold will be determined by the contract owner.

If the value of BTC drops precipitously, signers won’t make the return on their bonded capital that they’d hoped-- as Custodial Fees are denominated in TBTC. This doesn’t pose a problem for tBTC reserves, but is expensive to signers, lessening their value proposition.

At a certain threshold, a Deposit whose BTC collateral has devalued will move into a variant of the pre-liquidation phase that allows bond rebalancing without the fallback of signer bond forfeiture.

This threshold will also be determined by the contract owner.

A resilient price feed

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.

In concrete terms, that means the price of ETH to BTC. Due to only needing prices for a single pair of assets, tBTC will initially use a simple price feed based on MakerDAO’s Medianizer.


Pre-liquidation: the "danger zone"

At the first threshold, a Deposit enters pre-liquidation.

Pre-liquidations gives live signers an opportunity to rebalance bonds by opening a new deposit. A new deposit request totalling the backing BTC collateral less custodial and BTC tx fees is issued, and the resulting payment request is used to construct a withdrawal. On proof of deposit, the undercollateralized Deposit is closed and the signing bond returned. They’re paid out their earned custodial fees minus the tx fee.

At any time during this process, changes from the price feed can move the Deposit out of pre-liquidation. If no new Deposit is funded within a time window, or the signing collateral continues to devalue, the Deposit moves into liquidation.


At some point, either because signers didn’t produce a valid signature to move Deposit funds, or because the value of the signing bond continued to quickly decline, signers' bonded funds will be forfeit.

Forced Deposit liquidation favors the Deposit owner, first, as they are losing access to their BTC collateral and the benefit of a guaranteed withdrawal.

The owner is given a time window to return all withdrawn TBTC. If they do so, the owner receives all signing bond collateral.

If the owner doesn’t exercise this option, an auction begins. The purpose of the auction is to lower the TBTC supply, excluding the now-unprotected BTC collateral from the reserves.

  1. Any unwithdrawn TBTC is exchanged pro rata for its portion of the bond, which is set aside for the Deposit owner.

  2. The remaining signing bond is put up for auction for TBTC.

  3. The best TBTC bid larger than a minimum bid of the outstanding TBTC within the auction’s time window wins. If no such bid is made, signers forfeit progressively more of their backing work token, and the signing bond plus the additional work token funds seized are put back up for auction.

  4. All TBTC, including funds unwithdrawn by the Deposit owner, custodial fees earned by signers, as well as the proceeds of the auction, are burned, up to a ceiling of the TBTC surplus. If any TBTC is left over after, it’s given to the Deposit owner.

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.

Custodial Fees

Signers put their own funds at risk to assure depositors there will be no foul play. The bonds they put down are capital that could otherwise be productive, and need to earn a return relative to the risk to remain competitve with other opportunities.

Paying for security

There are a number of pricing models that could cover the opportunity cost of signers' bonds. An adjacent space offers a strongly aligned pricing model.

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’s 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 like to make a similar return on the total capital it’s responsible for-- its portion of Deposit security. In the full threshold case, that’s 1 / min(m, n) in deposit security, or 1 / m as m is less than n, with m signers are required to move funds. Those m signers would each require 1 / m * OverCollateralizationFactor in bonds, assuming for a moment a shared value currency.

For a few conservative values, n = 20, m = 15, OverCollateralizationFactor = 150%, LotSize = 1 BTC, a single signer can make .0005 TBTC a year per deposit. For depositors, that costs 1.5% a year. Lowering single-signer returns from 0.75% to 0.25% across the security value they provide means total signing revenue is 0.5% of the market cap of TBTC each year, with a return a year of their locked up capital, denominated in TBTC.

While these returns are reasonable relative to their risk in the cryptocurrency space, we can save both sides money through a more efficient use of capital. As the network matures, these costs can be lowered through the introduction of leveraged bonds.

Deposit ownership and maintenance

A minimum custodial deposit is set aside from the initially available TBTC of each Deposit. This withheld balance ensures signers will be paid for their work as time goes on.

Over time, the custodial deposit is earned by signers, who will be paid for their efforts when the Deposit is redeemed. A portion of the unwithdrawn minimum custodial deposit must be maintained at all times for a Deposit to be in good standing.

A deposit owner can maintain their Deposit by returning TBTC, or by leaving a larger balance undrawn.

Deposit s that fall out of good standing will be put up for auction, potentially forfeiting a deposit owner’s remaining custodial deposit. More details can be found in Handling Failure.


Threshold ECDSA


Future Signature Schemes

  • Schnorr

  • BLS

Handling Failure


  • Foreclosure and deposit auctions


  • Withdraw deposit?

  • Recollateralize

  • Auction off bond for TBTC

Aborts / Liveness



Deposits represents real Bitcoin unspent transaction outputs ("UTXOs") and are redeemable for the BTC held there. The tBTC redemption system aims to provide a deposit’s owner access to those BTC via a publicly-verifiable process. To support this goal, the redemption flow has been designed such that any actor may perform its critical actions (with the exception of producing signatures).

So long as the deposit is maintained in good standing, the deposit owner may request redemption. To do so, the owner must repay any outstanding TBTC (plus accrued custodial fees) and provide their Bitcoin payment details. 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.

The Value of Deposit Ownership

Because ownership of a deposit is required to redeem the underlying BTC and deposits are scarce, it follows that deposits have some value. While the market will price the redemption right, it is easy draw firm bounds around deposit value. Intuitively, a deposit’s value is the equity in the deposit, plus the value of the redemption right. Because a deposit’s custody fee schedule is predictable, we can establish a simple framework for determining the equity of a given deposit, which serves as a lower bound on its value.

The equity of a deposit is given by the equation

  • equity = maximum_TBTC_issuance - withdrawn_TBTC - accrued_fees.

The accrued_fees are calculated via simple interest:

  • accrued_fees = maximum_TBTC_issuance * daily_custodial_feerate * elapsed_custody_days

Ergo, for a deposit issuing a maximum of 1 TBTC with a custodial fee rate of 0.0027% per day (1% annually) from which 0.7 TBTC have been withdrawn, the equity after 180 days will be calculated as follows:

  • equity = 1 TBTC - 0.7 TBTC - (1 TBTC * 0.0027% * 180 days)

  • equity = 1 TBTC - 0.7 TBTC - 0.00486 TBTC

  • equity = 0.29514 TBTC

We calculate the equity value in TBTC here, because the purchaser of a deposit stands to gain TBTC. Should the price of TBTC fall relative to the price of BTC the real value of the equity drops too. However, the value of the redemption right should see a corresponding increase in value, as the redemption right for fully-withdrawn deposits becomes cheaper to exercise (as it becomes cheaper to purchase and burn TBTC in order to get the underlying BTC).

Redemption Requests

If the deposit is in good standing (has at least 0.5% equity), and 1 year has elapsed since the deposit was created, the owner may request redemption. To do so the owner makes a redemption request transaction to the smart contract on the host chain. The redemption request includes the following:

  1. A fee amount

    • must be >=2345 satoshi (~20 satoshi/vbyte)

  2. A public key hash (PKH) for BTC delivery

    • the 20-byte hash160 of a public key belonging to the requester

    • for security and privacy, this should be a new keypair

  3. Sufficient TBTC to bring the deposit to 100% equity

Upon receipt of the redemption request, the smart contract burns the provided TBTC, 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.

Redemption Transaction Format

A withdrawal 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 supply peg, 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 size) 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 deposit owner. 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 TODO: document and link.

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.

Redemption Proof

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 {:redemption-proof-timeout}. To validate a redemption proof, the smart contract performs normal SPV proof verification, and additionally verifies that the recipient matches the requester’s pulic key hash, and the value is greater than or equal UTXO Size - highest allowed fee (see Allowing for Bitcoin Fee Adjustment for more details).

Validating a Signature

After the redemption request is sufficiently confirmed, 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 12 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 it was created by request of the deposit owner.

Allowing for Bitcoin Fee Adjustment

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 creates 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 , 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.


Deposit and redemption state machine

deposit state machine

Funding Flow


This is the process to set up a deposit, and fund it with BTC. Upon successful funding, the funder will own and new Deposit and will be able to create new TBTC. To start the funding process, a funder places a small bond, and requests creation of a new keep to custody BTC. If a new keep is successfully formed, the Keep contracts notify the Deposit of the signing group’s public key. If keep setup fails, the funding process is aborted.

Once a keep is formed, the funder transfers BTC to the keep’s pay to witness public key hash (p2wpkh) address. This BTC becomes the underlying collateral for the new Deposit. The funder proves deposit via a stateless SPV proof of inclusion in the Bitcoin blockchain. If the funder fails to make this transfer in a timely manner, the funding process is aborted and the funder’s keep bond is forfeit.

Once BTC collateralization has been proven, the Deposit becomes active. Then the funder may withdraw TBTC, up to the amount of BTC collateral (less the minimal custodial deposit). The funding process can only result in an active Deposit or an abort state.

  • Deposit does not exist yet

  • The funder has placed a bond, and requested a signing group

  • The Keep contracts must select a signing group or return failure

  • A signing group has been formed, and their public key hash returned

  • The funder MUST return a SPV proof of funding before a timeout

Reachable exterior states

    • via a timeout in AWAITING_SIGNER_SETUP

    • via a timeout in AWAITING_BTC_FUNDING_PROOF


    • via provideBTCFundingProof

Internal Transitions
  • Anyone may put up a bond requesting a new signer group be formed

  • access control

    • anyone

  • writes

    • addres owner

  • from

    • START

  • to


  • Keep contract (or anyone else after a timer) notifies the deposit ath signer group setup has failed (or at least not proceeded in a timely manner)

  • access control

    • Keep contracts

    • anyone (after a timeout)

  • from


  • to


  • Keep contract notifies the Deposit of its signing group’s public key

  • access control

    • Keep contracts

  • args

    • bytes _keepPubkey

  • writes

    • bytes keepPubkey

  • from


  • to


External Transitions
  • Funder (or anyone else) provides a proof of BTC funding for the Deposit

  • access control

    • Anyone

    • expoected: Deposit owner

  • args

    • bytes _tx

    • bytes _proof

    • uint _index

    • bytes _headers

  • writes

    • uint256 utxoSize

  • from


  • to

    • ACTIVE

Redemption Flow


This is the process to redeem a deposit. Once started, redemption cannot be cancelled, except by proving signer fraud. Cancellation is impossible because as soon as redemption is requested the signers are permitted to sign, and a signature (even one neither chain knows about) can’t be revoked.

Ergo, cancellation of this process could result in BTC moved from the signers' address, and an Active Deposit with TBTC outstanding. This would result in a supply peg-break.

The requester notifies the Deposit of the bitcoin tx information (fee and recipient pubkeyhash) they are requesting, along with enough TBTC to cover the outstanding TBTC from the Deposit (counting any existing equity).

  • A withdrawal has been initiated by the Deposit owner

  • The signers MUST sign a digest

  • The signers may return the signature for verification

  • NOTE: there is a disincentive to return a signature, as the caller must pay for ecrecover gas and storage slot updates (to transition states).

  • The signers has returned a valid signature on the message

  • The signers MUST provide a settlement proof

  • In happy cases, we may skip the this state entirely.

Flow reachable from

    • via requestWithdrawal

Reachable exterior states

    • via an ECDSA or BTC fraud proof

    • via a state timeout


    • By providing a valid proof showing payment to the requester

Internal Transitions
  • signers provide a valid ECDSA signature under their pubkey

  • access control

    • Anyone

    • expected: 1 or more signers

  • args

    • bytes _signature

  • reads

    • address signersThresholdKeyAccount

    • bytes32 requestedDigest

    • uint256 withdrawalRequestTime

  • from


  • to


  • Explicitly allow a new signature with an increased fee. The fee may increased in linear steps over time. The new fee must be explicitly authorized by the contract, and the authorizing tx confirmed, before a new signature is created. To prevent bad behavior, signers must provide a signature at each fee level well before the next increase is available.

  • access control

    • Anyone

      • after a timer

  • args

    • uint256 _newFee

  • reads

    • uint256 initialWithdrawalFee

    • bytes requesterPKH

    • uint256 block.timestamp

  • writes

    • uint256 withdrawalRequestTime

      • rewrite this time to give signers a time extension

  • from


  • to


  • signers provides a valid Bitcoin SPV Proof of payment to the requester

  • access control

    • Anyone

    • expected: 1 or more signers

  • args

    • bytes _bitcoinTX

    • bytes _merkleProof

    • bytes _bitcoinHeaders

  • reads

    • bytes requesterPKH

    • uint256 oracleDifficultyReq

    • uint256 depositSize

    • uint256 fee

  • writes

    • mapping(address ⇒ uint256) balances

      • on TBTC ERC20 Contract

      • 1 time for each signer

      • 1 time for the deposit contract

  • from



  • to


External Transitions
requestWithdrawal (inbound)
  • Deposit owner requests a withdrawal

  • access control

    • only deposit owner

  • args

    • uint256 _fee

    • bytes _requesterPKH

  • reads

    • address depositOwner

  • writes

    • uint256 initialWithdrawalFee

      • the requested withdrawal fee

    • bytes requesterPKH

      • the bitcoin hash160 pubkeyhash to which to deliver BTC

    • uint256 outstandingTBTC

      • check that the `Deposit’s TBTC has been returned

      • this is a derived attribute from UTXO size and equity

    • uint256 withdrawalRequestTime

      • start timeouts for signers wrt signing and withdrawal

    • mapping(address ⇒ uint256) balances

      • change requester balance on TBTC ERC20 Contract

    • uint256 totalSupply

      • change total supply (burn) on TBTC ERC20 Contract

  • from

    • ACTIVE

  • to


provideECDSAFraudProof (outbound)
  • access control

    • anyone

  • from



  • to


provideSPVFraudProof (outbound)
  • access control

    • anyone

  • from



  • to


notifyRedemptionProofTimeout (outbound)
  • access control

    • anyone

  • from


  • to


notifySignatureTimeout (outbound)
  • access control

    • anyone

  • from


  • to



Host chain

The chain on which TBTC is managed


Secure multiparty computation setups powering tBTC signing


Public key hash

Random beacon

A secure, verifiable source of randomness accessible on the host chain

Cross-chain communication
Consensus relay

Chain-tracking SPV on some other chain, e.g. BTCRelay. Consensus relays are long-running cross-chain mechanisms that track the consensus state of another chain. They’re distinguished from other uses of the term "relay", eg the "threshold relay" random beacon mechanism.


Simplified payment verification

Stateless SPV

Non-chain-tracking SPV

Bitcoin & friends

Pay to (witness) public key hash


Pay to (witness) script hash


Bitcoin signature hash algorithm

BIP 143

Adopted SegWit sighash proposal


Sighash mode committing to ALL outputs and ALL inputs


Sighash mode committing to ONE output and ALL inputs


Sighash modifier. Changes ALL or SINGLE to commit to only ONE input

SACP, singleACP



Bitcoin hash function rmd160(sha256(message)). Used for PKH commitments in outputs. Used for SH commitments before segwit


Bitcoin hash function sha256(sha256(message)). Used for txids, sighash, merkle trees, and PoW


(unspent) transaction output

Weight unit

a measure of bitcoin transaction size. Main transaction info is 4 weight units per byte. Witness info is 1 weight unit per byte


4 weight units


A 36-byte string that uniquely identifies Bitcoin UTXOs. It consists of the creating transaction’s tx_id as a 32-byte LE uint256 (because Satoshi was bad), and a 4-byte LE uint32 denoting the UTXO’s position in the creating transaction’s output vector

1. The tBTC system participates in fairly limited fashion here, mostly coordinating work done in a secondary system responsible for managing the secure random number generation, private data storage, and multiparty computation needed to provide the system’s relevant security properties. In this diagram, that role is fulfilled by the Keep network, described in its whitepaper. The Keep Random Beacon is described in more detail in the Keep Random Beacon yellowpaper.
2. A system is only as decentralized as its most centralized component, so the beacon must be decentralized to achieve proper decentralization of the tBTC system as a whole.