# tBTC Signers

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](https://forum.threshold.network/t/tip-067-part-1-add-professional-node-operators-to-beta-staker-program/730/20).&#x20;

{% hint style="info" %}
Visit the [contract page on Etherscan](https://etherscan.io/address/0xc2731fb2823af3Efc2694c9bC86F444d5c5bb4Dc#readContract#F16) to see the current number of Beta Stakers.&#x20;
{% endhint %}

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.](https://app.threshold.network/explorer?tab=deposits)

## 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.

## Technical requirements

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
* 80 Mbps of network bandwidth
* Linux OS

In addition to the above:&#x20;

* 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.
* A Signer node requires access to an Ethereum node. It is highly recommended to set up a private Ethereum stack (e.g., Geth + Prysm) and use public providers as a failover (e.g., Alchemy, Infura, etc). Such a setup is crucial for network diversity and decentralization as it helps avoid the single-point-of-failure risk associated with public providers. Signers should use their own judgment for selecting stack components. Specific technical requirements for a private Ethereum stack depend on the software used. For example, a stack based on [Geth + Prysm requires 4 CPU / 16 GB RAM / 2 TB SSD](https://docs.prylabs.network/docs/install/install-with-script#step-1-review-prerequisites-and-best-practices).
* A Signer node requires an Electrum protocol server to interact with Bitcoin. It is highly recommended to set up a private stack consisting of an Electrum server (e.g., Fulcrum, ElectrumX, Electrs, etc) paired with a Bitcoin node (e.g., Bitcoin Core) and use public servers as a failover. The reasons are exactly the same as for a private Ethereum stack. Signers should use their own judgment for selecting stack components. Specific technical requirements for a private Bitcoin stack depend on the software used. For example, a stack based on Fulcrum + Bitcoin Core requires 8 CPU / 16 GB RAM / 2 TB SSD.
* It is highly recommended to set up a private monitoring stack to ensure observability and alerting. The monitoring system should supervise the node itself as well as Ethereum and Bitcoin stacks. Signer operators should use their own judgment for selecting stack components. Specific technical requirements for a monitoring stack depend on the software used. For example, a stack based on Grafana + Prometheus requires 2 CPU / 4 GB RAM / 20 GB HDD.

## Cost estimation

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.&#x20;

**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
* Monitoring stack requires 2 CPUs / 4 GB RAM / 20 GB HDD
* External storage for backups (node and auxiliary stacks) is 1 TB HDD
* The network layer ensures 100 Mbps of bandwidth and includes all necessary equipment (firewall, public IPs, etc.).

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.
3. **Network costs:** This category includes the cost of 100 Mbps of bandwidth and all auxiliary equipment and features, such as a firewall or public IPs. For the VPS-based model, such bandwidth is often provided out of the box with the VMs, but a firewall and public IPs may be charged separately. Moreover, some providers may apply an additional charge on egress traffic. It is safe to assume that network costs start from \~$50/month.
4. **Other costs:** This category includes all maintenance and other costs, depending on the hosting model and infrastructure configuration. For the VPS-based model, such costs can be OS licenses, automatic backup, additional management tools, and so on. For the self-hosting model, these can be costs of internet connection, power failover (e.g., UPS), auxiliary network equipment, and similar. This category of costs must be factored into the total monthly cost.

## Bottom Line

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.&#x20;

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

## **Disclaimer**

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.&#x20;

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.<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.threshold.network/tbtc-signer-nodes/tbtc-signers.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.