bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 36쪽 중 4쪽
t that a position still sitting on a Closing wallet can be stranded once its dissolution date has passed.
{% endstep %}
{% step %}
### Re-anchor when a wallet retires
```
1. REQUEST, on Ethereum: the position must be Active. If the source wallet
is Live, only governance may request (deliberate rotation off a healthy
wallet). If the source is retiring (MovingFunds or Closing), anyone may
request. The target must be a different wallet in the Live state, with a
free slot under its caps. Amount floor: the anchor must be greater than
the minimum plus one max fee.
2. SIGN, on Bitcoin: the source wallet's signers check the authorization
and sign a one-input/one-output re-anchor transaction paying the
target wallet. When a wallet is moving its funds, signer software
requests and signs these re-anchors automatically.
3. PROVE, on Ethereum: an SPV maintainer proves the transaction. The Bridge
moves custody to the target, shrinks the claim by the fee, releases the
source wallet's slot, and asks the vault to finance the fee: the vault
burns tBTC from its reserve, and any shortfall becomes public,
repayable fee debt.
4. LATE PROOF: a signed, confirmed re-anchor can be proven with no time
limit; a late proof can even restore a position that was stranded in
the meantime onto the new wallet.
IF THE REQUEST TIMES OUT: anyone can file the timeout. The target slot is
released, the position returns to Active on the same source wallet, and a
cooldown applies to the next non-governance request. No one is slashed.
```
Once a retiring wallet holds no reservations and its remaining balance is below the dust threshold, signer software reports that, so the wallet can begin closing.
{% endstep %}
{% step %}
### How a position ends in M1
Stranding is M1's only terminal state. Anyone may file it when the position is `Active` , and the custodying wallet is `Terminated`, `Closed`, or `Closing` with its dissolution date passed. The Bridge releases the capacity, drops the anchor from tracking, and records the position as Stranded. The owner's tBTC balance does not change; what is lost is the in-kind option of getting that specific bitcoin back, which v2 can honor. There is no compensation mechanism: if the bitcoin is really gone, the shortfall affects tBTC backing as a whole, exactly as with any terminated tBTC wallet today.
{% endstep %}
{% endstepper %}
# tBTC Minting Walkthrough
Follow along with this guide and leverage your Bitcoin by minting tBTC.
<figure><img src="https://2518393180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWosjlL4zUGUMlcMfuSAp%2Fuploads%2FMRiRVs3qPG4ACqRyd2fG%2FFlowchart%20tBTC%20v3-02.png?alt=media&token=e9b31d05-eaae-40b3-98e9-95bd35712ac1" alt=""><figcaption></figcaption></figure>
## Before you start
Here are some things you will need before you start the minting process:\
\
**What you need:**
:white\_check\_mark: At least 0.01 Bitcoin (BTC)
:white\_check\_mark: Bitcoin-compatible wallet (self-custodied)
:white\_check\_mark: Destination Wallet (on supported chains; see the list of supported chains [here](https://docs.threshold.network/contract-addresses/tbtc).)\
\
**Important Reminders:**
* *Always download and securely store your deposit receipt.* This JSON file is required to recover your funds in the event of any technical issues during the minting process. 
* *Minting may take anywhere from a few minutes to several hours*, depending on the amount of BTC deposited. You can monitor the status at <https://app.threshold.network/explorer>
* *Your BTC recovery address must come from a self-custodied wallet that you control.* Do not use an address from a centralized exchange.  
* *Multisig wallets are supported as long as they’re on the correct network.*
{% hint style="info" %}
If you don't have a Bitcoin wallet, you'll need to set one up. A solid option to use is Green Wallet. You can download it here:
* [Apple store download](< https://apps.apple.com/us/app/green-bitcoin-wallet/id1402243590>)
* [Google store download](https://play.google.com/store/apps/details?id=com.greenaddress.greenbits_android_wallet\&gl=US\&pli=1)
After you've created your wallet, select `Bitcoin` as your network..
{% endhint %}
# Governance Process
Discover how you can participate in Threshold Governance Process
### Lifecycle of a successful proposal
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 [snapshot](https://snapshot.org/#/threshold.eth). If a proposal receives majority support during the temperature check, it is eligible to move onto the next step. 
3. **Proposal Creation**: A community member holding enough vote weight (at least 0.25% of T total supply) submits the proposal on-chain. The proposal enters a **2-day delay period before voting** officially begins.
4. **Vote Period**: Proposal **voting remains open for 10 days**. If the proposal passes with enough quorum (at least 1.5% of T total supply), it moves onto the next step; if the proposal fails, it is canceled. Creators and supporters of the proposal may bring a modified proposal forward again but it must be sufficiently different and pass requirements outlined in previous steps.
5. **Timelock Period**: Once a proposal is approved, the Governor Bravo smart contracts include an additional **timelock delay of 2 days**. Anyone can interact with the Governor Bravo smart contracts to queue an approved proposal into the Timelock contract.
6. **Execution**: After the timelock delay, anyone can execute an approved proposal.
### Deviations in the proposal lifecycle
* **Committee vetos:** During the on-chain phase, the Elected Committee can veto any proposal. This is intended to be an extra security mechanism in the event that a dangerous proposal passes. 
* **Late quorum prevention:** The 10-days voting period is automatically extended when quorum is reached late, to prevent governance attacks that try to reach quorum at the last minute; in case a proposal reaches quorum less than 2 days before the deadline, the proposal deadline is **extended for 2 more days** from the moment the quorum was reached.
* **Off-chain proposals:** Some proposals do not imply any on-chain action (e.g. Council and Guild elections). In these cases, there is a Snapshot vote that takes 5 days for regular proposals and 7 days for elections, with no associated on-chain proposal.
# Threshold Multisigs
Compilation of current multisigs for the Threshold Committee
## Committee Multisigs
| Chain | Address | Safe Link |
| --------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------ |
| Ethereum | 0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f | <https://app.safe.global/home?safe=eth:0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f> |
| Eth: Foundation | 0xf642Bd6A9F76294d86E99c2071cFE2Aa3B61fBDa | <https://app.safe.global/home?safe=eth:0xf642Bd6A9F76294d86E99c2071cFE2Aa3B61fBDa> |
| Arbitrum | 0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f | <https://app.safe.global/home?safe=arb1:0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f> |
| Optimism | 0x7fB50BBabeDEE52b8760Ba15c0c199aF33Fc2EfA | <https://app.safe.global/home?safe=oeth:0x7fB50BBabeDEE52b8760Ba15c0c199aF33Fc2EfA> |
| Polygon | 0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f | <https://app.safe.global/home?safe=matic:0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f> |
| Base | 0x518385dd31289F1000fE6382b0C65df4d1Cd3bfC | <https://app.safe.global/home?safe=base:0x518385dd31289F1000fE6382b0C65df4d1Cd3bfC> |
| Solana | 814TqVmhQGKB3srSLRuMcH6m8qWFHRSbNpRxC5Xnador | <https://v3.squads.so/owners/M1NVajFvdzNFUHI0VUNpOUJuMmpxNmhjMjdQRVRHWDVkTjZrY3puc1ZUWkQ=> |
| Starknet | 0x0314A42C20b0364C6df5Af35E0914dd65F24a61F3563a8bc2A9D664938f37c4F | N/A (Argent's Multisig) |
{% hint style="info" %}
The Threshold Committee multisigs have a signature policy threshold set to 6 of 9.
{% endhint %}
# Liquid Token Delegation
How to delegate liquid T tokens
Liquid T holders can delegate their token weights to themselves or a third party for voting on governance proposals.
{% hint style="info" %}
Delegation is performed via an onchain transaction, which incurs ETH gas costs.
{% endhint %}
1. Go to <https://boardroom.io/threshold>.
2\. Connect your wallet.
3\. Click "*Set Up Delegation".*
<div align="left"><img src="https://2518393180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWosjlL4zUGUMlcMfuSAp%2Fuploads%2FCAb5otPDrrTzKLkftcjw%2Fgov-set-up-delegation.png?alt=media&token=603ca33b-2864-4fb2-b50e-2cc7acca643b" alt="Set Up Delegation"></div>
4\. Select your *"Delegation Type"* - either to yourself or a third party.
<div align="left"><img src="https://2518393180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWosjlL4zUGUMlcMfuSAp%2Fuploads%2Fgu2cIlrnSb3Eo9PD54No%2Fgov-delegate-type.png?alt=media&token=a576842b-0b80-48c3-868b-0c7399f757a5" alt="Choose Delegation Type"></div>
5\. Enter *"Delegate Address"* and click on *"Delegate Votes".*
<div align="left"><img src="https://2518393180-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FWosjlL4zUGUMlcMfuSAp%2Fuploads%2FlVC6W5m6iYkJUfRyso1l%2Fgov-delegate-vote.png?alt=media&token=b3bd6705-5ce7-47ea-a047-d4ab0e139294" alt="Delegate Votes"></div>
6\. Sign the transaction.
# tBTC Signers
A comprehensive guide for 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). 
{% hint style="info" %}
Visit the [contract page on Etherscan](https://etherscan.io/address/0xc2731fb2823af3Efc2694c9bC86F444d5c5bb4Dc#readContract#F16) to see the current number of Beta Stakers. 
{% 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: 
* 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. 
**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. 
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. 
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>
# Node Setup
This document explains the basic installation and configuration for the tBTC v2 client.
{% hint style="info" %}
Please be aware that running a node is not an easy task and requires technical skill and commitment to maintaining node uptime and availability.
{% endhint %}
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.
### Recommended Machine Types <a href="#recommended_machine_types" id="recommended_machine_types"></a>
{% hint style="info" %}
While it is possible to run the client on a local machine, this is not recommended.
{% endhint %}
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.
| VPS Provider | VPS Type |
| ------------ | -----------------------프로젝트로 돌아가기
