Analyzing tBTC against wBTC and cbBTC

janusz

— 20 min read
Analyzing tBTC against wBTC and cbBTC

Introduction

Wrapped bitcoin tokens on EVM-based chains satisfy market demand for using bitcoin (BTC) on more expressive smart contract platforms. All wrapped versions of BTC come with various trust assumptions.

Traditionally, wBTC has dominated market share for bitcoin-backed ERC-20 tokens on Ethereum. wBTC is custodied by a single party, BitGo. BitGo is a digital assets company that offers various solutions, including professional custody. Recently, BitGo announced they’d be distributing this custody to additional parties. This shift in custody is significant as users’ trust in wBTC is an extension of BitGo’s trust and reputation rather than trust in the technical implementation of the token itself.

And now, other custodial solutions like Coinbase’s cbBTC are entering the market to compete and provide users with an alternative.

However, more distributed forms of wrapped bitcoin tokens exist. tBTC v2 introduces a threshold signature signing mechanism where stakers in a protocol are given signing authority over a number of bitcoin wallets that custody bitcoin, backing tBTC on Ethereum and Ethereum-adjacent networks.

All of these solutions come with a variety of tradeoffs relative to who custodies the bitcoin-backed wrapped tokens on Ethereum: the reputation and jurisdictional risk of these custodians, how they’re selected to custody funds, and who has special privileges over the various smart contracts supporting wrapped tokens in Ethereum.

This brief report will cover the technical architectures of tBTC on Ethereum and Base. It will compare these architectures to wBTC and cbBTC. It will also cover the tradeoffs relative to trust assumptions outlined in the Bitcoin Layers framework.

This report is sponsored by Thesis, the company behind the tBTC project. We will refer to the bitcoin network as “bitcoin” and bitcoin the asset as “BTC” for the rest of this report.

Any bias within this report is due to the author preferring tBTC v2’s design to centralized custodians.

The process of minting and burning BTC-backed ERC-20 tokens

All synthetic BTC tokens on Ethereum are minted through the following steps:

  1. Deposit: A user deposits BTC into a bitcoin wallet managed by some third party. These BTC tokens are used to back the wrapped BTC tokens 1:1.
  2. Message passing: This step is handled differently by centralized and distributed systems. In a centralized system, issuers are notified of deposit requests in any manner. In a distributed system, one or more bitcoin light clients scan the bitcoin blockchain to notify the relevant smart contracts that a user has deposited funds into the relevant bitcoin address and is requesting a wrapped BTC token on Ethereum.
  3. Issuance: After the bridge has been notified, an Ethereum smart contract mints wrapped BTC tokens per users’ requests.

All synthetic BTC tokens on Ethereum are burned through the use of:

  1. A user submitting a burn request to the relevant smart contract on Ethereum. The request contains a BTC address in the data field.
  2. The token’s smart contract processes the request on Ethereum, burning the tokens.
  3. The bridge’s consensus mechanism signals to the bridge's consensus mechanism that signers of the corresponding bitcoin wallet need to release BTC to the user’s bitcoin wallet.

Primary trust assumptions

The primary trust assumptions related to these token contracts are the governance behind the respective smart contract for the ERC-20 contract token on Ethereum and the signing mechanism behind the bitcoin wallet holding the BTC that backs the token.

First, we introduce a few trust assumptions we’ll analyze.

All BTC-backed ERC-20 tokens have a corresponding bitcoin address (or addresses) on the bitcoin blockchain that holds BTC to back the token. If BTC in this wallet was moved to another wallet that was not designated to back the tokens (some mechanisms rotate the bitcoin wallets), then tokens on the alternative blockchain would become unbacked and lose value.

When a user deposits funds into a bitcoin address to mint a BTC-backed ERC-20 token, they give up complete custody of their bitcoin to the signers of said address. The signing mechanisms behind these wallets can be multi-signature wallets or threshold signature schemes, and signer selection can be done by a centralized company or an alternative consensus mechanism (e.g. Proof-of-Stake). Becoming a signer in one of these bitcoin wallets can be a permissionless or permissoned process.

The mechanisms and tradeoffs behind signer selection for these wallets. Some users prefer a federation of known companies to be the signers and trust that reputational risk causes these companies to not be malicious. Others prefer a mechanism where an alternative consensus protocol where signers additionally stake an alternative token and are subject to financial penalties for misbehaving. When it comes to trust-based systems, there is no objectively superior model, as end users have different preferences.

Governance

A smart contract on Ethereum is a self-executing contract where the parameters of execution are determined by its code. An ERC-20 token contract is a smart contract that conforms to the ERC-20 standards; i.e., it defines the total supply of a specific token, token balances for users, how the asset can be transferred, approvals for applications to interact with the token, and more.

Related to BTC-backed tokens, an ERC-20 smart contract is responsible for the minting and burning of tokens related to the corresponding amount that is held in the bitcoin wallets backing the respective token.

Ethereum contracts are immutable by default, meaning that they cannot be changed. However, they can adopt proxy models to be upgradeable, meaning that a specific party can upgrade the smart contract to change some parameters.

Smart contract upgrades can be malicious. For example, if a single signer is the admin for a token contract, and that contract is instantly upgradeable, then the single signer can upgrade the contract to redirect all of the token supply to their own signer (or another address they control) and steal all of the funds.

Thus, who is governing a specific contract is extremely important. Smart contracts can be governed by decentralized autonomous organizations (DAOs), distributed multi-sigs (e.g. a security council), centralized multi-sigs, or a single signer.

Poor implementation

Smart contracts can also be exploited if they are not implemented correctly. If a bug is found in a specific contract, an exploiter could manipulate the contract to steal funds, drain liquidity pools, and more.

ERC-20 tokens are not immune to this. For example, an exploiter can exploit the contract to mint a significant amount of tokens. In the case of a BTC-backed ERC-20 token, this would cause the token to become unbacked and break its two-way peg.

Introducing tBTC, wBTC, and cbBTC

In this report, we are covering three different BTC-backed tokens on Ethereum and Base: tBTC, wBTC, and cbBTC. We will cover the trust assumptions related to their token contracts, the governance behind them, and the bridge contracts respective to Base. We will also cover the signers behind the bitcoin wallets that hold BTC backing the respective tokens.

tBTC

tBTC is a BTC-backed ERC-20 token that is available across several EVM-based blockchains. The BTC backing the tBTC token is held in bitcoin wallets that are controlled by a set of signers participating in a tECDSA scheme, where 51% of signers are needed to sign a transaction. Signing privileges in these wallets are given to stakers in the Threshold Network, who stake the “T” token to be eligible to participate as a signer. When elected, signers are eligible to receive rewards. Some of the roles in tBTC are permissioned, which we will touch on in this report.

The Threshold Network operates primarily on the Ethereum blockchain, but signers participate in an offchain communication protocol (libp2p) to coordinate signing events. A signer in tBTC is responsible for keeping this node online to ensure that signing events (e.g. a peg-out) are completed promptly.

wBTC

wBTC is a BTC-backed ERC-20 token that is available across several EVM-based blockchains. The BTC backing the wBTC token is held in reserve wallets managed by BitGo, a US-based centralized custodial provider. BTC has typically been held in ⅔ multi-signature wallets where BitGo retained all signing privileges. wBTC has recently announced a partnership between BitGo and BitGlobal to diversify the custodians, and their respective jurisdictions, who are responsible for custodying these assets.

cbBTC

cbBTC is a BTC-backed ERC-20 token that is available on Ethereum Mainnet, Base, and will soon be available on Arbitrum One. The BTC backing the cbBTC token is held in reserve wallets managed by Coinbase, a US-based centralized custodial provider. Coinbase holds funds backing cbBTC in cold storage wallets across a number of geographically distributed locations and additionally has insurance on funds they custody.

Analyzing the signing mechanism behind tBTC

We will now refer to Threshold Network and tBTC generally as tBTC.

tBTC signing mechanism

The primary difference between tBTC and wBTC & cbBTC, is that the signing mechanism for bitcoin wallets is distributed. BTC is stored in wallets that are signed by tECDSA signature scheme with a 51% threshold. tECDSA is a threshold signature scheme that shards a public key across a number of different signers and requires a threshold of these signers to come together and produce a valid signature. In the case of tBTC, 51% of signers need to come together to produce a valid signature to initiate a transaction for a given bitcoin wallet.

To be eligible to be a signer, operators need to join a staking mechanism involving the T token, an ERC-20 token. The T token staking contract lives on Ethereum and enables any user to deposit the T token in the staking contract to earn rewards. A user can do this via interacting with the T Staking Dashboard or interacting with the smart contract directly. Stakers can directly participate as a signer, or delegate their stake to another signer. Currently, the minimum amount of T someone can stake is 40,000 T, roughly $1,018 as of the time of publishing.

A signer would additionally need to run a Threshold Network node to allow them to participate in the signing mechanism. After staking the necessary amount of tokens, they would need to configure a node to be able to participate in an offchain communication protocol which is based on libp2p. This protocol enables the signers to coordinate on signing events.

Not all of the BTC backing tBTC is held in a single address. A new bitcoin address is generated for deposits periodically. Every time a new bitcoin address is generated for deposits, a T staker is responsible for a distributed key generation ceremony, where they create a bitcoin wallet that will be used for these deposits.

After the wallet is generated, the sortition pool will then select signers from the T staking mechanism to participate in signing events for the bitcoin wallet. The sortition pool is a mechanism that elects signers on a random basis from a pool of nodes who are staking tBTC. This mechanism helps randomize and distribute signing power across nodes in the network. Staking a large percentage of T will see nodes increase their chances of being selected from the sortition pool. Each wallet is divided into 100 key shares, and those key shares are divided amongst node operators via the sortition pool. Nodes that stake more T have a higher probability of being selected to be a signer and have more than 1 signer key, but this is not guaranteed.

Not only are the signers of the bitcoin wallets selected via a randomized process, but each newly generated wallet has a new set of signers. In the event that a majority of signers were malicious, the risk is contained to wallets that these signers have 51% control over. The more wallets that are created in the tBTC protocol the more this risk becomes minimized over time, assuming that stake does not become completely centralized to a few parties. In the event that stake was centralized, and the sortition pool only had a few entities to select from, the risk of malicious signers gaining control over wallets becomes higher.

Today, anyone can stake T and point their stake towards the tBTC application (the Threshold Network has two applications T stakers can support). However, the role of signing, custody, and any other function related to tBTC is currently permissioned. Stakers must currently apply to be a “beta staker” to participate in core functions for tBTC. To become a “beta staker”, a user (or entity) needs to apply to become a staker. If their application meets the expectations of the Threshold DAO, then the DAO votes (some votes are delegated to more active DAO members) on which stakers they want to participate in the program. An example of this process can be found in this forum post. Currently, there are 35 beta stakers.

If fully permissionless, tBTC purely relies on economic incentives. This would see the T token be instrumental in incentivizing the signer set. Signers could need to be incentivized from their rewards in T tokens, and its corresponding value, to not steal funds from the system. Still, even if not financially incentivized, some signers may remain honest. Furthermore, participation would also need to be decentralized enough to ensure no single party, or limited number of parties, could collude to steal the funds.

Permissionless participation in the Threshold Network could potentially widen the attack surface for stealing BTC backing tBTC. While staking is permissionless, eligibility to participate in the tECDSA signing scheme is permissioned to Beta Stakers. Thus, the members of the Threshold Network that could exploit tBTC’s bitcoin wallets are known to the Threshold DAO.

The market capitalization of T is less than the value of BTC backing tBTC. If the staker set was permissionless, malicious actors might be incentivized to acquire T, stake it, become a part of the eligible signer set, and attempt to steal the BTC in newly generated wallets if they controlled more than 51% of signing power. The more centralized stake becomes, the higher probability that a malicious staker gains majority control of a newly created bitcoin wallet for deposits. The staker could then steal funds in the wallet.

Additionally, if signers of current (or legacy) bitcoin wallets are not incentivized through rewards provided by newly issued T, they could turn malicious and steal the BTC in their specific wallet. While the risk is isolated to specific wallets, users are trusting the signers for these wallets to not steal funds.

Verifiability

Threshold Staking Contracts

Users can verify who is staking T tokens in the Threshold Network’s staking contracts. They can do this by looking at the staking contract on the Ethereum blockchain. You can find this contract here.

By looking at this contract on Etherscan, we can see the Ethereum addresses of parties who are currently staking in the T staking contract. Users can correlate these addresses with those on tbtcscan, which outlines how stakers might be shaped into groups responsible for signing transactions on tBTC’s corresponding bitcoin wallets.

Threshold’s node implementation

Threshold’s node implementation is open-source. This node implementation is used for signers to coordinate signing native bitcoin transactions via the aforementioned tESDCA scheme. The signers communicate signing events via a libp2p network.

The role of the T token

The T token does not overcollateralize deposits in the tBTC bridge. The T token is leveraged for staking and gaining the ability to become a signer of the bitcoin wallet custodying funds that back tBTC. Users can view the T token as a Sybil-resistance mechanism in addition to an incentivization mechanism.

Staking more T token increases the probability that a staker will be selected as a signer for a given wallet, but it does not guarantee it. This could create more incentives to stake the T token. Additionally, it provides protection against liveness failures.

A potential risk is the price performance related to the T token. T rewards will need to be able to incentivize stakers long term, and if the price performance is low, this could result in centralizing effects (less people want to stake T). In a permissionless setting, it could disincentivize tBTC signers to remain honest and potentially see them steal the BTC backing tBTC.

By requiring signers to stake some amount of tokens before joining the network, you could also introduce a mechanism that detects large acquisitions of stake, which may be malicious, and enable the current staking set to review new staking entrants prior to them joining the network.

Overall security model of tBTC

Many people have attributed the tBTC tECDSA scheme, and 51-00 signing threshold, as a “big multi-sig” that controls all of the BTC backing tBC. This is incorrect.

tBTC’s security model sees the BTC backing tBTC distributed across a number of bitcoin wallets. Currently, the BTC is held in nine wallets. This sees risk distributed across the individual wallets respectively.

tBTC’s wallet signers are selected via the randomized process mentioned above. Having signing privileges, and the relative amount of signing power, in a given bitcoin wallet does not guarantee that this signer will have these privileges in the future.

If a signer, or group of them, had over 51% control of a given wallet and wanted to steal the funds, the risk would be contained to the wallets that these signers have control of. This concept sees tBTC have future protections and mitigations against compromised wallets.

However, this does still come with risks. Ideally, stake is distributed enough to minimize the chances of a single party gaining 51% control over a specific bitcoin wallet. If stake became completely centralized (especially if/when the protocol becomes fully permissionless), then the chances that the sortition pool could elect a very centralized group of signers for a specific wallet which could make collusion and theft easier.

tBTC should be viewed as a distributed, but permissioned, protocol. The reputation of signers is an important factor in tBTC’s security model, but the risk does not lie with a single custodian. As mentioned in previous sections, making this role permissionless adds a new set of risks.

cbBTC and wBTC likely have distributed key management and signing, but they do not have a distributed signer election mechanism like tBTC. All decisions related to the cbBTC and wBTC signing mechanisms are managed by a centralized company. This means that the signers of these wallets, and decisions on how signing keys are set up and managed, are in the hands entirely by employees of the respective companies. It would take only one entity to be malicious to steal the funds backing these tokens respectively.

As mentioned above, BTC-backed tokens on Ethereum are represented by ERC-20 smart contracts. These contracts can be either immutable or upgradeable. The mechanism behind upgrading a specific token smart contract can vary.

The token addresses for the respective tokens on Ethereum mainnet can be found below:

When looking at these contracts, users can discern a few things. First, we see that the token contract for tBTC, on Ethereum, is not upgradeable. This means that a specific owner can not upgrade the contract to malicious logic.

Additionally, there is no blacklist or pause function in the tBTC token contract. This means that the owner of the contract can not censor specific users, or stop users from sending tBTC tokens.

cbBTC, on the other hand, is upgradeable by an admin. This means that an admin, i.e., an address controlled by Coinbase, could upgrade the contract to implement malicious logic such as stealing user funds, censoring specific users, and other actions. cbBTC also has a blacklist function in its contract, for regulatory reasons. blacklist functions are common practice for US-based asset synthetic asset issuers, such as Circle with USDC.

wBTC is upgradeable, but not by BitGo itself. There is a wBTC DAO that controls the wBTC smart contract, and it would take 8 (of 13) of these parties to sign and upgrade the contract, implement a blacklist function, pause the minting and burning of wBTC, and pause ERC-20 token transfers.This means that wBTC can pause the contract and stop all transfers of wBTC, but cannot individually censor.

Additionally, the staking contracts for T can be found here:

How these assumptions change on rollups

Rollups are scaling solutions that take transaction execution from a base layer (e.g., Ethereum) while still using the base layer’s data availability and consensus. In Ethereum, they also usually have an enshrined bridge that provides rollup “settlement” for L1 assets. They do this to improve transaction costs and performance. A number of users no longer interact with the Ethereum base layer due to costs, and now prefer to transact on rollups.

Users’ trust assumptions related to BTC-backed tokens are affected when they interact with these rollup systems. Users take on additional assumptions past the Ethereum L1 and token issuers. The security of the mechanism related to specific token contracts can also change.In the sections below, we’ll cover how interacting with a rollup changes trust assumptions related to tBTC and other tokens generally, and specifically look at each tokens’ implementation on Base, a rollup on Ethereum.

Trust assumptions on Base

tBTC’s trust assumptions change when interacting with the token on an L2. Both contracts that users interact with, the token contract and bridge contract, are upgradeable by an admin. The admin in both cases is a 6-9 multi-signature wallet. This admin can submit a malicious upgrade to the contract and steal user funds in the worst case.

You can find the owners and the threshold (signers) for Base’s tBTC token contract here.

Using tBTC on rollups sees users trust a more centralized signer set when compared to tBTC on Ethereum L1. Instead of trusting a more distributed set of actors, trust is put into a signing mechanism comparable to a federation.

wBTC is minted on Ethereum rollups via an implementation of a LayerZero bridge contract. tBTC is minted on Base through an implementation of a WormHole bridge contract. cbBTC is minted on Base by Coinbase who additionally has control over the token contract.

General trust assumptions

The figure below outlines some trust assumptions related to these protocols on Ethereum and Base mainnet:

On rollups, cbBTC and wBTC are managed by centralized parties.

Outlining each against our framework

Tokenized bitcoin on Ethereum and Ethereum rollups come with a variety of trust assumptions. At Bitcoin Layers, we analyze sidesystems against a standardized framework related to trust assumptions users take past the bitcoin L1. To further understand the trust assumptions related to tBTC, wBTC, and cbBTC on Ethereum and Base, we can review them against our framework.

In the Bitcoin Layers framework, we analyze:

  • Bridge security: Can someone steal users’ funds?
  • Data availability: Who is responsible for making data available related to the sidesystem's state?
  • Network operators: Who is responsible for including users transactions in a sequence?
  • Finality guarantees: Who provides guarantees that users’ transactions won’t be reorged?

For a full breakdown of the framework, head to our website. Below, we provide a quick breakdown for each token & protocol. And while currently not live, we are researching a “weighted scoring mechanism” to value some categories over others. For this report, we apply that prospective score to further illustrate overall trust assumptions.

On Ethereum

tBTC

tBTC on Ethereum would receive the following scores:

  • Bridge custody, Yellow*: Leverages a distributed signing mechanism where malicious peg-outs can be isolated to specific wallets
  • Data availability, Yellow: Data related to the chain’s state is made available by a permissionless consensus network
  • Network operators, Yellow: Blocks are built by a permissionless consensus network
  • Finality guarantees, Yellow: Finality is provided through a permissionless consensus network

The overall score is 67 out of 100 points.

We are currently reviewing the verbiage around mechanisms like tBTC v2 and the Spiderchain receiving a yellow score in our framework.

cbBTC

tBTC on Ethereum would receive the following scores:

  • Bridge custody, Stop!: The bitcoin is custodied by a single entity
  • Data availability, Yellow: Data related to the chain’s state is made available by a permissionless consensus network
  • Network operators, Yellow: Blocks are built by a permissionless consensus network
  • Finality guarantees, Yellow: Finality is provided through a permissionless consensus network

The overall score is 33.5 out of 100 points.

wBTC

tBTC on Ethereum would receive the following scores:

  • Bridge custody, Stop!: The bitcoin is custodied by a single entity
  • Data availability, Yellow: Data related to the chain’s state is made available by a permissionless consensus network
  • Network operators, Yellow: Blocks are built by a permissionless consensus network
  • Finality guarantees, Yellow: Finality is provided through a permissionless consensus network

The overall score is 33.5 out of 100 points.

On Base

tBTC

tBTC on Base would receive the following scores:

  • Bridge custody, Red: The bitcoin is custodied by 9 publicly known operators
  • Data availability, Yellow: Data related to the chain’s state is made available by a permissionless consensus network
  • Network operators, Red: Users can force include their own transactions into a block, but if the sequencer halts the network they can’t propose their own block
  • Finality guarantees, Yellow: Finality is provided through a permissionless consensus network

The overall score is 44.9 out of 100 points.

cbBTC

tBTC on Base would receive the following scores:

  • Bridge custody, Stop!: The bitcoin is custodied by a single entity
  • Data availability, Yellow: Data related to the chain’s state is made available by a permissionless consensus network
  • Network operators, Red: Users can force include their own transactions into a block, but if the sequencer halts the network they can’t propose their own block
  • Finality guarantees, Yellow: Finality is provided through a permissionless consensus network

The overall score is 28.4 out of 100 points.

wBTC

tBTC on Base would receive the following scores:

  • Bridge custody, Stop!: The bitcoin is custodied by a single entity
  • Data availability, Yellow: Data related to the chain’s state is made available by a permissionless consensus network
  • Network operators, Red: Users can force include their own transactions into a block, but if the sequencer halts the network they can’t propose their own block
  • Finality guarantees, Yellow: Finality is provided through a permissionless consensus network

The overall score is 28.4 out of 100 points.

Tradeoff space

Within these designs, there are a number of tradeoffs. Some are not specific to the specific implementation of the tokens’ smart contracts.

Many users prefer Coinbase’s custodial solution, even if it has the power to censor users, freeze their funds, and steal, or lose, the bitcoin backing cbBTC. A number of users have traditionally trusted BitGo to ensure that wBTC is backed, and will now need to trust BitGo and Bit Global to ensure wBTC’s peg is not broken. And other users prefer the more distributed nature of tBTC. tBTC has been in production for over four years and has proven to be a resilient mechanism to bridge BTC cross-chain in a distributed manner. The isolation of risk to specific wallets, and randomized selection of signers for each bitcoin wallet holding BTC backing tBTC, and permissioned setting for beta stakers create a balanced tradeoff between permissioned signing mechanisms and fully decentralized systems.

But a more distributed system doesn’t necessarily mean a more secure one. Coinbase does have a proven track record for institutional custody and is trusted by millions of users. Even if the centralized system has the ability to censor and steal from users, doesn’t mean it ever will.

In contrast, a distributed system has a wider attack surface. Users must consider that the protocol must be able to be resilient against attacks, but also have an efficient coordination mechanism in place to mitigate ongoing attacks. In tBTC, users must be confident in the protocol’s implementation in code and distribution of stake, the soundness in wallet generation and key distribution processes, the randomization of the sorition pool, and the individual signers who collectively come together to manage the bitcoin wallets backing tBTC. If any of these mechanisms were to fail, then users' funds would be at risk.

So, who can steal?

Simply put, wBTC and cbBTC trust centralized custodians to not steal the bitcoin backing their tokens respectively. This is the ultimate trust assumption related to these tokens, and users should practice due diligence before trusting their funds with one of these custodians.

In tBTC, if a specific signer, or subset of signers, were malicious and were selected by the sortition pool to manage a newly created bitcoin wallet, they could steal. If the current signers of a current wallet became malicious, and coordinated effectively, they could steal.

Related to tBTC, this assumption changes across rollup-style blockchains. Since tBTC is natively minted to Ethereum, and leverages Ethereum as its accounting ledger, tBTC tokens are a synthetic version of the token. For example, on Base, the tBTC backing the token lives in a multi-sig contract governed by a 6/9 threshold.

Users may prefer interacting with rollups due to performance and lower cost, but do take on further trust assumptions when doing so. The risks related to wBTC and cbBTC are still primarily with the custodial providers.

Future roadmap for tBTC

tBTC v2 is most certainly a work in progress, with numerous upgrades on its roadmap. Below we highlight a few:

  • Upgrade tECDSA to Schnorr Signatures:The tBTC ecosystem is looking to upgrade its signing mechanism from tECDSA to Schnorr signatures. This will make the threshold signing scheme simpler to execute. It will also make signing events attributable, meaning that if a signer fails to sign a specific signing event, they can be slashed.
  • Make beta staking and DKG permissionless:The beta staker role, and the parties who can create a bitcoin wallet and set up the distributed key generation ceremony, are currently permissioned in tBTC. The tBTC roadmap wants to see this role eventually become permissionless. In this scenario, the system would further rely on economic incentives to ensure the integrity of newly generated bitcoin wallets and that their signer set is distributed.

Summary

The following section includes the author's opinion.

tBTC is a bitcoin-backed ERC-20 token that has a permissioned, distributed signer set that participates in a consensus mechanism to custody BTC backing tBTC. cbBTC and wBTC are bitcoin-backed ERC-20 tokens where a more centralized group of custodians controls all the bitcoin backing the tokens.

In either of these models, users give up the custody of their bitcoin to a third party in exchange for a tokenized representation. They may do this to interact with onchain financial applications, they may trust the custodian holding the bitcoin, or they may not be aware of the trust assumptions.

Making these trust assumptions public is crucial because custodial providers are trusted per their reputation. If the reputation of the signers were to change (e.g. more custodians were added or changed), then users have to consider if they trust the newly added signers with the custody of funds backing their tokenized assets.

Additionally, users should consider the censorship resistance and distribution of risk when leveraging wrapped bitcoin tokens as collateral in decentralized financial applications. The more centralized the provider, the more vulnerable it is to jurisdictional risk.

In a more distributed setup, users must consider the overall implementation of a system and if that implementation can withstand a variety of attack vectors. It is crucial that these systems are designed thoughtfully, because a poor implementation can potentially lead to exploits.

Many people think that tBTC is a large multi-sig with a single point of failure. The goal of this report is to share why this is not the case, and how the distribution of risk can be an effective mitigation strategy. Custodial players do have their place in the space, but for applications that need more censorship resistance, tBTC could be an alternative asset for bitcoin-backed collateral.

This report will be published to our GitHub repo. Once published, community members are welcome to submit PRs if needed.

Read more