Naming

Important to note that tBTC – lowercase "t" – is the name of the network/protocol. TBTC – uppercase "T" – is the name of the Bitcoin-backed token on Ethereum.

In the whitepaper the authors often use "host-chain" to refer to the chain upon which TBTC will be minted and used. My suspicion is this is because the authors hope to expand the design for other cross-chain bridges in the future. For concreteness in this walkthrough I've replaced "host-chain" with "Ethereum".

Prior Work

A Bitcoin peg on Ethereum is desirable because it provides sidechain functionality and scalability extensions. This has been known for a long-time and is a mainstay-concept in the Bitcoin world.

Bitcoin pegs are mostly useful because the Bitcoin network upgrades itself much more slowly than the Ethereum network. There are all sorts of amazing things happening on Ethereum – namely DeFi – which Bitcoin complements.

There have been 2 main approaches to Bitcoin pegs in the past—

• Centralized, Provable, Redeemable
• Decentralized, Synthetic, Irredeemable

Centralized, Provable, Redeemable

This approach is based on the "federated peg" model. With this approach, a multi-sig Bitcoin wallet locks up bitcoins. Another blockchain then issues tokens representing those bitcoins. And then the multi-sig signers validate the sidechain.

Thus far we've seen 2 main solutions emerge.

The first is Liquid, a sidechain developed by Blockstream. Liquid is a network of settling payments between exchanges. In this solution, Bitcoin gets locked up in multi-sig wallets with 15 signers. The signers are made up of participants which have been evaluated by Blockstream. Signers vote to approve blocks and approve exits back to Bitcoin.

The second is WBTC. WBTC uses a similar approach to Liquid, called a "wrapped token". WBTC is a Bitcoin-backed ERC-20 token. The organization behind it follow a centralized consortium model. The consortium votes to add and remove custodians of BTC reserves. These custodians in turn operate a multi-sig Bitcoin wallet, of which they control all keys. Custodians can move the deposited bitcoins and are in charge of minting WBTC on Ethereum.

Trade-offs

This model has its benefits in that it works. It's easy to audit on-chain reserves and operating the model is simple – it's unlikely to fail.

However, it has critical drawbacks. It simply requires too much trust in the centralized custodians. Custodians have the power to block withdrawals and collude to steal reserves. They could also easily be forced to mess with the underlying reserves by powerful off-chain actors such as governments and hacking groups.

Decentralized, Synthetic, Irredeemable

The main alternative is a decentralized synthetic asset. The most popular example of this is MakerDAO's Dai stablecoin. Dai is synthetically pegged to the US dollar, holding ETH in reserves. This design could easily be applied to creating a Bitcoin synthetic.

Trade-offs

This model has the advantage of being very flexible, but is risky and breaks some of Bitcoin's most sacred values. For example, a synthetic could inflate the supply of the underlying Bitcoin. There's also major risk in creating a synthetic which is pegged to a volatile asset in BTC, and which is backed by another volatile asset in ETH.

Design Goals

tBTC's main goal is to create an ERC-20 token which maintains Bitcoin's hard money status.

tBTC needs to be—

• censorship-resistant
• inflation-resistant
• minimal supply-side value loss – as efficient as possible
• always redeemable – 1 TBTC should equal to 1 BTC. Depositing 1 BTC to tBTC should remove that BTC from the circulating supply of BTC. If you want to get your BTC back, you should be able to do it immediately.

Unlike stablecoins, no artificial price peg is needed. There just needs to be a supply peg between Ethereum and Bitcoin.

Developing Intuition: A Simple Single-Signer Protocol

In order to understand the tBTC model as a whole, it's good to take a simple, naive version as an example.

The simple system is made up of an off-chain signer, a PeggedBitcoin (PBTC) ERC-20 contract and an off-chain depositor.

The depositor wants to create a PBTC. They ask the contract to take 1 BTC. The smart contract waits for the signer to do 2 things. Firstly, they need to accept the request and return a new BTC address for the depositor to put their BTC into. Secondly, they need to deposit 150% of their own ETH as collateral.

The depositor then puts 1 BTC into the new BTC address and provides proof of this to the contract. The contract creates 1 PBTC – 0.99 goes to the depositor and 0.01 goes to the signer as a fee.

When the depositor wants their BTC back, they send 1 PBTC to the contract along with their BTC address. A signer then pays 1 BTC to that BTC address, subtracts transaction fees and provides proof of the payment to the contract. The contract can then burn 1 PBTC in order to equalize the BTC:PBTC ratio. The signer is then able to withdraw their ETH collateral.

Flaws

This obviously an elegant design, but it's too good to be true. It skips difficult issues like the slowness of Bitcoin proof-of-payment on the EVM and hacing a reliable price feed.

The biggest problem though is having very insecure custody, and this expresses itself in 3 main ways—

1. There's only 1 signer. If deposits become more valuable than their collateral, the signer can steal it and make a profit. Also, the signer can be coerced be coerced by powerful actors. So it fails on the censorship-resistance goal.
2. There's a single hot wallet. This creates an enormous honey-pot and attack target for hackers.
3. There's no failure localization – a single fault could affect the entire network.

System Architecture: Designing a Robust Multi-Wallet Multi-Signer Protocol

The authors want the protocol to be based on a multi-wallet design, have many geo-graphically distributed signers and have no single points of failure.

Additionally, the system needs to improve on several faults highighted in the section above. Namely, it needs to—

• introduce multi-signer payments
• improve the bonding system
• detect and handle signers who don't hold enough collateral
• have a Bitcoin proof system
• solid way to handle failures on both Bitcoin and Ethereum sides

There are few pieces which are essential to the system, which the authors are assuming will be in place at launch. They include a well-distributed work token and random beacon for selecting signers. The system also needs an efficient key-generation protocol and a multi-party threshold ECDSA protocol, both on the secp256k1 curve.

One of the main people behind Keep is Matt Luongo from Keep Network. The whitepaper states the Keep will provide all of the requirements above.

Deposits

Overview

tBTC enables people to create TBTC on a chain not hosted by Bitcoin with an absolute 1:1 pegging.

The process looks like this—

1. depositors ask tBTC to give them a BTC address to deposit in
2. tBTC selects a bunch of signers
3. signers generate a private/public keypair and broadcast it to the system
4. depositors then deposit their hard-earned BTCs to that wallet
5. the deposited BTC is split into 2 parts – one part can be used to create 1:1-backed TBTC and the other can be used to pay signers for their work.

Deposit Request

The deposit request is the starting point for somebody wanting to move their BTC to TBTC.

The request itself takes the shape of a transaction to the tBTC Ethereum smart contract. It indicates that the depositor needs a wallet address from a signing group because they want to deposit some BTC.

The deposit request needs to include a small fee in ETH. This is because there is a cost to creating a signing group. This fee is refunded once a successful deposit is made.

Signer Selection

After the deposit request the process of signer selection begins. Here is that process—

1. tBTC requests a random seed a secure decentralized beacon on Keep
2. the random seed is used to randomly select signers from a pool. This comprises the signer group.
3. this signer group creates a public ECDSA key together
4. the public key is used to create a wallet address, which is published to Ethereum

Signer Bonding

Before the signer group creates the public ECDSA key together they need to stake a bond in ETH. The signers can lose their bond if they behave badly.

Making a Deposit

So tBTC now has a wallet address for this deposit request. The depositor send BTC from their own wallet into the signer group's wallet address. Bitcoin confirms the transaction and the depositor issues a transaction to Ethereum proving that the deposit has been made.

tBTC – a set of smart contracts on Ethereum – is the only link between Bitcoin and Ethereum. As a result, tBTC needs to know that the BTC has been successfully deposited before tBTC lets the depositor act as though they've made a deposit.

Once tBTC has received proof that the depositor has made the deposit, the depositor can receive their initial bond back.

If tBTC doesn't receive a deposit proof within a certain period of time, the signer group disbands, tBTC takes the deposit bond and makes it available to the members of that signer group.

Light Relays

To prove that they've made the Bitcoin deposit, the depositor needs to send a proof to the Ethereum smart contract.

This proof is done with a special Simple Payment Verification (SPV) developed for tBTC called a Light Relay. Light Relays use stateless SPV proofs while passing on enough information to give each proof some recency guarantee. This is done by using Bitcoin's difficulty adjustment. Light Realys only store some headers about difficulty adjustment rather than all the block headers.

Lots

Deposits are made in fixed-size lots. The size of the lot is adjustable – it's a system parameter. At launch the lot size will be 1 BTC.

You can only make deposits in multiples of the lot-size – i.e. whole bitcoins – at first. If you want to deposit 5 bitcoins you need to create 5 deposits. The advantage of this is that it creates more signer groups and increases system resilience.

Mistakes Making a Deposit

By design, tBTC cannot handle the case where too much or too little BTC is deposited. So depositors need to send exactly the right amount – otherwise they cose lose money.

Underpayment

tBTC won't accept deposits under the lot size. If you send less than 1 BTC you don't get any TBTC. In fact, you lose your funds to the signers.

Overpayment

tBTC does accept an overpayment, but only creates TBTC according to the lot size. So if you send 1.2 BTC, you'll only end up getting 1 TBTC. The remaining 0.2 BTC is vulnerable. Another TBTC holder can burn their TBTC to claim that initial 1.2 BTC deposit.

This means that if you notice you've overpaid, you should quickly try to burn and reclaim your deposit before someone else does and gets your extra 0.2 BTC.

Multiple UTXOs

To keep the system more simple, tBTC only accepts the first UTXO sent as a deposit to the signer group. If you send more UTXOs you lose any funds held in any except the first UTXO. So don't do that. This will likely be addressed in the UI.

Deposit Economics

In order to do work on the system, signers need to be paid. In turn this requires that their fees are guaranteed by minting and that they known exactly when their deposits will expire.

Terms

The lifetime of a deposit is 6 months. This enables depositor to budget for fees and for signers to know how long their ETH is going to be locked up for.

In some cases, despotiros may not want or need to retain the right to access their deposited BTC. So at the point when they create their deposit they can choose to receive an NFT – the deposit owner token. This token can be transferred to somebody else. When the deposit is redeemed, the holder of the deposit owner token gets their initial deposit back.

Bonding

Bonds prevent signers from working together to stop depositors redeeming their BTC and from stealing the funds they're signing over.

Each deposit requires a bond to be staked by every signer in the group. The collateral used in the bond needs to be an asset that's both very liquid and one that has a large market cap. Both criteria are critical for maintaining security.

If signers do collude to steal the funds, depositors are able to get their money back by taking the signers' bonds.

Acceptable Collateral

Ultimately, TBTC and Keep's work token would be good as collateral. Netiher will work at the launch of tBTC though. They're both too illiquid and too small market cap. For now, ETH is the best option.

Measuring Security

For security, bonds need to be proportional to the size of the deposit. Signers need to have more to lose by cheating than gain. This is made more complicated by the M-of-N signing model.

Take a 1 BTC deposit as an example. It's backed by a 3-of-5 group of signers, that is 3 out of 5 signers in the group are required to sign transactions. In this case, 3 signers could steal the deposit, giving them each 1/3 of a BTC. In order to protect for this, signers in tBTC are required to stake 1/3 of a BTC each in ETH. In this way signers are never able to work together to leave with more value than they have at stake in the system.

Pricing Currency Fluctuations

The BTC to ETH price fluctatuation is huge. This is an obstacle for the design of tBTC.

To protext from the situation where ETH drops in price compared to BTC, signer bonds must be overcollateralized at 150%. If signers fall below this collateralization ratio they enter pre-liquidation and then liquidation.

On the other hand, if BTC drops in price relative to ETH the main issue becomes that signers will get lower fees for custodying the BTC. This is because signer fees are denominated in BTC. THe rational move for signers is thus to reclaim their excess liquidity out of the bond and put it to use, perhaps as another bond for more deposits.

A Resilient Price Feed

tBTC won't try to stabilize the price of TBTC – the market will be responsible for that. tBTC only tries to maintain the TBTC supply at the correct 1:1 ratio. So tBTC only needs to understand the relationship btween BTC and ETH and can therefore use a simple price feed.

Undercollateralization

Preliquidation

When a deposit hits a 125% collateralization ratio it enters pre-liquidation. At this point signers must close the deposit. They either have 6 hours after the moment they enter pre-liquidation, or until the deposit hits 110% collateralization.

Liquidation

Liquidation aims to keep the BTC:TBTC ratio in-tact.

Forced liquidation is unlikely. Self-interested signers will redeem deposits before they reach liquidation. But the mechanism still needs to be in place to dissuade dishonest signer behavior. Liquidation takes place when the bonds are undercollateralized but also when the signer commits fraud.

The liquidation process starts with signers being marked for liquidation. tBTC seizes their bonds in order to try to sell them for TBTC. The end goal of this is to burn the TBTC, bringing the ratio back into equilibrium.

Once the system has the seized ETH, it tries to exchange it on on-chain reserves like Uniswap. If this doesn't have enought TBTC available, tBTC begins a falling-price auction. The auction starts with buyers able to buy 80% of the outstanding TBTC amount. The amount then increases until someone buys its. Once it reachers 100% the bond remains available until someone buys it.

All the TBTC which is obtained during this process is burned to help maintain the supply peg. If any is left over the account which triggered the liquidation gets a small fee. If any is left over after that and the liquidation happened because of undercollateralization, signers get a cut. Otherwise if it was liquidated due to fraud the remaining TBTC is simply burned.

Price Feed

The price feed will initially be governed and maintained by a single trusted actor.

Mechanisms of Price Feed Updates

A price in the system expires after 6 hours. If it isn't updated after that, processes in the system which require price shutdown.

To save on computation, the price is only updated if the proposed update is different by more than 1% compared to the current one.

Future Design

Although the price feed is initially governed by a single actor the plan is for it to be governed by the tBTC ecosystem in the future.

The first upgrades will use a medianizer model as used by Maker. A medianizer uses multiple price feeds which are voted in by a governing body. The price is then taken as a median price of those feeds.

The team is also considering sourcing prices from decentralized exchanges and liquidity pools such as Uniswap.

Minting

Minting is different to the process of depositing Bitcoin. It's split into 2 phases. Firstly a simple payment verification proof leads to the issuance of a deposit owner token for the depositor. Then the system gives the depositor a deposit beneficiary token.

This mechanism leads to a system which is well-balanced for security and a flexible user experience.

Minting the Deposit Owner

After the deposit is made, the depositor can submit proof of their funding transaction. If successful, the depositor gets an NFT called a deposit owner token. The deposit owner token is tied to the UTXO of the initial deposit. It is transferable, and enables its holder to exclusive right of redemption over the funds held in that UTXO, i.e. the deposit.

Implications

The major advantage of this are that it localizes attacks. Attacking one deposit will only affect that deposit, not others.

It's worth noting that different deposit owner tokens will have different levels of risk associated with them. Also, deposit owner tokens are likely a good candidates for financial privacy innovations on Ethereum.

Minting Fungible TBTC

Once a deposit has accumulated enough work on Bitcoin it can be traded for TBTC. This process is called the "vending machine" and is facilitated by an Etehreum smart contract.

Any valid deposit owner token can be presented to the vending machine to create TBTC. Validity is determined by the amount of work that the deposit has accumulated. This is comprised of Bitcoin's current difficulty rating and the volume of deposit tokens being exchanged.

Once you've got a deposit owner token you don't immediately need to use it to mint TBTC. You can just hang on to it if you like.

The original holder of the deposit owner token can exchange it for 1 new TBTC, minus a 0.005 TBTC signing fee.

The original holder is also able to transfer their deposit owner token to another wallet. At this stage they get another NFT, called the deposit beneficiary token. The significance of this token is that the holder receives a rebate on the signer fee as well as another 0.001 TBTC, paid by the redeemer. If the original NFT holder retains the depositor NFT they lose the right to the signing fee rebate.

The result of this is that depositors are incentivised to release their deposit owner tokens. This mechanism is important because it increases the liquidity of deposit owner tokens. This benefits the tBTC network by reducing risk to signers and friction for people that want to move back from TBTC to BTC.

Redeemers can obtain deposit owner tokens from the smart contract. Each costs 1 TBTC which is destroyed by the contract upon receipt.

Signer Fees

Signers put their money at stake to secure depositor money. Naturally this money must earn a return – otherwise why would signers participate?

Paying for Security

tBTC uses a similar model to centralized cryptocurrency custodians. Centralized custodians charge 0.5–0.75% on assets under custody (AUC) per year.

tBTC is a custodian of sorts and so it feels natural to use this costing as a model. Ultimately the authors note that the decentralized model has capacity to be much cheaper, but will require much more collateralized capital, at least at first.

tBTC signers must make at least a similar return to the amount of capital they're custodying. 1 BTC deposited rewards its signers with 0.009375 TBTC. This is 1.875% of the market cap of TBTC going to signers every year.

Signing

The tBTC system requires M-of-N signatures protecting each deposit. The maximum size of the signing group is 80 due to Bitcoin's consensus rules.

Improved Fault Attribution

Without any special treatment, the entire group of signers would be punished even if only some were caught misbehaving. That is, if the signing group is made up of 5, but 3 were caught doing something bad, all 5 would lose their bond. tTBC uses accountable-subgroup multisignatures to overcome this.

Future Signature Schemes

tBTC may implement MuSig and/or BLS in the future.

Handling Failure

Aborts/Liveness

System-critical actions like depositing and redeeming must happen with a fixed time period. If they don't happen within that period they are considered an "abort". Aborts are punished – an incompetence tax, if you will – but less severely than fraud.

Fraud

There are 2 fraud cases. The first is on the ECDSA proof wherein a signer group produces signatures that the system didn't request. The second is on the simple payment verification proof where if a UTXO moves for a reason that tBTC doesn't understand.

Redemption

Overview

Deposits represent real Bitcoin UTXOs. Anybody who holds a deposit owner token can request its redemption.

Once requested, the owner of the deposit owner token must relinquish it and pay the outstanding signer fees. At this point the process is in full swing and cannot be cancelled.

At this point the signers must produce a valid Bitcoin signature. This send the deposited BTC to the requested address and enables Bitcoin actors to create a transaction redeeming the deposited BTC.

Redemption Requests

Only the holder of the deposit owner token can request redemption.

The redemption request itself includes a fee amount, the redeemer's BTC address and the size of the deposit along with the signer fee, and a beneficiary fee if the redeemer is not the original depositor.

When tBTC receives the request it burns an amount of TBTC equal to the deposit size, gives signers their fees and bonds and notifies signers that they need to put together a signature.

Repayment Amount

The repayment amount is the amount of money included along with the redemption request. It includes the deposit size, the custodial fee of 0.005 BTC and a payment of 0.0005 TBTC to the holder of the deposit beneficiary token.

Further Notes on Redemption

• the format of the redemption request on Ethereum is simple and canonical
• once a redemption transaction is completed, it's proved by a redemption proof
  • which is
    • an SPV proof
    • expected within 12 hours of the redemption request being submitted
• after proof is confirmed signers must produce signature on the redemption transaction
  • got 3 hours to do so
• tBTC has a mechanism by which signers can increment fees every 4 hours to align with Bitcoin fee adjustment