Threshold Network powers tBTC, the Bitcoin standard in finance, and the most decentralized 1:1 tokenized Bitcoin.

tBTC enables Bitcoin liquidity to move seamlessly across chains without compromising settlement finality. Built on threshold cryptography and secured by a rotating network of independent node operators, it distributes control of Bitcoin so that no single entity can act alone on funds.

This structure upholds Bitcoin’s core principles of being trust-minimized, permissionless, and censorship-resistant while maintaining a direct and verifiable path back to native Bitcoin. No complex staking mechanics needed.

Threshold Network's T token is the value accrual and governance asset for the network.

The next pages cover the complete setup process for a tBTC v2 node. Two installation methods are supported, Docker and binary, each with its own configuration flow. Choose the method that aligns with your infrastructure standards, then follow the step-by-step instructions to bring your node online and connect it to the Threshold Network.

Staking T tokens secures the Threshold Network and enables stakers to get fee waivers/rebates on tBTC mint and redemption fees. Stakers receive direct rebates from real protocol activity, with no inflationary emissions or token unlocks involved.

T Staking for tBTC Fee Rebates/ Waivers

Since the beginning of 2026, T token holders have been able to stake their T to receive fee rebates and waivers when minting tBTC and redeeming BTC. With the reinstatement of minting fees, staking T has become even more valuable for reducing costs when using tBTC on the Threshold Bridge.

The Explorer page in the app will continue to display rebates or fee waivers earned through staking T. Because rebates now apply to both minting and redemption fees, they will appear across both transaction types.

Staking T (Threshold Tokens) returns a share of the tBTC mint and redemption fees to stakers as rebates. The breakdown below shows exactly how much you can save at each fee tier, giving you a clear basis to evaluate whether staking T offsets the cost of your expected tBTC activity.

$T is available on most decentralized exchanges and major centralized exchanges, giving anyone a path to participate. Staking T is the operational backbone of Threshold Network: stakers provide the security that backs tBTC and earn a share of every fee the protocol generates, aligning incentives between the network and the people who secure it.

Verifiable Bitcoin Accounts (VBA) are how institutions use Bitcoin without compromise, enabling deployment into onchain lending and yield markets while preserving existing custody arrangements.

Built on Threshold Network's battle-tested signer infrastructure, Verifiable Bitcoin Accounts (VBA) is purpose-built for custodians, institutional allocators, asset managers, family offices, hedge funds, corporate treasury teams, and other organizations. It delivers segregated custody, verifiable UTXOs, direct access to onchain yield/ lending markets, and an optional legal framework.

Every spending condition, recovery path, and migration rule is encoded in Bitcoin Script - verifiable onchain, and auditable by design.

Configuration options for logging

Application configuration can be stored in a file and passed to the application with the --config flag.

Client information exposed by the tBTC v2 client.

Logging can be configured with environment variables. Please see sample settings:

Certain errors may be reported by your node. See a sample below:

When the pool is locked, new operators cannot join but sortition (selecting operators from the pool) is possible. When the pool is unlocked, new operators can join but the sortition is not possible. Once the first set of Signers is registered, the pool will get locked for some time to allow the sortition. After some time, when another set of Signers are added, the pool will be unlocked again.

Here you'll find the version of the Threshold dapp.

Before initializing the tBTC SDK instance in your project, you need to answer the following questions:

• What Bitcoin network and which tBTC contracts do you plan to interact with?

• Do you want to perform just read-only actions or send transactions as well?

Answering those questions will allow initializing the SDK in the right way. The SDK is prepared to handle common use cases but provides some flexibility as well. This guide explains that in detail.

The SDK addresses it by exposing the TBTC.initializeSepolia function. That function:

• Takes an Ethers signer or provider as a parameter and uses it to interact with tBTC contracts deployed on Ethereum Sepolia

• Automatically configures an Electrum Bitcoin client to communicate with the Bitcoin testnet (communication is done through a set of pre-configured Electrum servers)

Another core feature of the tBTC bridge is unminting (burning) TBTC tokens and redeeming BTC in return. This guide explains how to perform this process using the SDK.

Initialize the SDK

First, initialize the SDK, as described in the Initialize SDK guide.

Request redemption

Once the SDK is initialized, you can unmint and request for redemption in the following way:

import { TBTC } from "@keep-network/tbtc-v2.ts"
import { BigNumber } from "ethers"

// Initialized SDK.
const sdk: TBTC

// Set the P2WPKH/P2PKH or P2WSH/P2SH Bitcoin redeemer address. This is the
// address where redeemed BTC will land.
const bitcoinRedeemerAddress: string = "..."

// Set the desired redemption amount using 1e18 precision. No need to do an 
// explicit approval on the TBTC token upfront.
const amount = BigNumber.from(5 * 1e18)

// Request redemption. This action will burn TBTC tokens and register a
// redemption request in the bridge. Returns the hash of the request redemption
// transaction and the target wallet public key that will handle the redemption.
const {
  targetChainTxHash,
  walletPublicKey
} = await sdk.redemptions.requestRedemption(bitcoinRedeemerAddress, amount)

IRelay

Contains only the methods needed by tBTC v2. The Bitcoin relay provides the difficulty of the previous and current epoch. One difficulty epoch spans 2016 blocks.

getCurrentEpochDifficulty

function getCurrentEpochDifficulty() external view returns (uint256)

Returns the difficulty of the current epoch.

getPrevEpochDifficulty

function getPrevEpochDifficulty() external view returns (uint256)

Returns the difficulty of the previous epoch.

TBTC

constructor

constructor() public

Liquid T holders can delegate their token weights to themselves or a third party for voting on governance proposals.

1. Go to https://boardroom.io/threshold.

2. Connect your wallet.

3. Click "Set Up Delegation".

4. Select your "Delegation Type" - either to yourself or a third party.

5. Enter "Delegate Address" and click on "Delegate Votes".

6. Sign the transaction.

The client requires an Ethereum Key File of an Operator Account to connect to the Ethereum chain. This account is created in a subsequent step using Geth (GoEthereum).

The Ethereum Key File is expected to be encrypted with a password. The password has to be provided in a prompt after the client starts or configured as a KEEP_ETHEREUM_PASSWORD environment variable.

The Operator Account has to maintain a positive Ether balance at all times. We strongly advise you monitor the account and top-up when its balance gets below 0.5 Ether.

Install Geth (GoEthereum)

To create a new Ethereum account, install Geth (GoEthereum) and create a new account using the command below. This account will subsequently be referred to as the Operator Account.

geth account new --keystore /home/$USER/.operator-key

When prompted, provide a password to protect the operator key file.

Once the process completes, your public key will be displayed. Take note of your Operator Account public key.

Your Operator Account will need to maintain a positive ETH balance at all times to ensure proper operation and availability of your tBTC v2 node.

Required Ports

The node has to be accessible publicly to establish and maintain connections with bootstrap nodes and discovered peers. The node exposes metrics and diagnostics services for network health monitoring purposes. Update firewall rules as necessary, including application level firewalls for the following ports

An Announced Address is a layered addressing information (multiaddress/multiaddr) announced to the Threshold Network that is used by peers to connect with your node, e.g.: /dns4/bootstrap-0.test.keep.network/tcp/3919 or /ip4/104.154.61.116/tcp/3919.

If the machine you’re running your node is not exposing a public IP (e.g. it is behind NAT) you should set the network.AnnouncedAddresses (flag: --network.announcedAddresses) configuration property to addresses (ip4 or dns4) under which your node is reachable for the public.

To read more about multiaddress see the .

The client requires two persistent directories. These directories will store configuration files and data generated and used by the client. It is highly recommended to create frequent backups of these directories. Loss of these data may be catastrophic and may lead to slashing.

Create folders for tBTC v2 client

cd /home/$USER/
mkdir keep
cd keep
mkdir storage config

The tBTC v2 client will create two subdirectories within the storage directory: keystore and work. You do not need to create these.

The keystore subdirectory contains sensitive key material data generated by the client. Losing the keystore data is a serious protocol offense and leads to slashing and potentially losing funds.

The work directory contains data generated by the client that should persist through client restarts or relocations. If the work data are lost, the client will be able to recreate them, but it is inconvenient due to the time needed for the operation to complete, and may lead to losing rewards.

Assuming for the root user with the command provided in the step, the operator-key file should be located in the /.operator-key directory.

Contained within the operator-key directory is the account key file (operator key file), its name will be similar to the following: UTC--2018-11-01T06-23-57.810787758Z--fa3da235947aab49d439f3bcb46effd1a7237e32

Copy (not move!) this account key file to the config directory created above

tBTC SDK is a TypeScript library that provides effortless access to the fundamental features of the tBTC Bitcoin bridge. The SDK allows developers to integrate tBTC into their own applications and offer the power of trustless tokenized Bitcoin to their users.

The SDK documentation consists of the following parts:

• Quickstart

• Architecture

For a high-level overview of the tBTC protocol, please see the section.

The following diagram presents the architecture of the tBTC SDK and its place in the ecosystem:

As you can see, the SDK consists of several major parts:

• TBTC component

• Feature services

• Shared libraries

The TBTC component is the main entry point to the SDK. It provides different ways to initialize the SDK that are supposed to address the common use cases (see guide to learn more). Moreover, the TBTC component gives access to the SDK core features through feature services as well as low-level direct access to the underlying tBTC smart contracts and Bitcoin network client.

The SDK feature services provide seamless access to the core features of the tBTC bridge. The most important features of the SDK are:

• Deposits: deposit and mint flow for BTC depositors

• Redemptions: unmint and redeem flow for TBTC redeemers

• Maintenance: authorized maintenance actions for maintainers (e.g. optimistic minting guardians)

Shared libraries are reusable modules that provide cross-cutting concerns leveraged by multiple feature services and the TBTC component. The main shared libraries of the SDK are:

• Bitcoin: interfaces and utilities necessary to interact with the Bitcoin chain

• Contracts: chain-agnostic interfaces allowing interaction with tBTC smart contracts

• Electrum: Electrum-based implementation of the Bitcoin client

The SDK addresses it by exposing the TBTC.initializeMainnet function. That function:

• Takes an Ethers signer or provider as a parameter and uses it to interact with tBTC contracts deployed on Ethereum mainnet

• Automatically configures an Electrum Bitcoin client to communicate with the Bitcoin mainnet (communication is done through a set of pre-configured Electrum servers)

The following code snippet presents the usage of this function:

EcdsaLib

compressPublicKey

function compressPublicKey(bytes32 x, bytes32 y) internal pure returns (bytes)

Converts public key X and Y coordinates (32-byte each) to a compressed public key (33-byte). Compressed public key is X coordinate prefixed with 02 or 03 based on the Y coordinate parity. It is expected that the uncompressed public key is stripped (i.e. it is not prefixed with 04).

Parameters

IReceiveBalanceApproval

IReceiveBalanceApproval is an interface for a smart contract consuming Bank balances approved to them in the same transaction by other contracts or externally owned accounts (EOA).

receiveBalanceApproval

function receiveBalanceApproval(address owner, uint256 amount, bytes extraData) external

Called by the Bank in approveBalanceAndCall function after the balance owner approved amount of their balance in the Bank for the contract. This way, the depositor can approve balance and call the contract to use the approved balance in a single transaction.

The implementation must ensure this function can only be called by the Bank. The Bank does not guarantee that the amount approved by the owner currently exists on their balance. That is, the owner could approve more balance than they currently have. This works the same as Bank.approve function. The contract must ensure the actual balance is checked before performing any action based on it.

Existing solutions that bridge Bitcoin to DeFi require users to send their Bitcoin to an intermediary in exchange for an IOU token representing the original asset. This centralized model requires you to trust a third party and is susceptible to censorship, threatening the premise of Bitcoin as a sovereign, secure, permissionless digital asset.

In contrast, tBTC is a decentralized and trust-minimized bridge between Bitcoin and DeFi. It provides Bitcoin holders with secure, open access to the broader DeFi ecosystem, allowing you to unlock the value of your Bitcoin by borrowing and lending, minting stablecoins, providing liquidity, and more.

Instead of centralized intermediaries, tBTC uses a randomly selected group of operators running nodes on the Threshold Network to secure deposited Bitcoin through . tBTC requires a threshold majority agreement before operators can perform any action with your Bitcoin.

By rotating the selection of operators bi-weekly, tBTC protects against any individual or group of operators colluding to fraudulently seize the underlying deposits. By relying on an honest-majority assumption, we can calculate the likelihood of any wallet comprised of a quorum of dishonest operators.

Sweeping is an accounting optimization for tracking Bitcoin deposits in tBTC contracts. It involves periodically consolidating recent Bitcoin deposits into a single Unspent Transaction Output (UTXO) for a more optimal commitment cadence to Ethereum. This process simplifies tracking associated public keys and refund time locks while also helping prevent supply peg disruption. Typically, Sweeping runs every 8 hours, depending on the volume and size of deposits.

When a user makes a deposit, they lock the funds using our . This creates an Unspent Transaction Output ().

Typically, the job of a bitcoin "wallet" (wallets don't exist in the same way they do on Ethereum) is to scan the blockchain for specific locking script patterns it thinks it can unlock (like a associated with your public key) and sum up the relevant funds. When you want to send someone else bitcoin, the wallet software figures out which UTXOs to unlock to send to them so that you don't have to.

If we wanted to be able to redeem bitcoin deposits, we would need to track which deposits are associated with which public keys, the same way that wallet software does; this is a headache, especially from a bitcoin mining fee perspective.

Here are some things you will need before you start the minting process: What you need:

✅ At least 0.01 Bitcoin (BTC)

✅ Bitcoin compatible wallet (self-custodied)

✅ Destination Wallet (on supported chains; see the list of supported chains .) Important Reminders:

1. Forum discussion: A Threshold community member posts a potential proposal on the Threshold governance forums. Community members who post the initial proposal are encouraged to get active in Meta governance discussions within the community on forums and in Discord to earn support for the proposal. There is no minimum token threshold required to create a new proposal on the forums. Community mods reserve the right to moderate spam proposals during this stage by deleting the proposal from the forums.

2. Temperature Check: Once a potential proposal has enough traction and discussion within the community, it can proceed for a temperature check via an off-chain . If a proposal receives majority support during the temperature check, it is eligible to move onto the next step.

The client exposes metrics and diagnostics on a configurable port (default: 9601) under /metrics and /diagnostics resources.

The data can be consumed by Prometheus to monitor the state of a node.

The client exposes the following metrics:

Here you can find instructions explaining how to use the SDK in your own project.

To install the tBTC SDK in your project, run:

Please note that you will also need to install the library to initialize a signer or provider. To do so, invoke:

Here is a brief example demonstrating the use of the SDK in Ethereum:

The SDK addresses it by exposing the TBTC.initializeMainnet function. That function:

• Takes an Ethers signer or provider as a parameter and uses it to interact with tBTC contracts deployed on Ethereum mainnet

• Needs to receive as a second parameter the value true to activate the crosschain mode.

The main feature of the tBTC bridge is depositing BTC and using it to mint the ERC-20 TBTC token. This guide explains how to perform this process using the SDK.

First, initialize the SDK, as described in the guide.

Once the SDK is initialized, you can initiate the deposit and get their Bitcoin address in the following way:

The next step is doing the actual Bitcoin deposit transaction to the deposit address. There are two possible ways to do so:

• Recommended: Use an external Bitcoin wallet

IVault is an interface for a smart contract consuming Bank balances of other contracts or externally owned accounts (EOA).

Called by the Bank in increaseBalanceAndCall function after increasing the balance in the Bank for the vault. It happens in the same transaction in which deposits were swept by the Bridge. This allows the depositor to route their deposit revealed to the Bridge to the particular smart contract (vault) in the same transaction in which the deposit is revealed. This way, the depositor does not have to execute additional transaction after the deposit gets swept by the Bridge to approve and transfer their balance to the vault.

The implementation must ensure this function can only be called by the Bank. The Bank guarantees that the vault's balance was increased by the sum of all deposited amounts before this function is called, in the same transaction.

Please review this document in its entirety prior to beginning setup of your node to familiarize yourself with the general setup process.

Important Considerations

The Threshold Network expects certain capabilities for each node running on the network. To help attain these capabilities consider the following criteria:

• It is paramount that tBTC v2 nodes remain available to the Network. We strongly encourage a stable and redundant internet connection.

• Equally important is machine uptime and reliability. A VPS is strongly recommended.

• A connection to a production grade self-hosted or third party Ethereum node deployment.

• Persistent and redundant storage that will survive a VM or container rotation, and a disk failure.

• Each node running on the network requires a unique Ethereum Operator Account. The account has to maintain a positive Ether balance at all times.

• Each node running on the network requires a unique IP address or a unique application port running under the same IP.

Your operating environment will ultimately dictate what machine type to go with. This is particularly relevant if you’re running a containerized solution where multiple applications are sharing VM resources. The below types are sufficient for running one instance of the tBTC v2 Node.

The preferred OS is Ubuntu.

A Keep Node requires a connection to a WebSocket Ethereum API. You should obtain a WS API URL from a service provider (e.g. , , ) or run your own Ethereum node (e.g. ).

Starting from version v2.0.0-m3 , the Keep Node interacts with the Bitcoin network through an Electrum protocol server. You can use one of the publicly available servers or run your own. The URL of the chosen server should be passed under the bitcoin.electrum section of the configuration. If no Electrum server is set explicitly in the bitcoin.electrum configuration section, the Keep Node will randomly pick one server from its embedded server list, appropriate for the Bitcoin network the Keep Node is currently running against.

The client expects configuration options to be passed as CLI flags or specified in a . If you specify an option by using a parameter on the command line, it will override the value read from the configuration file.

Heartbeat

The library establishes expected format for heartbeat messages signed by wallet ECDSA signing group. Heartbeat messages are constructed in such a way that they can not be used as a Bitcoin transaction preimages.

The smallest Bitcoin non-coinbase transaction is a one spending an OP_TRUE anyonecanspend output and creating 1 OP_TRUE anyonecanspend output. Such a transaction has 61 bytes (see BitcoinTx documentation): 4 bytes for version 1 byte for tx_in_count 36 bytes for tx_in.previous_output 1 byte for tx_in.script_bytes (value: 0) 0 bytes for tx_in.signature_script 4 bytes for tx_in.sequence 1 byte for tx_out_count 8 bytes for tx_out.value 1 byte for tx_out.pk_script_bytes 1 byte for tx_out.pk_script 4 bytes for lock_time

The smallest Bitcoin coinbase transaction is a one creating 1 OP_TRUE anyonecanspend output and having an empty coinbase script. Such a transaction has 65 bytes: 4 bytes for version 1 byte for tx_in_count 32 bytes for tx_in.hash (all 0x00) 4 bytes for tx_in.index (all 0xff) 1 byte for tx_in.script_bytes (value: 0) 4 bytes for tx_in.height 0 byte for tx_in.coinbase_script 4 bytes for tx_in.sequence 1 byte for tx_out_count 8 bytes for tx_out.value 1 byte for tx_out.pk_script_bytes 1 byte for tx_out.pk_script 4 bytes for lock_time

A SIGHASH flag is used to indicate which part of the transaction is signed by the ECDSA signature. There are currently 3 flags: SIGHASH_ALL, SIGHASH_NONE, SIGHASH_SINGLE, and different combinations of these flags.

No matter the SIGHASH flag and no matter the combination, the following fields from the transaction are always included in the constructed preimage: 4 bytes for version 36 bytes for tx_in.previous_output (or tx_in.hash + tx_in.index for coinbase) 4 bytes for lock_time

Additionally, the last 4 bytes of the preimage determines the SIGHASH flag.

This is enough to say there is no way the preimage could be shorter than 4 + 36 + 4 + 4 = 48 bytes.

For this reason, we construct the heartbeat message, as a 16-byte message. The first 8 bytes are 0xffffffffffffffff. The last 8 bytes are for an arbitrary uint64, being a signed heartbeat nonce (for example, the last Ethereum block hash).

The message being signed by the wallet when executing the heartbeat protocol should be Bitcoin's hash256 (double SHA-256) of the heartbeat message: heartbeat_sighash = hash256(heartbeat_message)

Determines if the signed byte array is a valid, non-fraudulent heartbeat message.

Wallet heartbeat message must be exactly 16 bytes long with the first 8 bytes set to 0xffffffffffffffff.

GovernanceUtils

onlyAfterGovernanceDelay

function onlyAfterGovernanceDelay(uint256 changeInitiatedTimestamp, uint256 delay) internal view

Reverts if the governance delay has not passed since the change initiated time or if the change has not been initiated.

Parameters

Gets the time remaining until the governable parameter update can be committed.

Wallets are created periodically based on governance. changes the time between wallets and reads it. The time between new wallets is held in walletCreationPeriod in number of seconds, so the current value of 1209600 represents 14 days. In order for the wallet to move funds, it produces signatures using a , requiring 51-of-100 Signers to cooperate.

The 100 signers on each wallet are chosen with our , and the randomness is provided by the .

The probability that an operator is chosen to be a Signer is equal to their allowlist weighting. Each Signer is chosen independently. The same operator can be a signer on the same wallet multiple times. The same operator can be a Signer on multiple wallets simultaneously.

For simplicity, say there are only three Stakers: Alice, Bob, and Carol. Alice has 250M T, Bob has 400M T, and Carol has 350M T staked, so they own 25%, 40% and 35% of the stake respectively. That means, Alice has a 25% chance to be a Signer, Bob has a 40% chance, and Carol has a 35% chance. Each Signer is selected independently.

The primary wallet responsibility is taking care of Bitcoins deposited by tBTC users. Whenever a wallet needs to move some Bitcoins due to a protocol action (e.g. deposit sweep or redemption), it must assemble an appropriate Bitcoin transaction and sign each transaction's input using the tECDSA signing algorithm. During the tECDSA signing, randomly selected 51-of-100 wallet signers must collaborate to produce a proper signature.

A single tECDSA signing attempt consists of several steps. Each step has a maximum duration expressed in the specific number of host chain (e.g., Ethereum) blocks:

1. Signers' readiness announcement phase, which takes exactly 6 blocks

See GitHub for the latest release:

Under Assets, copy the path to the compressed binary and use the command below to download the file. Make relevant adjustments to the version as necessary:

After the download completes, use the command below to display the contents of the folder:

Extract the compressed file:

To launch the tBTC v2 client, several configuration flags and environmental values need to be set. For simplicity, a bash script can be used rather than typing or pasting all the flags into the console.

The following flags must be set at a minimum:

The following instructions assume your docker install followed installation instructions.

This function allows setting up the SDK to work with custom tBTC smart contracts and custom Bitcoin network. For example, it can be used to address the following use cases:

This is the common case when you are setting up a development environment. Let's suppose you have deployed the tBTC contracts on your local Ethereum chain and you are using a . The following snippet demonstrates SDK initialization in that case:

In some cases, you may want to initialize the SDK for mainnet/testnet, but point the Electrum Bitcoin client to your own server. Here is how you can do that:

You can even use another (non-Electrum) Bitcoin client implementation. This is how you can achieve that:

Sometimes, you may also want to initialize the SDK with mock tBTC contracts and Bitcoin network for testing purposes. This can be done as follows:

You can learn about APIs of contracts related to the Bridge under the following links:

Threshold Network allows authorized signers to participate in tBTC minting, redemptions, and custody. These signers ensure key operations run properly without interruptions.

You may find that some notable professional staking providers request DAO approval here.

Signer nodes form a permissioned set responsible for creating tBTC wallets that custody BTC. Running a tBTC Signer node is a significant commitment with specific requirements. This document aims to highlight such requirements, technical recommendations, and possible costs of operating a tBTC Signer node.

To stay informed about current node activities and other tBTC-related transactions, you may visit the Threshold App Explorer page.

General requirements

Running a Signer node is a long-term commitment.

Operators of Signer nodes are expected to be extremely responsive. Ideally, they should be able to upgrade their nodes within 24 hours of notification.

Operators of Signer nodes must be technically capable. They are responsible for ensuring high availability (more than 96% uptime) and the node's security.

A Signer node performs relatively computationally expensive operations (DKG, threshold signing, etc). To ensure a high level of service, a Signer node requires a machine with:

• 4 CPUs

• 4 GB of RAM

• 1 GB of persistent disk space

In addition to the above:

• The underlying machine’s operating system and tools must be up to date, especially regarding recent security patches.

• Backups of the persistent disk must be performed on an ongoing basis. This is crucial to ensure the safety of mission-critical data (e.g., key material). Using an additional encryption layer for backups is highly recommended.

• The network layer must provide a unique public IPv4 address so the node can be reached from the external network. A proper firewall configuration must be in place to ensure a safe perimeter, allowing inbound traffic on two ports (communication and diagnostics). The internet connection must be stable, and failover scenarios must be accounted for.

The actual monthly costs of running a Signer node depend on the hosting model (VPS vs self-hosting) and infrastructure configuration. The following estimate provides a ballpark figure. It also assumes that all aforementioned technical requirements and recommendations are taken into account.

Key system assumptions

• Signer node requires 4 CPUs / 4 GB RAM / 1 GB HDD

• Ethereum stack requires 4 CPUs / 16 GB RAM / 2 TB SSD

• Bitcoin stack requires 8 CPUs / 16 GB RAM / 2 TB SSD

The above assumptions can be used to divide costs into 4 categories:

1. Computing costs: This category includes the costs of running 18 CPUs and 40 GB of RAM. There are several possible configurations that can provide such computing capacity. Using the VPS-based model as an example, the cost of 3x 8CPU/16GB VMs on leading cloud service providers starts from ~$400/month.

2. Storage costs: This category includes the cost of using a 4 TB SSD and ~1 TB HDD in total. For the VPS-based model, part of this cost is often included in the cost of VMs, but some providers charge separately for storage at rates like ~$0.08/GB (e.g., Amazon EBS). In that case, it is safe to assume that storage costs start from ~$200/month.

In summary, the cost for running a Signer node using the VPS-based model starts at approximately $650/month. Assuming a safety margin for other costs, a rough estimate is $800/month to run a setup in accordance with the technical requirements and recommendations.

Estimating the general cost for the self-hosting model is non-trivial due to the variety of possible configurations. The total monthly cost can be similar to the VPS-based model, but may also incur additional hidden costs, such as hardware maintenance

The above assumptions and figures should be used cautiously, as they are intended only to provide a general sense of infrastructure costs. Each prospective Signer node operator should conduct their own estimates based on their individual circumstances.

Last but not least, the presented estimate refers only to the infrastructure-related costs of operating a tBTC Signer node. This estimate DOES NOT include human operational costs. Each Signer must include this overhead when making their own estimates.

DonationVault

Vault that allows making BTC donations to the system. Upon deposit, this vault does not increase depositors' balances and always decreases its own balance in the same transaction. The vault also allows making donations using existing Bank balances.

BEWARE: ALL BTC DEPOSITS TARGETING THIS VAULT ARE NOT REDEEMABLE AND THERE IS NO WAY TO RESTORE THE DONATED BALANCE. USE THIS VAULT ONLY WHEN YOU REALLY KNOW WHAT YOU ARE DOING!

bank

contract Bank bank

DonationReceived

event DonationReceived(address donor, uint256 donatedAmount)

onlyBank

modifier onlyBank()

constructor

constructor(contract Bank _bank) public

donate

function donate(uint256 amount) external

Transfers the given amount of the Bank balance from the caller to the Donation Vault and immediately decreases the vault's balance in the Bank by the transferred amount.

Requirements:

• The caller's balance in the Bank must be greater than or equal to the amount,

• Donation Vault must have an allowance for caller's balance in the Bank for at least amount.

Transfers the given amount of the Bank balance from the owner to the Donation Vault and immediately decreases the vault's balance in the Bank by the transferred amount.

Requirements:

• Can only be called by the Bank via approveBalanceAndCall,

• The owner balance in the Bank must be greater than or equal to the amount.

Ignores the deposited amounts and does not increase depositors' individual balances. The vault decreases its own tBTC balance in the Bank by the total deposited amount.

Requirements:

• Can only be called by the Bank after the Bridge swept deposits and Bank increased balance for the vault,

• The depositors array must not be empty,

• The depositors array length must be equal to the depositedAmounts

LightRelayMaintainerProxy

The proxy contract that allows the relay maintainers to be refunded for the spent gas from the ReimbursementPool. When proving the next Bitcoin difficulty epoch, the maintainer calls the LightRelayMaintainerProxy which in turn calls the actual LightRelay contract.

lightRelay

contract ILightRelay lightRelay

isAuthorized

mapping(address => bool) isAuthorized

Stores the addresses that can maintain the relay. Those addresses are attested by the DAO.

The goal is to prevent a griefing attack by frontrunning relay maintainer which is responsible for retargetting the relay in the given round. The maintainer's transaction would revert with no gas refund. Having the ability to restrict maintainer addresses is also important in case the underlying relay contract has authorization requirements for callers.

retargetGasOffset

uint256 retargetGasOffset

Gas that is meant to balance the retarget overall cost. Can be

LightRelayUpdated

event LightRelayUpdated(address newRelay)

MaintainerAuthorized

event MaintainerAuthorized(address maintainer)

MaintainerDeauthorized

event MaintainerDeauthorized(address maintainer)

RetargetGasOffsetUpdated

event RetargetGasOffsetUpdated(uint256 retargetGasOffset)

onlyRelayMaintainer

modifier onlyRelayMaintainer()

onlyReimbursableAdmin

modifier onlyReimbursableAdmin()

constructor

constructor(contract ILightRelay _lightRelay, contract ReimbursementPool _reimbursementPool) public

updateLightRelay

function updateLightRelay(contract ILightRelay _lightRelay) external

Allows the governance to upgrade the LightRelay address.

The function does not implement any governance delay and does not check the status of the LightRelay. The Governance implementation needs to ensure all requirements for the upgrade are satisfied before executing this function.

Authorizes the given address as a maintainer. Can only be called by the owner and the address of the maintainer must not be already authorized.

The function does not implement any governance delay.

Deauthorizes the given address as a maintainer. Can only be called by the owner and the address of the maintainer must be authorized.

The function does not implement any governance delay.

Updates the values of retarget gas offset.

Can be called only by the contract owner. The caller is responsible for validating the parameter. The function does not implement any governance delay.

Wraps LightRelay.retarget call and reimburses the caller's transaction cost. Can only be called by an authorized relay maintainer.

See LightRelay.retarget function documentation.

EcdsaInactivity

Claim

struct Claim {
  bytes32 walletID;
  uint256[] inactiveMembersIndices;
  bool heartbeatFailed;
  bytes signatures;
  uint256[] signingMembersIndices;
}

groupThreshold

uint256 groupThreshold

The minimum number of wallet signing group members needed to interact according to the protocol to produce a valid inactivity claim.

signatureByteSize

uint256 signatureByteSize

Size in bytes of a single signature produced by member supporting the inactivity claim.

verifyClaim

function verifyClaim(contract SortitionPool sortitionPool, struct EcdsaInactivity.Claim claim, bytes walletPubKey, uint256 nonce, uint32[] groupMembers) external view returns (uint32[] inactiveMembers)

Verifies the inactivity claim according to the rules defined in Claim struct documentation. Reverts if verification fails.

Wallet signing group members hash is validated upstream in WalletRegistry.notifyOperatorInactivity()

Parameters

Validates members indices array. Array is considered valid if its size and each single index are in [1, groupSize] range, indexes are unique, and sorted in an ascending order. Reverts if validation fails.

Protocol Upgrades

Defense by Thesis - Beta Staker Allowlist & Bridge Fee Rebates

• Date: 27 November 2025

• Report: View Audit 1 PDF - View Audit 2 PDF

• Scope: Smart contracts for T staking rebates. See related proposals, and

• Date: 5 November 2025

• Report:

• Scope: WalletRegistry and EcdsaDkg smart contracts

• Date: 31 Oct 2025

• Report:

• Scope: NativeBTCDepositor contract

• Date: 25 Sept 2025

• Report:

• Scope: Threshold CCIP Update

• Date: 08 Sept 2025

• Report:

• Scope: Cross-chain bridge transfers

• Date: 01 May 2025

• Report:

• Scope: tBTC integration with the Sui blockchain

• Date: April 2025

• Report:

• Scope: tBTC integration with the StarkNet blockchain

• Date: April 11th, 2024

• Report:

• Scope: tBTC integration with the Base blockchain

• Date: 29 August 2023

• Report: -

• Scope: Smart contracts for the tBTC Bridge on Solana

• Date: 29 September 2022

• Report: -

• Scope: Security audit of the core tBTC Bridge contracts

• Date: 19 November 2021

• Report: -

• Scope: Vending machine security audit

• Date: 09 November 2021

• Report: -

• Scope: Staking contracts, T token logic, and vending machine mechanisms

VendingMachineV2 is used to exchange tBTC v1 to tBTC v2 in a 1:1 ratio during the process of tBTC v1 bridge sunsetting. The redeemer selected by the DAO based on the "TIP-027b tBTC v1: The Sunsetting" proposal will deposit tBTC v2 tokens into VendingMachineV2 so that outstanding tBTC v1 token owners can upgrade to tBTC v2 tokens. The redeemer will withdraw the tBTC v1 tokens deposited into the contract to perform tBTC v1 redemptions. The redeemer may decide to withdraw their deposited tBTC v2 at any moment in time. The amount withdrawable is lower than the amount deposited in case tBTC v1 was exchanged for tBTC v2. This contract is owned by the redeemer.

Exchange tBTC v1 for tBTC v2 in a 1:1 ratio. The caller needs to have at least amount of tBTC v1 balance approved for transfer to the VendingMachineV2 before calling this function.

The library handles the logic for revealing Bitcoin deposits to the Bridge.

The depositor puts together a P2SH or P2WSH address to deposit the funds. This script is unique to each depositor and looks like this:

Since each depositor has their own Ethereum address and their own blinding factor, each depositor’s script is unique, and the hash of each depositor’s script is unique.

Used by the depositor to reveal information about their P2(W)SH Bitcoin deposit to the Bridge on Ethereum chain. The off-chain wallet listens for revealed deposit events and may decide to include the revealed deposit in the next executed sweep. Information about the Bitcoin deposit can be revealed before or after the Bitcoin transaction with P2(W)SH deposit is mined on the Bitcoin chain. Worth noting, the gas cost of this function scales with the number of P2(W)SH transaction inputs and outputs. The deposit may be routed to one of the trusted vaults. When a deposit is routed to a vault, vault gets notified when the deposit gets swept and it may execute the appropriate action.

Requirements:

The is an ERC-20 token that powers tBTC and serves as the value accrual asset for the Threshold Network. As of late, the T token is fully diluted.

Historically, the T token was formed through the merger of two entities, NU and KEEP. Based on the final merger proposal, the conversion ratio for each token is determined by total supply rather than price. During the merger, the supply of NU is approximately 1,380,688,920, and the total supply of KEEP is approximately 940,795,010. Accordingly, the conversion factors are ~3.26 T per NU and ~4.78 T per KEEP.

The initial supply of T was established by the DAO at launch as 10Billion T with the following allocation during launch:

• 4.5B T allocated to NU token holders

Application configuration can be stored in a file and passed to the application with the --config flag.

Example:

./keep-client --config /path/to/your/config.toml start

Configuration files in formats TOML, YAML and JSON are supported.

Sample configuration file:

You can learn about APIs of contracts related to ECDSA under the following links:

EcdsaAuthorization

EcdsaDkg

EcdsaDkgValidator

EcdsaInactivity

IWalletOwner

IWalletRegistry

Requests a new wallet creation.

Only the Wallet Owner can call this function.

Closes an existing wallet.

Only the Wallet Owner can call this function.

VendingMachineV3 is used to exchange tBTC v1 to tBTC v2 in a 1:1 ratio after the tBTC v1 bridge sunsetting is completed. Since tBTC v1 bridge is no longer working, tBTC v1 tokens can not be used to perform BTC redemptions. This contract allows tBTC v1 owners to upgrade to tBTC v2 without any deadline. This way, tBTC v1 tokens left on the market are always backed by Bitcoin. The governance will deposit tBTC v2 into the contract in the amount equal to tBTC v1 supply. The governance is allowed to withdraw tBTC v2 only if tBTC v2 left in this contract is enough to cover the upgrade of all tBTC v1 left on the market. This contract is owned by the governance.

Exchange tBTC v1 for tBTC v2 in a 1:1 ratio. The caller needs to have at least amount of tBTC v1 balance approved for transfer to the VendingMachineV3 before calling this function.

Library managing the state of stake authorizations for ECDSA operator contract and the presence of operators in the sortition pool based on the stake authorized for them.

Sets the minimum authorization for ECDSA application. Without at least the minimum authorization, staking provider is not eligible to join and operate in the network.

Sets the authorization decrease delay. It is the time in seconds that needs to pass between the time authorization decrease is requested and the time the authorization decrease can be approved, no matter the authorization decrease amount.

Sets the authorization decrease change period. It is the time period before the authorization decrease delay end, during which the authorization decrease request can be overwritten.

Used by staking provider to set operator address that will operate ECDSA node. The given staking provider can set operator address only one time. The operator address can not be changed and must be unique. Reverts if the operator is already set for the staking provider or if the operator address is already in use. Reverts if there is a pending authorization decrease for the staking provider.

Callback function executed once a new wallet is created.

Should be callable only by the Wallet Registry.