Introduction

In this report, we will analyze Threshold Network Bitcoin (tBTC) as a potential collateral asset. The objective of this analysis is to comprehensively assess the risks associated with tBTC to determine its suitability for collateral onboarding. Our evaluation will employ both quantitative and qualitative methods, providing insights into the safety of integrating tBTC as collateral and recommending any necessary exposure restrictions.

We will categorize the identified risks into three main areas:

• Market Risk - Concerns related to market liquidity and volatility.
• Technology Risk - Considerations pertaining to smart contracts, dependencies, and Oracle price feeds.
• Counterparty Risk - Aspects concerning governance, centralization potential, and legal/regulatory factors.

These risk categories will be summarized in the final section of this report, providing tokenholders with valuable information to make informed decisions regarding the integration of tBTC and the establishment of appropriate parameters.

Section 1: Protocol Fundamentals

This section addresses the fundamentals of the proposed collateral. It is essential to convey (1) the value proposition of tBTC and (2) the overall architecture of Threshold Network. This section contains descriptive elements that cannot be quantified and serves as a descriptive introduction to the collateral.

This section is divided into two sub-sections:

1.1: Description of the Protocol
1.2: System Architecture

1.1 Description of the Protocol

The Threshold Network is the outcome of the merger of Keep Network and NuCypher. Keep Network contributes infrastructure and off-chain privacy-preserving containers called “keeps,” while NuCypher provides privacy tools and a distributed node network.

Central to the Threshold Network is threshold cryptography, a method that distributes cryptographic operations across a network of independent nodes. This approach ensures that sensitive information can be processed jointly without any single entity having access to the complete secret key, preserving privacy.

Threshold Network is governed by the Threshold DAO, encompassing the Token Holder DAO and an Elected Council multisig. Currently tBTC operations are managed by the multisig with plans to transition to on-chain governance.

At present, Threshold Network offers three distinct products and services:

1. tBTC v2: tBTC v2 is a decentralized bridge between Bitcoin and Ethereum, enabling Bitcoin holders to access DeFi and the expanding Web3 universe without relying on intermediaries. It allows users to bridge their Bitcoin assets securely and without the need for trust in third parties.
2. Threshold Access Control (TACo): TACo facilitates end-to-end encrypted data sharing and communication without the need to trust a centralized authority. It is a decentralized access control layer that achieves true decentralization through a well-collateralized network of approximately 150 independently operated nodes.
3. thUSD (Threshold USD): thUSD is a decentralized stablecoin pegged 1:1 against the USD price. To borrow thUSD, users provide tBTC as collateral. Each thUSD is fully backed by tBTC with a minimum 110% collateral ratio, supported by a stability pool that automatically purchases liquidations, enabling a lower liquidation ratio compared to traditional auctions.

Given that the objective of this report is to assess collateral risk, we will focus on tBTC v2 for the remainder of the report. Adjacent products will be mentioned where ever relevant.

Threshold Network History:

Given the rich history of Threshold Network, below is a brief overview of chronological events and on the protocols that merged into Threshold, namely Keep Network and NuCypher.

Chronolgical Summary of Threshold Network

• 2015-01-01 Founding of Nucypher
• 2017-01-01 Founding of Keep Network
• 2018-06-19 Whitepaper release Nucypher
• 2020-04-28 Inception Keep Token
• 2020-08-30 Inception Nucypher Token
• 2020-09-15 tBTC v1 Contract Creation as product of Keep Network
• 2021-05-28 Discussion around merging NuCypher and Keep
• 2021-08-17 tBTC v2 Contract Creation Threshold Network Product
• 2021-12-21 Completion of Dao Merger
• 2023-01-31: Minting goes live (with permissoned group of minters)

Keep Network

Founded in 2017 by Matt Luongo and Corbin Pon, Keep Network was created in response to a growing need for enhanced privacy tools in the Ethereum ecosystem. Keep uses encryption and multi-party computation (sMPC) to protect private data, allowing smart contracts to interact with it while maintaining transparency and auditability.

It accomplishes this through a system of off-chain data containers known as “keeps.” These keeps are assigned to a group of participants called “signers,” who are responsible for managing and safeguarding the private data. Keep Network’s core application, the Random Beacon, provides a source of randomness to ensure that individual signers cannot access or decode the stored information. To participate in the network, signers stake KEEP tokens and receive a service fee in return.

One of the primary use cases for Keep Network is the tBTC application, which serves as a trust-minimized bridge between the Bitcoin and Ethereum blockchains. Keep Network signers facilitate the exchange and secure storage of BTC for Ethereum-based tBTC tokens, enabling BTC holders to access DeFi on Ethereum. Although tBTC experienced a vulnerability shortly after its initial launch in May 2020, it underwent rigorous security audits and testing before being successfully relaunched in September 2020.

Nucypher

Founded in 2015, NuCypher aimed to secure data in the cloud using Proxy Re-Encryption (PRE). They later adapted their technology for blockchain smart contracts. In 2017, they transitioned to a token-based model and conducted a $4.4 million SAFT sale. Public testnets launched in 2019, raising $10.7 million in a second SAFT round.

NuCypher offers cryptographic infrastructure for privacy-focused applications. It provides Threshold Access Control (TAC) for secure, trustless data sharing and Condition Based Decryption (CBD) to manage data access based on on-chain conditions.

NuCypher’s Ethereum-based middleware provided re-encryption services to decentralized apps (dApps) by allowing users to stake NU tokens. The WorkLock mechanism encourages participation through ETH escrow in exchange for NU tokens, aligning incentives for network growth.

1.1.1 Underlying Collateral

tBTC is a ERC-20 token that represents and is backed 1:1 by Bitcoin. The goal of tBTC is to enable users to access the value of their Bitcoin in the DeFi ecosystem while not requiring trust in a central third party.

1.1.2 Yield Accural Mechanism

There is no innate Yield Accural Mechanism. tBTC acts as bridge between Bitcoin and Ethereum, allowing users to utilize their BTC value within the DeFi ecosystem.

1.1.3 Provider Fee

The platform fees are action-based. As for now, a user incurs a mint and redemption fee. The current mint fee has been lowered with TIP-54, currently set to 0.1% with the entirety going to the treasury. Redemption fees are set to 0.2% going to the treasury.

There is a proposal for T governance token buybacks from treasury funds which has been approved but not yet implemented.

1.1.4 Node Operator Set

The node operators are publicly viewable on tBTCscan. Currently the network has 322 registered nodes that specifically opted in to tBTC v2 application. According to Threshold Network, the node operators are currently restricted to the list of Beta Stakers instead of all Stakers.

The rational for this is:

• During early days of the system, Threshold Network requires Stakers available to test changes and address critical bugs quickly, and having direct access to those known by the development team is crucial.
• The signature algorithm, GG18, can’t identify misbehaving signers, which poses a risk. Misbehaving stakers could disrupt Bitcoin transactions. Identifying them would allow us to exclude them from the signing process.

An alternative algorithm (FROST/ROAST) is in development in a public Github repo for identifying misbehaving signers. In addition to attributability, FROST/ROAST will allow Threshold to greatly expand signer sets to e.g. 501-of-1000

1.1.5 Validator Selection

Threshold Network effectively runs a token-weighted selection scheme (think Delegated Proof-of-Stake (dPoS)) for the currently permissioned validator set of tBTC v2. Node operators can participate in the Threshold network by running nodes and selecting which modules they want to support. They get rewarded in T tokens (Threshold’s native currency) for their services. Threshold Network selects Nodes for tBTC v2 primarily to custody BTC on the Bitcoin blockchain. Stakers can deposit T Tokens into the Staking Contract and can delegate to available Nodes.

Source: P2P.org

1.1.6 Validator Collateralization

To run a node, operators need a minimum of 40,000 T tokens to stake, plus funds to cover the gas fees. tBTC v2 staking docs also highlight that node operators should maintain a positive ETH balance and recommend at least 0.5 ETH.

1.1.7 Governance Model

Threshold Network is governed by two bodies: the Tokenholder DAO and the Threshold Council. The governance model uses token-weighted governance (i.e. one token is equal to one vote) with on-chain voting via an implementation of Governor Bravo. The governing currency is the T token.

tBTC operations are not currently controlled by an on-chain DAO. Currently, voting is conducted on Snapshot with on-chain operations managed by the Threshold Council. The Threshold Council is a 6-of-9 multisig. There are plans to deprecate or transfer management currently entrusted to the multisig as the tBTC system ossifies.

1.2 System Architecture Diagram

1.2.1 Network Architecture Overview

Source: Custom Diagram

The Threshold Network underpins the second generation of tBTC (tBTC v2). The application is architected with the following core components referenced with the corresponding number in the diagram:

1) Bridge Component:
The Bridge Component acts as the interface to the Bitcoin blockchain and off-chain clients. It is responsible for listening to deposit reveals, sweeping them, proving the actions, and reporting relevant information to the Bank. During redemption, listens to requests, disperses funds, proves actions, and reports to the Bank. Manages everything about Bitcoin wallets.

2) Bank Component:
The bank component manages Bitcoin balance accounting for Ethereum addresses. It provides two mappings to keep track of balance and allowances. It does not issue an ERC-20 token, only performs accounting.

3) Vault Component:
The Vault component is an authorized smart contract interfacing with the Bank. Custodies a balance and allows for operations like minting and burning of tBTC tokens. tBTC (the token) is implemented as a flagship Vault in this system.

4) Rewards and Slashing Conditions:
The Slashing and rewards functionality is represented in an abstracted way in the figure above in circle 4. Operators registered in the ECDSA sortition pool receive rewards, except those marked as ineligible due to inactivity or disqualification during Distributed Key Generation (DKG). These rewards are distributed based on the operator’s weight in the pool. However, there are slashing conditions in place for T stake. If a DKG result is deemed malicious and is successfully challenged, the submitter faces a slashing penalty, while the individual reporting the malicious result receives a reward. Additionally, operators who are permanently inactive can be subject to claims of operator inactivity, signed by a threshold of group members. If such a claim is submitted and accepted, these inactive members are excluded from receiving rewards from the sortition pool for a specified governable period.

5) 51-of-100 threshold-ECDSA-backed wallet
ECDSA introduces the concept of threshold ECDSA wallets. In this system, the power to issue digital signatures under a singular public key is distributed among ‘n’ parties. A specific threshold, denoted as ‘t’, is set. This means that while any group of ‘t + 1’ participants can collaboratively sign a document, any group smaller than this cannot.

The WalletRegistry smart contract serves as an on-chain ledger for ECDSA wallets, which are managed by an off-chain network of nodes. The key generation protocol utilized by this off-chain network is designed to ensure three primary attributes:

1. Unified Public Key: The entire signing group possesses a collective ECDSA public key. This key is disclosed on the host chain (typically Ethereum) and corresponds to a Bitcoin wallet that the signing group collectively owns.
2. Distributed Secret Key Shares: Every member within the signing group holds a threshold ECDSA secret key share. This share allows them to generate a threshold ECDSA signature share for any transactions linked to the signing group’s wallet.
3. Signature Combination: Any member of the signing group can amalgamate signature shares from themselves and other group members. This amalgamation results in a fully signed version of a specified transaction, representing the collective intent of the signing group.

7) Minters and Guardians:
Permissioned Guardians and Minters handle minting of tBTC to prevent malicious activities. Minting tBTC is technically permissionless, with deposits eventually being swept by a staker if optimistic Minters attempt to censor the deposit. The permissioned, optimistic Minters primarily enable more convenient, “fast-track” minting.

8) Coverage Pool:
The Coverage Pool plays a crucial role as a protective buffer within the tBTC protocol, serving as a safety net for assets secured by the system. In the unfortunate event of Bitcoin held as collateral being lost or compromised, the Coverage Pool comes into action. It facilitates the conversion of pool assets into BTC, which is then returned to the protocol to uphold the stability of the supply peg. The governance of the assets within the Coverage Pool is overseen by the Threshold DAO, providing a decentralized and community-driven approach to its management. Furthermore, there is room for the evolution of the pool’s asset strategy, allowing for diversification of assets and the potential to incentivize external deposits. This strategic approach aims to enhance coverage and bolster the protocol’s resilience against unforeseen challenges, making it a robust and secure ecosystem for users and stakeholders alike.

1.2.2 System Architecture Diagram

The Flow Diagram depicted in the diagram consists of several key components and contracts organized into different functional areas.

Source: Threshold Network Github

On the left side, there are contracts related to staking and applications. The IStaking contract defines an interface for staking operations, and the TransparentUpgradeableProxy contract implements this interface, indicating its role in handling staking-related activities. Additionally, the TokenStaking contract is associated with applications and interacts with IApplication.

In the middle of the diagram, there is a critical component called the Random Beacon, consisting of IRandomBeacon and RandomBeacon contracts. This Random Beacon is responsible for generating random values or beacon entries crucial for various processes in the system. It interacts with two instances of the SortitionPool contract, SortitionPoolRB and SortitionPoolWR, which are used for random selection purposes.

On the right side of the diagram, contracts related to the ECDSA (Elliptic Curve Digital Signature Algorithm) and wallet management are represented. The Bridge contract is involved in the communication to Bitcoin. The IWalletRegistry contract defines an interface for wallet management.

Note the arrows labeled with “implements,” indicating which contracts implement specific interfaces. These relationships show how various contracts fulfill their respective roles in the system. Additionally, project labels at the top of the diagram provide information about the source code locations of the contracts and components.

1.2.3 Key Components

Group Selection

The table below pertains to the key generation process for tBTC wallets using the tss-lib protocol. Members are chosen from a sortition pool to attempt key generation. While not all selected members might actively participate, a minimum number, denoted as C (Critical Size), is essential for successful Distributed Key Generation (DKG). The table showcases various configurations of total members (N) and the threshold (T) required for an ECDSA signature, indicating their security levels against potential adversaries.

Source: Keep Github

The security levels, measured in bits, show how resistant each configuration is against adversaries of different strengths. A higher bit value indicates stronger security. For instance, a 51 out of 100 configuration means that out of 100 members, 51 are needed for an action, and its security against an adversary controlling 15% of the total operators is greater than 54 bits. The calculations are based on a pool of 10,000 operators.

Across the 321 Node Operators, stake is distributed in the following way:

Source: tBTCScan

The top 18 Nodes together make up 51.1% of overall stake. However, given that node operators are selected from Early Node Operators this metric is deemed of lesser importance.

Guardians & Minters

The Optimistic Minting Model in tBTC v2 streamlines the process of converting BTC to tBTC. Users deposit BTC, which is then registered on the Ethereum network. Before this BTC is transformed into tBTC, a specialized group called “Minters”, comprising DeFi protocols like Curve DAO, Euler, and Synthetix, validates the deposit. To bolster security, another layer of oversight is added through “Guardians,” a broader assembly from the Threshold DAO and the DeFi community, who can overrule any minting they deem dubious. Additionally, a built-in three-hour pause before the minting ensures Guardians have sufficient time for any necessary interventions. The pause period continues to be compressed as the system matures.

Coverage Pool

The Coverage Pool is a safety net for assets secured by the tBTC protocol. If Bitcoin is lost from the protocol, the Coverage Pool provides assets to maintain the protocol’s stability. The risk manager for this pool is a multisig entity.

Currently, the Coverage Pool consists of 17 Million T tokens deposited from the DAO treasury (see Asset Pool Contract), with the Threshold DAO overseeing its operation. The DAO decides how much T enters or leaves the pool when Bitcoin is lost, with a maximum allocation of 50 million T. The strategy behind this is explained in detail on the Threshold Network Forum.

The Coverage Pool is an evolving part of tBTC’s risk management. The Threshold DAO may choose to diversify the assets in the pool to reduce dependence on a single asset type. Additionally, the DAO can propose a rewards system to attract external deposits into the pool in exchange for T rewards, which could increase the pool’s size and offer more coverage to tBTC users.

Section 2: Performance Analysis

This section evaluates tBTC from a quantitative perspective. It analyzes token usage and competitive metrics and accounts for subsidized economic activity.

This section is divided into three sub-sections:

2.1: Usage Metrics
2.2: Competitive Analysis Metrics
2.3: Subsidization of Economic Activity

2.1 Usage Metrics

2.1.1 Total Value Locked (TVL)

tBTC has currently, as of 16-10-2023, a token supply of approximately 2,185 BTC under custody. This is the equivalent to 60,755,792 USD. tBTC experienced an initial burst of growth in February when tBTC v2 went live on mainnet. In July, redemptions were enabled and has since been followed by exponential growth in supply and holders.

The tBTC token contract was deployed to mainnet on 2021-08-17. It gained some traction reaching a TVL of 40 Million. The v1 TVL subsequently dropped to ~1.5 Million.

Since 2023-01-30, tBTC saw renewed growth, having outgrown it previous TVL 3-fold.

2.1.2 Transaction Volume

The chart below depicts the Transaction Volume calculated by the daily transfer event count of the tBTC v2 token for Ethereum mainnet.

Similarly to TVL, transaction volume has seen a meaningful sustained growth since 2023-01-30 spiking regularly to low hundred of transaction per day in the last month.

The 30-day moving average is, however, currently between approximately 50 to 70 daily transactions. In dollar terms this translates to a daily transfer volume between 2 to 4 Million USD.

2.1.3 DEX Volume

The daily trading volume across markets (CEX & DEX) suggest the revitalization of tBTC v2. However, as of now tBTC v2 has not regained prior levels in terms of Dollar Volume across markets. This is more likely explained by the market cycle and the relatively lower price of BTC (therefore tBTC) as opposed to decline in tBTC activity specifically.

Source: Coingecko API

2.1.4 Average Transaction Size

The average transaction size in USD and tBTC declined since prior market cycles. However, the reduced number of transfers compared to historical levels can also mean that there is increased utility for tBTC as collateral within DeFi.

2.1.5 On-chain Transaction Volume to Market Capitalization Ratio

The Trading-Volume-to-Market-Capitalization Ratio (a.k.a. Turnover Ratio) is a financial metric used to normalize analysis of trading activity.

Generally, a high vol-to-mcap ratio suggests high liquidity and high market interest. Yet, when we cross-reference with the “Daily Transaction Count” Chart in 2.1.2 and “Daily Transaction Volume” Chart in 2.1.2, it suggests rather periods of market volatility in BTC (amplified through the low market cap of tBTC) or large changes in supply of tBTC (see recent large mint on 2023-10-06) drive periods of high turnover.

2.1.6 Token Velocity

Token velocity is a measure of the rate at which a token is being circulated or used within a given period. It provides insights into the token’s activity and how frequently it changes hands in the market.

The chart below depicts Token Velocity of tBTC for a 90-day interval (i.e. Token Velocity = Daily Transaction Volume / Average 90-Day Market Capitalization).

2.1.7 Daily Active Addresses (DAA)

We define an active user as a unique address that has interacted with the tBTC v2 token contract over a 24h period.

tBTC unique users has increased substantially since redemptions were activated in July.

2.1.8 User Growth

tBTC has seen as meaningful user growth with the number of unique holders increasing from sub-hundred to around 350. This growth is meaningful considering the current depressed market cycle.

2.1.9 DeFi Integrations

The largest tBTC holder is the crvUSD LLAMMA market with around 1/3 of the tBTC supply used as collateral for crvUSD. It also has a substantial sum in the Curve tBTC/WBTC pool and Curve crvUSD/tBTC/wstETH Tripool.

Source: Etherscan || Note: Labels have been manually added

A significant amount of the token supply is bridged via the Wormhole TokenBridge to Arbitrum, Optimism, Polygon, Solana, and Base. A marginal amount of tBTC is also in the Balancer tBTC/WBTC pool and Uniswap tBTC/WBTC pool. See a list of top contract addresses holding tBTC below:

2.2 Competitive Analysis Metrics

2.1.2 Market Share

tBTC is competing with other tokenized representations of BTC on Ethereum. We identified the following Bitcoin Bridges:

We evaluate Market Share based on the total number of BTC units minted. This approach offers the advantage of facilitating a direct comparison, regardless of price fluctuations between various BTC representations. However, it’s important to acknowledge that this method has its limitations, particularly because not all BTC representations hold the same value due to factors like security breaches and market sentiment.

The chart shows that tBTC makes up an insignificant percentage of the total tokenized BTC market share (1.3%). WBTC shows a clear market dominance, making up about 90% of market. tBTC ranks 4th by TVL behind WBTC, hBTC, and bBTC.

2.2.2 Trading Volume Share in Total Tokenized Bitcoin Trading Volume

Below is shown the volume share across protocols in terms of dollar volume for the period between 2023-06-18 and 2023-10-18. An analysis with WBTC is essentially meaningless, as it dominates in terms of volume.

Source: Coingecko API

Excluding wBTC we can see that tBTC picked up volume relative to the competition since around August.

Source: Coingecko API

However, it is important to note that tBTC, while occasionally capturing some marketshare, is still a marginal asset.

Source: Coingecko API

2.3 Subsidization of Economic Activity

Threshold Network has an extensive Liquidity Bootstrapping Program lined up for tBTC. We have summarized the key liquidity bootstrapping initiatives below:

• GP-002 Binance Learn and Earn: Allocate a minimum budget of $150,000 worth of native token $T to Binance’s Learn and Earn program.
• TIP-45 Bootstrap Node Proposal v2: Allocate $10k/month to three bootstrap node providers Boar, P2P, and Staked with uptime and server requirements specified.
• TIP-46 Defi Liquidity Bootstrap and Growth Part I - Market Maker: Provide Sense Capital with a 50 million T token loan to enhance liquidity for tBTC across the DeFi ecosystem to be repaid in a basket of ETH-based crypto assets. Liquidity deployment and inventory rebalancing requirements are specified.
• TIP-47 Liquidity Bootstrappening Part 2 - PCV (Governor Bravo): A multi-phased plan to enhance tBTC liquidity and establish BTC-based Protocol Owned Liquidity (POL). Once establishing POL, Threshold would offer incentives for votes to the Curve pool gauges. 10M T allocated for vote incentives and 40M T allocated for directly purchasing BTC-denominated Protocol Controlled Value (PCV).
• TIP-60 Solana Growth Partnership: Boost tBTC’s presence on Solana by partnering with Mango & Dual DAO to enhance liquidity and utility. Allocate 20 million T tokens to the Threshold Treasury Guild, bridge to Solana, and mint T option tokens using the Dual Finance program

In summary, Threshold Network has devised a comprehensive Liquidity Bootstrapping Program for its tBTC product, spanning various proposals and partnerships. These initiatives offer incentives to a diverse range of participants, including node providers, market makers, and liquidity providers. The overarching goal is to enhance tBTC’s liquidity, utility, and presence across multiple blockchain networks. Through strategic collaborations, grants, and well-defined milestones, Threshold Network is actively working to establish tBTC as a prominent and trusted Bitcoin representation in the DeFi ecosystem.

Section 3: Market Risk

This section addresses the ease of liquidation based on historical market conditions. It seeks to clarify (1) the Closeness-to-Peg Basis & Volatility of tBTC, and (2) the liquidity profile of the collateral. Market risk refers to the potential for financial losses resulting from adverse changes in market conditions.

This section is divided into 2 sub-sections:

3.1: Volatility Analysis
3.2: Liquidity Analysis

3.1 Volatility Analysis

3.1.1 Closeness-to-Underlying Basis

The following analysis examines the “Closeness to underlying” (c2u) metric on a daily basis. This metric measures the difference between the closing price of a synthetic asset and its underlying asset.

Note the analysis is based on the daily OHLC of most liquid tBTC/WBTC pool on Curve Finance. The analysis timespan is from 2023-08-15 to 2023-10-18, as the start date marks the pool creation.

Source: Kraken API || Geckoterminal API

The analysis includes 64 daily data points. On average, the synthetic asset tends to close approximately 0.1145% lower than its underlying asset, with some daily variations noted. The most significant negative deviation observed during this period was approximately -0.0152, while the most significant positive deviation was around 0.0121. Additionally, the 25th percentile value is approximately -0.0039, indicating that a quarter of the time, the synthetic asset closes at a relatively lower price compared to its underlying asset, while the 75th percentile value is approximately 0.0016, suggesting that it tends to close below the underlying asset for a significant portion of the time.

Source: Kraken API || Geckoterminal API

We analyzed the “Absolute Closeness to Underlying” metric (c2u_abs) on a daily basis, comprising 64 data points. On average, the daily absolute deviation between the synthetic asset’s closing price and its underlying asset’s closing price is around 0.351%. The standard deviation of approximately 0.3009 indicates variation in these deviations. The smallest observed absolute deviation was 0.0101, while the largest was approximately 1.5233. The 25th percentile value is roughly 0.138%, and the 75th percentile value is around 0.502%. This data reflects fluctuations in the absolute closeness to underlying throughout the analyzed period.

Source: Kraken API || Geckoterminal API

The analysis reveals that tBTC typically trades at an average spread of approximately -29.70 units compared to BTC, indicating a lower value. However, this spread exhibits significant variability, with a standard deviation of 119.76. The most notable negative deviation was -399.57, while the maximum positive deviation reached 313.17.

3.1.2 Relative Volatility

The analysis of relative volatility between tBTC and BTC over different time periods provides valuable insights. Over the entire observation period, tBTC exhibits a volatility of approximately 0.0211, whereas BTC displays a slightly higher volatility of 0.0244, indicating that BTC experiences greater price fluctuations.

In the most recent 90-day period, tBTC’s volatility remains consistent at 0.0211, while BTC’s volatility decreases to 0.0167, suggesting reduced volatility for BTC during this timeframe. Over the last 60 days, tBTC’s volatility is 0.0209, and BTC’s is 0.0165. However, during the past 30 days, tBTC’s volatility increases to 0.0261, while BTC’s volatility is 0.0153, indicating a notable rise in tBTC’s relative volatility compared to BTC.

3.2 Liquidity Analysis

3.2.1 Supported DEXs and CEXs

According to Coingecko, tBTC is supported by Kraken CEX exclusively, which lists 3 active pairs.

Source: Coingecko

The USD volume on Kraken is negligible with an average of $181.34 with a standard deviation of $84.03, ranging from a minimum of $92.16 to a maximum of $259.05 across the 3 pairs in the last on 24 hours on 18-10-2023. Similarly the The Bid-Ask Spread Percentage on this day has an average of 5.87% with a standard deviation of 3.76%, ranging from a minimum of 1.87% to a maximum of 9.32%.

tBTC has much more presence across various DEX pools, including Curve, Uniswap V3, Balancer, Velodrome, Aerodrome, and Orca. The heaviest concentration is on Ethereum-based Curve pools.

Source: Coingecko

As of October 18, 2018, analysis of 20 trading pairs across six decentralized exchanges revealed an average daily trading volume of approximately 6,479.21 USD, along with a mean bid-ask spread percentage of about 0.6404. Notably, there was significant variability, with a substantial standard deviation of 28,970.47 for trading volume. The trading volume ranged from a minimum of 0.000696 USD, highlighting no existent markets, to a maximum of 129,561.10 USD. The bid-ask spread percentage also varied, with the lowest recorded at 0.6028 and maximum of 0.914806. DEX markets show a range of market sizes and trading conditions within decentralized exchanges with a concentration in Curve pools.

3.2.2 Token On-chain Liquidity

The total tBTC on-chain Token Liquidity is $18,670,710 on October 18 with a 95% share of total liquidity on Curve DEX. The Token Liquidity reported on DEX Guru results from the value tBTC can be swapped into (as opposed to TVL count across pools).

Source: DexGuru

The two most liquid pools are the WBTC/tBTC pool with $16.73 Million in TVL followed by $10.74 Million in the crvUSD/tBTC/wstETH Pool.

Source: DexGuru

3.2.3 Liquidity Utilization Rate

The Liquidity Utilization Rate (LUR) measures the efficiency of utilizing available liquidity for trading tBTC. It is calculated by dividing the total daily trading volume by the total liquidity of tBTC. The analysis is conducted for a timeframe between 2023-07-18 and 2023-10-18.

Source: DexGuru API

The LUR has a mean value of approximately 0.1047, indicating that, on average, about 10.47% of the total liquidity is being used daily for trading. The standard deviation of 0.2933 suggests some variability in daily utilization rates. The minimum LUR observed is 0.0020, while the maximum is significantly higher at 2.7325, highlighting the wide range of utilization rates in the dataset. The quartile values (25th, 50th, and 75th percentiles) provide insights into the distribution, with the median (50th percentile) LUR at 0.0393, suggesting that half of the observations fall below this level.

3.2.4 Leverage Ratio

There are no lending markets listing tBTC on Ethereum. However, users can gain leverage by minting crvUSD against tBTC collateral.

Chaos Labs have provided a crvUSD monitoring and risk dashboard that shows liquidation bands for tBTC across price points. The crvUSD LLAMMA algorithm uses a process called soft liquidation that gradually liquidates collateral to crvUSD as tBTC price changes.

Source: Chaos Labs crvUSD Analytics | Date: 10/30/2023

Leverage from tBTC collateral will soon also be available by depositing into Threshold USD (thUSD is a stablecoin soft-pegged to USD and is backed by ETH and tBTC, maintaining a minimum collateral ratio of 110%.

3.2.5 Slippage

The DefiLlama slippage estimator (Token Liquidity) tool shows that a tBTC-> WBTC trade of $8,312,500 (288.78 WBTC) over Paraswap will produce 1.57% trade slippage in tBTC. As the WBTC pair is the deepest liquidity available for tBTC currently, large liquidations are likely to route through WBTC.

Source: Defillama | Date: 10/18/2023

Section 4: Technological Risk

This section addresses the persistence of collateral properties from a technological perspective. It aims to convey, (1) where technological risk arises that can change the fundamental properties of the collateral (e.g. unresolved audit issues), and (2) do any composability/dependency requirements present potential issues (e.g. is a reliable pricefeed oracle available?).

This section is divided into 3 sub-sections:

• 4.1: Smart Contract Risk
• 4.2: Product and Layer Composability
• 4.3: Oracle Pricefeed Availability

4.1 Smart Contract Risk

4.1.1 Protocol Audits

The tBTC v2 Bridge code has been audited by 3 independent auditors: Least Authority, Chain Security and Certik. The audits are listed on the Threshold Network Github.

Least Authority
The security audit by Least Authority dated 29 September 2022, delves into the security and functionality of the tBTC Bridge v2. The audit covered various code repositories and focused on areas such as implementation correctness, potential adversarial actions, fund management, and vulnerabilities in the code. Key findings highlighted concerns with Bitcoin SPV Merkle Proofs and updates between non-zero allowances. The report also offers several suggestions for improvements, including code optimizations and enhancements to the test suite.

Chain Security
On November 09, 2021, ChainSecurity conducted a security audit of the Threshold Network system, assessing its smart contracts. While no critical or high-severity issues were identified, two medium-severity and eight low-severity concerns were found. The Threshold Network system, resulting from the merger of Keep Network and NuCypher, introduces a new native token called T. The audit also covered the Vending Machine, which facilitates token conversions, and the Staking Contract, supporting legacy staking contracts.

Certik
The Certik Audit report, conducted November 19, 2021, for the Threshold Network is specifically on VendingMachine.sol used to convert Nucypher’s $NU Token and Keep Network $KEEP contract to $T of Threshold Network. Findings range from informational to minor, including potential issues related to third-party dependencies and calculation accuracy. The report provides recommendations to enhance code quality and security, emphasizing the importance of monitoring third-party entities and using precise calculations for a robust and secure project.

4.1.2 Concerning Audit Signs

A summary of notable findings in the audit reports are listed below:

Least Authority (Issue) || Updates between Non-zero Allowances Can Result in Exploits
The audit by Least Authority identified a vulnerability related to how updates between non-zero allowances are managed in the Threshold Network. This flaw could have led to potential system exploits. The Threshold Network team has since addressed and resolved the issue.

Least Authority (Issue) || Bitcoin SPV Merkle Proofs Can Be Faked
Least Authority’s audit revealed that the tBTC Bridge v2 had a potential flaw where Bitcoin SPV Merkle proofs could be faked. Such a vulnerability might have jeopardized the integrity of Bitcoin transactions in the system. The Threshold Network team has addressed and rectified the issue.

Chain Security (Issue) || Ineffective Try Catch Statement
The audit pointed out an ineffective use of the try-catch statement in the authorizationDecrease function. Ideally, try-catch statements should effectively manage critical code segments that might fail. However, in this case, if the function isn’t successful, it fails silently, potentially leading to an incorrect authorization decrease. The Threshold Network Team has accepted the risk and introduced the AuthorizationInvoluntaryDecreased event to monitor involuntary decreases, which includes a field indicating the success or failure of the application call.

Least Authority (Suggestion) || Expand Data Type for Timestamp
On the 7th of February, 2106, the epoch timestamp will surpass the uint32 maximum limit, causing an overflow. To counter this, it was recommended to use a larger data type for the Unix timestamp. However, the Threshold Network team chose to retain the uint32 representation for gas efficiency reasons and did not implement the suggested change. As a result, this issue remains unresolved.

Least Authority (Suggestion) || Make Bank.sol and TBTC.sol Compliant with EIP-2612
The audit by Least Authority highlighted that the Bank and tBTC smart contracts weren’t compliant with the EIP-2612 standard. Such non-compliance posed a risk of incompatibility with certain third-party libraries. The Threshold Network team addressed the issue by updating the code, ensuring compatibility and resolving the concern.

4.1.3 Bug Bounty

Threshold Network has a Bug Bounty program with ImmuneFi.
Anyone who identifies vulnerabilities within the Threshold Network can earn rewards of up to $500,000, depending on the severity of the threat. The rewards are structured as follows:

• Smart Contracts:
  • Critical Level: $100,000 to $500,000
  • High Level: $10,000 to $50,000
  • Medium Level: $1,000 to $5,000
  • Low Level: $1,000
• Websites and Applications:
  • Critical Level: $10,000 to $25,000
  • High Level: $1,000 to $10,000
  • Medium Level: $1,000

4.1.4 Immutability

Below we depict a Immutability and Access Control Diagram for the key contracts associated with the tBTC v2 product. Contracts in Yellow represent Transparent Upgradeable Proxy Contracts.

Source: Manual Research || Etherscan

The three core contracts to the tBTC v2 product as previously highlighted in Section 1.2.3 Key Components are the Bank, Bridge and tBTC Vault. The Bank is central and non-upgradeable. Bridge can be upgraded via a Transparent Upgradeable Proxy. TBTCVault upgrade is a two-step process with a 24-hour governance delay.

4.1.5 Developer Activity

Developer Activity shows the extent to which the project is actively being developed. Artemis.xyz bases the calculation of Developer Activity on the Electric Capital Developer Report Framework. Weekly Commits tends to be a good proxy for developer productivity, as it represents the smallest unit of work of a developer. However, it should be noted that the length of a commit can vary significantly.

Threshold development encompasses 3 GitHub repos: Keep (has code for tBTC), nuCypher, and Threshold. The chart below left depicts the Weekly Commits of Developer Activity specifically for the Keep GitHub where development of tBTC is hosted. The chart below right depicts the Weekly Active Developers. A Developer is considered active if at least one commit has been pushed:

Source: Artemis.xyz

Both charts suggest sustained development suggesting stable development. However, there are somewhat few weekly active developers (most likely associated with the Core Development Team itself).

4.1.6 Smart Contract Maturity

The original tBTC v1 system was launched on 2020-09-15 and significantly influenced the subsequent tBTC v2 code, which was deployed on 2021-08-17. tBTC v1 held roughly 1900 BTC at its peak, while the current tBTC v2 holds about 2500 BTC. Given the substantial amount of BTC under custody in both versions, a successful breach of the Threshold Network constitutes a potentially significant bounty.

It should be noted that tBTC is under active development with a roadmap to implement features that enhance network decentralization and security. As the system develops, control is gradually being transferred from trusted individuals and a team multisig to either permissionless functionality or governance controlled by an on-chain DAO.

4.1.7 Previous Incidents

There have not been exploits that resulted in the loss of user funds. However, the Threshold Network has recently experienced a number of security challenges that have been addressed without incurring losses.

Denial-of-Service and Redemptions Vulnerability

An address tied to the FTX exploit transferred funds across projects, notably tBTC. This revealed two vulnerabilities:

Denial-of-Service Exploit:
The first challenge arose when an FTX-affiliated address made a BTC redemption request. While this request was initially approved, a subsequent request from another FTX-related address was unexpectedly obstructed. This obstruction was caused by a uniquely crafted BTC transaction from an unidentified source. These transactions misled the tBTC signing clients into believing that the wallets were preoccupied, effectively freezing all tBTC redemptions. The Keep development team formulated and implemented a patch to counteract this denial-of-service exploit.

Redemption Approval Vulnerability:
The second vulnerability was rooted in the Threshold DAO’s design, which currently permits delegation to only one approver address. This design flaw became evident when the exclusive US-based company, which had control over the address, was unable to sanction the FTX-associated redemption. To address this, a new system named “optimistic redemptions” has been proposed. Under this system, all redemptions would be deemed valid by default. However, specific addresses would have the authority to veto any redemption. While this approach may introduce minor delays in the redemption process, it promises enhanced security and adaptability.

GG18 Threshold Signing Scheme Vulnerability

There was a protocol level design vulnerability reported in August 2023 in the GG18 threshold signing scheme that was responsibly disclosed and remediated in tBTC prior to public disclosure. The vulnerability further motivated tBTC to transition to the FROST/ROAST signing algorithm.

Binance TSSShock Vulnerability

There was an implementation level vulnerability in Binance’s tss-lib library (TSSShock), that was responsibly disclosed although tBTC was not vulnerable. The vulnerability motivated Threshold’s decision to maintain it’s own version of tss-lib rather than rely on Binance’s version that has experienced multiple historical issues.

L2WormholeGateway Vulnerability

There was a critical vulnerability disclosed via Threshold’s bug bounty program related to the L2WormholeGateway contracts which was remediated.

Previous Incidient in tBTC v1

The Threshold Network was notified of two vulnerabilities in its threshold cryptography implementation in 2021, crucial for its privacy solutions and the tBTC application. Although no users or funds were compromised, the team swiftly released a fix and advised tBTC nodes to update. These vulnerabilities, linked to a Binance library fork used by many in the Web3 space, were highlighted by Trail of Bits. The Threshold team not only ensured all user ID numbers were secure but also proposed a successful fix to Binance’s library. This collaborative effort underscored the community’s commitment to security and cooperation. The Threshold Network team handled the situation quickly and professionally.

4.2 Product and Layer Composability

4.2.1 Dependencies

Bitcoin Relay

The primary dependency is the Bitcoin Relay mechanism designed to facilitate the verification of Bitcoin transactions on the Ethereum blockchain, specifically for the tBTC system. The core idea is to provide a way to prove Bitcoin deposits to an Ethereum smart contract, leveraging a simplified form of SPV (Simple Payment Verification) called Light Relay. Here’s a breakdown of its functionality and how it works:

1. Bitcoin Deposit Verification:
   • The primary function of the Light Relay is to allow a depositor to prove their Bitcoin deposit to an Ethereum smart contract. This is crucial for minting equivalent tokens on the Ethereum blockchain, as seen in the tBTC system.
2. SPV Proof:
   • The Light Relay employs a simplified version of SPV (Simple Payment Verification) to verify Bitcoin transactions. Unlike traditional SPV, which may require a significant amount of data, the Light Relay is optimized to reduce the amount of data needed for verification while still providing a reliable proof.
3. Utilizing Bitcoin’s Difficulty Adjustment:
   • The mechanism leverages Bitcoin’s difficulty adjustment feature to ensure the recency of the proof. By monitoring changes in Bitcoin’s mining difficulty, the Light Relay can provide a guarantee that the proof is relatively recent, which is crucial for ensuring the integrity of the cross-chain interaction.
4. Header Storage Optimization:
   • Instead of storing all block headers, which can be data-intensive, the Light Relay only stores certain headers related to difficulty adjustment. This selective storage significantly reduces the amount of data the Ethereum smart contract needs to handle and store, making the verification process more efficient and cost-effective.

How it Works:

1. Deposit and Proof Creation:
   • When a user makes a Bitcoin deposit intending to mint tBTC on Ethereum, they need to create a proof of this deposit.
2. Light Relay Interaction:
   • The depositor then interacts with the Light Relay on the Ethereum blockchain to submit this proof. The Light Relay is a smart contract that is capable of verifying Bitcoin transactions using the simplified SPV method.
3. Header Submission and Verification:
   • Relevant Bitcoin block headers, particularly those around difficulty adjustments, are submitted to the Light Relay. The Light Relay verifies these headers and the included proof against the stored headers and Bitcoin’s difficulty adjustment rules.
4. Recency Guarantee:
   • By examining the difficulty adjustment information within the submitted headers, the Light Relay can ensure that the proof is recent. This recency guarantee is crucial for mitigating certain types of attacks or fraud.
5. Proof Validation:
   • Once the Light Relay validates the proof, it confirms the Bitcoin deposit to the respective Ethereum smart contract. This confirmation triggers the minting of corresponding tokens (e.g., tBTC) on the Ethereum blockchain, completing the cross-chain interaction.
6. Optimized Header Storage:
   • Throughout this process, the Light Relay smart contract maintains an optimized set of Bitcoin block headers to facilitate future verifications, reducing the overall data and computational overhead on the Ethereum blockchain.

Wormhole Bridge for Layer 2

The collaboration between tBTC and Wormhole is set to significantly expand tBTC’s reach by enabling cross-chain compatibility with over 20 different ecosystems. This partnership encompasses two key components: a bridging mechanism and a liquidity bootstrapping campaign. Wormhole proposed this integration to the Threshold community in April, and it garnered strong support, receiving full approval on April 29th.

The integration will allow tBTC to seamlessly transfer to various blockchain environments, including Ethereum Virtual Machine (EVM) chains like Arbitrum and Polygon, as well as non-EVM chains like Solana and Cosmos. The bridging plan, based on RFC-8, enhances capital efficiency by minting tBTC on Ethereum and deploying native tokens for each new chain.

The L2WormholeGateway is a contract that enables the transfer of tBTC tokens between different blockchain ecosystems. It grants minting authority to the Wormhole Bridge for creating tBTC tokens on Layer 2 (L2) and sidechains. The process involves users locking their tBTC tokens on Layer 1 (L1), waiting for confirmation, and then minting equivalent tokens on L2. Conversely, users can burn tokens on L2, wait for confirmation, and unlock their tBTC tokens on L1. This contract is integrated into the bridging process and ensures that the proper amount of tBTC is created or destroyed during the transfer. It is designed to be upgradeable through a transparent proxy.

4.2.2 Withdrawals Processing

Source: Custom Diagram

The redemption process allows a user to convert their account balance into Bitcoin.

• Step 1: The user provides a Bitcoin address
• Step 2: The system deducts the equivalent amount from their account balance
• Step 3: The system transfers the corresponding Bitcoin to the user’s specified address from a redeeming Bitcoin wallet

There’s a maximum redemption size limit, determined by the largest wallet size, so if a user wants to redeem an amount exceeding this limit, they would need to split it into multiple redemption requests to ensure the process goes smoothly. There is also a delay involved to process the redemption that Threshold estimates as 3-5 hours.

4.3 Oracle Pricefeed Availability

4.3.1 Understanding the Oracle

tBTC does not currently have a Chainlink price feed available. The team have been working to establish one, as well as a Proof of Reserve that will verify BTC stored on the Bitcoin chain. Timeline for the Chainlink feed is not certain, although is planned in the near term.

crvUSD is able to list tBTC as collateral by using the Curve pool EMA as an oracle price feed. The CryptoWithStablePriceTBTC contract takes the crvUSD/wstETH/tBTC tripool EMA. The ma_time is set to ~6.9 minutes (the param value * ln(2) derives the ma_time in seconds). The crvUSD oracle takes an aggregated price of crvUSD paired against several stablecoins (USDC, USDT, USDP, and TUSD) multiplied by the EMA price reported by the tricrypto pool to produce a price that is referenced by the LLAMMA market AMM for liquidation processing.

4.3.2 Token Liquidity and Distribution

tBTC on-chain token liquidity on October 18 had 95% share of total liquidity on Curve DEX, mostly in the WBTC/tBTC and crvUSD/wstETH/tBTC pools (refer to section 3.2.2 Token On-chain Liquidity).

4.3.3 Attack Vectors

The oracle may become unreliable in certain circumstances:

High Dependency on a Single Protocol: The crvUSD integration relies heavily on its Curve crvUSD/wstETH/tBTC liquidity pool to derive a price feed. The system could become vulnerable in case of failure involving a bug in the pool contract or counterparty assets in the pool (e.g. wstETH). The reliability of the pricefeed is dependent on liquidity in the pool; if liquidity migrates to another venue, it may cause the pool be be vulnerable to manipulation.

Data Latency: The EMA oracle is set to quite a low value of 6.9 minutes. However, the oracle is inherently latent to make pool manipulation expensive. This is a suitable characteristic for crvUSD’s LLAMMA design, but may not be a suitable oracle for other integrations.

4.3.4 Associated Vulnerabilities

Bad Debt Creation: In a successful price feed manipulation attack, one direct impact could be the creation of bad debt for the protocol. Lending protocols rely on accurate price feeds to maintain appropriate collateralization ratios. If the price feed is manipulated to reflect an inaccurate price, attackers may perform malicious actions to create bad debt.

Faulty Liquidation: If an oracle is manipulated to drastically lower the price of a collateral asset in a lending protocol, it could trigger unjust liquidations of user positions, causing financial losses and disrupting the normal operations of the protocol.

Section 5: Counterparty Risk

This section addresses the persistence of tBTC’s properties from an ownership rights perspective (i.e. possession, use, transfer, exclusion, profiteering, control, legal claim). The reader should get a clear idea of (1) who can legitimately change properties of the collateral (e.g. minting additional units) and what their reputation is, (2) the extent that changes can be implemented and the effect on the collateral.

This section is divided into 3 subsections:

• 5.1: Governance
• 5.2: Economic Performance
• 5.3: Legal

5.1 Governance

5.1.1 Governance Scope

tBTC is undergoing a process of progressive decentralization in terms of its governance. There is an on-chain governance system that currently applies to processes related to the T token, but does not yet extend to direct governance of the tBTC system. As the network ossifies, the Threshold team plans to transfer control to an on-chain DAO of T tokenholders, but for now it is controlled by the Elected Council 6-of-9 multisig with token voting conducting via Snapshot.

Threshold is envisioned to be overseen by a community-driven DAO composed of members from the former NuCypher and Keep networks. This DAO comprises two main components: the Tokenholder DAO and the Elected Council. Each of these governance bodies has distinct responsibilities embedded within the overall governance framework.

Source: Threshold Docs

The Tokenholder DAO uses the Governor Bravo governance model, utilizing OpenZeppelin Governance, deployed on the Ethereum Mainnet at address 0xd101f2B25bCBF992BdF55dB67c104FE7646F5447. Meanwhile, the Elected Council is a 6-of-9 Gnosis Safe multisig, deployed at address 0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f.

Token voters are intended to govern key aspects of the system, including contract upgrades and parameter changes, while the Elected Council serves a precautionary veto role on potentially malicious governance actions. Currently, the Elected Council handle both responsibilities during the controlled tBTC roll-out. A visual representation of the intended governance architecture is displayed below.

Source: Threshold Docs

Vote Delegation

Vote delegation in DAO governance allows stakers or token holders to assign their voting power to a chosen delegate, who can either be themselves or a third party. This process doesn’t transfer the actual assets but merely the voting weight they represent within the Threshold DAO. Third-party delegates, who are active volunteers in Threshold governance, provide ETH addresses for others to delegate their voting power. These delegates then represent the community by voting on governance proposals. For those community members less involved in daily governance, they can delegate their votes to these proactive DAO members, ensuring their voices are still heard indirectly. It’s worth noting that there’s no financial compensation for third-party delegates, and currently, tokens in AMM pools, like Curve, cannot be delegated, though this may change in the future.

Guilds

The Threshold DAO has three community-led guilds: Marketing, Integrations, and Treasury. Each guild is managed by an elected committee and holds regular elections. The Treasury Guild manages the DAO’s finances, including liquidity and treasury diversification. The Integrations Guild focuses on building partnerships with other protocols and organizations, while the Marketing Guild is responsible for marketing, community growth, and education about Threshold’s services and value. Members can join these guilds based on their interests and expertise.

Governance process

In the Threshold community’s Proposal Community Process, ideas transition through four steps:

1. Temperature Check: Members post proposals on forums, engage in discussions to gain support, and pass an offchain snapshot vote with no minimum token threshold.
2. Proposal Creation: A member with adequate vote or stake weight submits the proposal on-chain, initiating a two-day vote delay.
3. Vote Period: Voting lasts 10 days, moving to the next step if passed or being cancelled if failed. Modified proposals can be reintroduced with changes.
4. Execution: Approved proposals are executed by the designated GovernorBravo instance.

5.1.2 Access Control

Most contracts are owned or indirectly owned by the 6-of-9 Council multisig. Below we depict a Immutability and Access Control Diagram for the key contracts associated with the tBTC v2 product.

Source: Manual Research || Etherscan

The Threshold Council is composed of 9 members. The original council includes 4 members elected from the original Keep community, 4 members elected from the original NuCypher community and 1 member mutually appointed by both teams to ensure neutrality. The current elected council members are:

Source: Threshold Forum

Access Control Scope on the core contracts, currently operated by the above multisig, include:

Bank

• The onlyOwner modifier allows the owner to upgrade the Bridge address. This function does not implement any governance delay and does not check the status of the Bridge, implying that the owner needs to ensure all requirements for the upgrade are satisfied before executing this function.

tBTC Vault

• The owner can initiate and finalize upgrades to a new vault and recover mistakenly sent ERC20 and ERC721 tokens from both the tBTC token contract address and the vault address.

Bridge

• This contract is an upgradeable Proxy
• The onlyGovernance modifier allows the owner to mark vault addresses and SPV maintainer addresses as trusted or not, update deposit and redemption parameters, update moving funds parameters, update wallet parameters, update fraud parameters, and update the treasury address.

5.1.3 Distribution of Governance

Token governance is currently conducted via Snapshot until on-chain governance is transferred to tokenholders. The Threshold Snapshot specifies eligible voters as liquid and staked T Tokenholders.

Source: Snapshot

The T token distribution provides some insights into the governance power distribution.

Source: Etherscan || Manual labeling with Arkham/ Publicly Available Resources

Overall, a significant share of the T supply is on centralized exchanges. Nevertheless, a strong ~28% is locked into the staking contract. T used in governance could change any time as the VendingMachine.sol contracts enable $KEEP and $NU Holders to exchange their Tokens for T.

T delegates and their vote power can be seen on the Boardroom DAO voting page. The top 6 voters make up over 50% of the total vote power.

5.1.4 Proposal Frequency

On average, there were around 3.25 proposals per month on Snapshot, with a standard deviation of approximately 2.07, signifying some variation in monthly submission rates. The data ranged from a minimum of 1 proposal to a maximum of 9 proposals per month, demonstrating the diversity in activity.

The median stood at 3 proposals per month, providing a sense of the typical month. Additionally, the 25th percentile, at 1.75 proposals, and the 75th percentile, at 4.25 proposals, offer lower and upper boundaries for the middle half of the data, respectively. Overall, there seems to be sustained submission of proposal suggesting lasting activity.

Historical Vote Topics

We extract key terms using tf-idf from the body of snapshot votes. The scope of governance based on the proposal can be summarized into the following overarching categories:

Source: Threshold Snapshot

5.1.5 Participation

Threshold Network has an active forum with 292 total registered users. The participation can be summarized as follows:

Source: Threshold Forum

The participation translates somewhat to votes (randomly selected subset of proposals by Tally):

Source: Tally

As the tables indicate, participation is one-sided (little no votes) with a small set of addresses actively voting. It should be noted that votes can be delegated.

5.2 Economic Performance

5.2.1 Revenue Source

Revenue for tBTC v2 comes from minting and redemption fees. These can directly be queried on-chain in the Bridge Smart Contract.

Deposit fees are currently 0.1%.

Redemption fees are currently 0.2%.

Source: Etherscan

5.2.2 Revenue

The TimelockController contract is set as the protocol treasury and is the recipient of all fees. Since 1/31/2023, the contract has received a total of 4.85 tBTC (as of 10/31/2023). The annualized revenue, based on this figure, is a total revenue of 6.46 tBTC worth $223k.

5.2.3 Net Profit

Operational costs as of now are not clear. Some resources are available but no balance sheet is provided. Some insight can be gained from the forum thread where DAO contractors post their salary publicly - typically these range from USD 30,000 to USD 40,000 per month (or equivalent) across 5 contributors.

5.3 Legal

5.3.1 Legal Structure

In general Threshold Network operates as DAO. The DAO has a Cayman Foundation, the Threshold Foundation. Legal structures can also be found behind the contributing development teams (Nucypher & Keep), the two former networks which merged.

Keep SEZC (now Keep Ltd)

Keep SEZC (now Keep Ltd) is a corporation located in Grand Cayman, under the state jurisdiction of E9. It has been assigned the Employer Identification Number (EIN) 000330025, which is sometimes also referred to as a Taxpayer Identification Number (TIN) or IRS Number. This corporation is among those that submit 10-K filings to the U.S. Securities and Exchange Commission (SEC). The Central Index Key (CIK) for Keep Ltd is 1808274, a unique identifier used by the SEC’s computer systems to recognize corporations and individuals who have filed disclosures with the SEC.

Keep Ltd’s (https://eintaxid.com/company/000330025-keep-sezc/) is listed as Floor 4, Willow House, Cricket Square, Grand Cayman, with the postal code KY1-9010. Their business phone number is 650-513-2125.

Moreover, a filing in the Grand Court of the Cayman Islands regarding Keep SEZC has been mentioned, indicating a legal proceeding or restoration application, although the specifics of this case were not detailed.

Nucypher

NuCypher is a cryptography company that provides privacy-preserving infrastructure and protocols, with its headquarters located in San Francisco, California. It was founded by MacLane Wilkison and Michael Egorov in 2015. The firm offers decentralized proxy re-encryption services and is recognized for its contributions to decentralized encryption, access control, and key management systems on public blockchains. Furthermore, NuCypher provides end-to-end encrypted data sharing solutions on public blockchains, as well as decentralized storage solutions.

In terms of legal and incorporation details, NuCypher operates under the legal name ZeroDB, Inc. The last funding type registered by the company was an Initial Coin Offering (ICO).

5.3.2 Licenses

The Cayman Islands Virtual Asset Service Providers (VASP) Act enumerates several exemptions, inclusive of:

• platforms which are mere meeting places where sellers and buyers may post bids and offers and where the parties trade in a peer-to-peer environment only;
• fintech service providers that use innovative technology to improve, change or enhance financial services but which are not virtual asset services; and
• virtual service tokens which are not transferable or exchangeable and include tokens whose sole function is to provide access to an application or service.

Cross-chain bridges might be construed as legitimate exceptions under the provisions of the VASP Act, courtesy of their pivotal role in enabling smooth interoperability amongst disparate blockchain networks, sans engagement in core exchange services as delineated by the VASP Act. However, there is an absence of publicly available data concerning exemptions specifically advantageous to Threshold Network, nor is there any disclosure of pertinent documentation, such as legal opinions or non-action letters, to the public domain. The publicly available information does not provide details on any specific licenses held by the Threshold Network.

5.3.3 Enforcement Actions

Threshold does not appear on the public Crypto Assets and Cyber Enforcement Actions List. Furthermore, we have yet to find specific information on lawsuits against Threshold Network brought by other regulators.

5.3.4 Sanctions

We did not find specific information on how Threshold Network complies with OFAC sanctions and other international sanctions programs. It’s possible that there might not be public records of measures taken by the protocol to adhere to certain regulatory frameworks and cooperate with authorities.

5.3.5 Liability Risk

Given the nature of blockchain networks and cryptocurrency platforms, liability risks might be inherent, yet no explicit mention has been identified. The liability risk associated with utilizing the platform remains elusive for an in-depth examination, primarily due to the non-disclosure of the operating entity managing the platform and its ensuing obligations towards end-users. Notably absent are the Terms & Conditions/Terms of Use for the platform—documents that traditionally delineate the boundaries of liability for the interacting parties, enumerate user rights, disclaimers, waivers, risk warning and the like. This lack of accessible legal framework may leave users without a clear understanding or avenue to ascertain the extent of liability risks they may be incurring upon engagement with the platform.

5.3.6 Adverse Media Check

We were unable to find any adverse media reports or allegations related to money laundering, corruption, sanctions exposure, threat financing, or involvement in illegal activities associated with Threshold Network. We leave it to the reader to keep monitoring reputable news outlets or regulatory announcements for any updates concerning Threshold Network.

Section 6: Risk Management

This section will summarize the findings of the report by highlighting the most significant risk factors in each of the three risk categories: Market Risk, Technology Risk, and Counterparty Risk.

6.1.1 Market Risk

LIQUIDITY: Does the token have a liquid market that can facilitate liquidations in all foreseeable market events?

Care must be take to monitor tBTC liquidity, as it is still in a bootstrapping phase with a comparatively low market cap when compared with the sector leader (WBTC). Threshold have been actively implementing partnerships to expand liquidity, especially in the Curve pools, with POL and liquidity incentives.

A substantial amount of tBTC supply is deposited as collateral for crvUSD (727 tBTC or 30% of total supply), and is also the only DeFi market where tBTC can be used as collateral currently. The max crvUSD debt is 50m, which constitutes around 60% of the current tBTC market cap. While unlikely to cause liquidity issues in the short term (tBTC leverage is quite conservative for now), there could be a situation where liquidity is insufficient to process liquidations, and that could result in bad debt to the lending protocol.

VOLATILITY: Has the asset had any significant depeg events?

During the time period we observed since mid-August, tBTC tends on average to close approximately 0.1145% lower than its underlying asset, with some daily variations. The most significant negative deviation observed during this period was approximately -1.52%, while the most significant positive deviation was around 1.21%.

Overall, tBTC has exhibited a strengthened peg after implementing redemptions in July 2023. Deposits and withdrawals are permissionless, always available during normal operation, and involve a relatively modest wait period. Deposit fees are 0.1% and redemption fees are 0.2% currently, creating reasonable confidence in a BTC peg bounded between +0.1% and -0.2%.

6.1.2 Technology Risk

SMART CONTRACTS: Does the analysis of the audits and development activity suggest any cause for concern?

There are substantial challenges in designing a highly secure, permissionless bridge protocol. tBTC is a novel solution with a unique system design that may increase the chance of containing smart contract bugs. It has been live on mainnet for several years, including tBTC v1, and has undergone a controlled roll-out to mitigate the chance of user losses. The roll-out has involved a gradual introduction of features like redemptions and striking a balance between permissioned operations and Guardian monitoring with permissionless access to the protocol. There have been several audits of the protocol and there is an active bug bounty program. Despite having a history of some vulnerability disclosures, the protocol has not suffered any user losses.

DEPENDENCIES: Does the analysis of dependencies (e.g. oracles) suggest any cause for concern?

As a bridge protocol, there are a substantial amount of external dependencies required to keep the network secure. tBTC depends on a network of nodes to reliably relay BTC locked on the Bitcoin network, to approve minting of tBTC on Ethereum, and to custody BTC on the Bitcoin network.

There are currently limitations of the GG18 threshold signing scheme that prevent identification of misbehaving signers. A new algorithm, FROST/ROAST, is in development which will allow the network to expand its node operator set and strengthen network security. A permissioned set of Minters and Guardians process eligible mints and play a role in preventing unauthorized mints/redemptions. A 51-of-100 threshold ECDSA wallet facilitates shared custody of BTC by the network nodes.

There is not yet a Chainlink pricefeed available for tBTC, although the team have been actively working to implement one for ease of integration with lending platforms and other DeFi integrations. The Curve EMA is suitable for the crvUSD market, but has a high dependence on liquidity and reliable operation of the single Curve pool from which the price is derived.

6.1.3 Counterparty Risk

CENTRALIZATION: Are there any significant centralization vectors that could rug users?

While minting tBTC does involve a permissioned set of Minters and Guardians (EOA addresses) that facilitate expedited minting, users can still have their transactions processed even if these actors are hostile or negligent through permissionless sweeps. It’s possible a rogue Minter attempts to maliciously mint tBTC, but so long as there is 1 live and honest Guardian, the minter can be blocked (there is currently an optimistic minting delay of 1 hour).

The Elected Council 6-of-9 multisig has ownership privilege of the Ethereum-based contracts, and although it has significant operational control of the contracts, it does not have access to BTC custodied on the Bitcoin network. Ultimately, the bridge node operators maintain shared custody of user funds, of which there are a substantial number in the hundreds.

LEGAL: Does the legal analysis of the protocol suggest any cause for concern?

The strategic decision to utilize a Cayman Foundation for the off-chain representation of the DAO taps into the recognized legal framework of an internationally endorsed jurisdiction, potentially offering a layer of credibility and stability. While certain features of Threshold Network’s operations, i.e. cross-chain bridges, might be eligible for exemptions under the Cayman Islands VASP Act, the absence of specifics regarding Threshold’s compliance status injects a degree of regulatory uncertainty. Moreover, the fluid nature of legal and regulatory landscapes across various jurisdictions presents a challenge, as these frameworks are subject to frequent changes, diverse interpretations, and sometimes conflicting applications, adding layers of complexity to the protocol’s compliance efforts.

The absence of accessible legal documents on the general user interface, such as Terms & Conditions, creates ambiguity around the liability risk for both the platform operators and users. Without explicit disclaimers or user agreements, it is challenging to ascertain the scope of liability and user rights, which could lead to potential legal disputes.

6.1.4 Risk Rating

Based on the risks identified for each category, the following chart summarizes a risk rating for tBTC as collateral. The rating for each category is ranked from excellent, good, ok, and poor.

• We rank tBTC ok on liquidity since it is still in a bootstrapping phase and is currently a minor tokenized BTC asset. A significant amount of the tBTC supply is being used as collateral in crvUSD compared to available DEX liquidity, which is highly concentrated in Curve pools.
• We rank tBTC good in volatility due to the permissionless ease of mints/redemptions that facilitate arbitrage, with a small fee charged on each action. tBTC has exhibited strong peg strength since redemptions were activated in July 2023.
• We rank tBTC ok in smart contracts since the protocol is still undergoing a gradual roll-out and that may involve further updates to the protocol design.
• We rank tBTC ok in dependencies as it involves significant off-chain processes that introduce complexity to the system. There is a Curve EMA oracle available, but not yet a Chainlink oracle.
• We rank tBTC good in decentralization for prioritizing permissionless access, a decentralized bridge network, and a reasonably convincing pathway to on-chain governance.
• We rank tBTC ok in legal as the legal structure(s) domicile in a prominent jurisdiction, while no enforcement actions against Threshold are evident. Clarifying the legal status of cross-chain bridges and fortifying the protocol’s defenses could be better implemented.

The most immediate concern for tBTC use as collateral is ensuring there is sufficient liquidity in all market conditions to facilitate liquidation. Over 30% of the tBTC supply is used as collateral in crvUSD while a combined 21.11% resides in the Curve WBTC/tBTC and crvUSD/wstETH/tBTC liquidity pools. These are the primary DEX trading venues for tBTC. tBTC leverage is currently quite conservative, but the crvUSD market allows a max 50m crvUSD debt in the tBTC market, which is 60% of the current tBTC market cap and 2.86x the token liquidity supplied to the aforementioned Curve pools.

In case of an extreme market event that causes tBTC to depeg due to liquidation demand in excess of available liquidity, tBTC can be readily redeemed to arb the peg. However, this process is not immediate. There is a delay involved with redemption that can take 3-5 hours with a redemption fee (set at 0.2%).

As Threshold is responsibly conducting a gradual roll out of the protocol to mitigate unforeseen issues, Curve and other DeFi platforms integrating tBTC should also take a conservative stance to onboarding tBTC as a collateral type. While tBTC is suitable collateral for crvUSD, given it has sufficient liquidity to derive a reliable price from the pool’s EMA oracle, we believe a conservative approach to setting the debt ceiling is advisable. The DAO should consider reducing max debt to a value consistent with tBTC supply and liquidity expectations and gradually increase the value along with observed adoption of the protocol.

Disclaimer：

1. This article is reprinted from [hackmd.io]. All copyrights belong to the original author [Llama Risk]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.