### Tl;dr The goal of this proposal is to add 5 professional node operators to the tBTC Beta Staker program by delegating DAO-owned T. ### Background tBTC currently relies on a permissioned group of node operators, referred to as "Beta Stakers", to secure the wallets that contain the BTC that backs tBTC. These nodes are highly reliable, and stake a significant amount of T. An increase in the number of Beta Staker nodes will improve system decentralization through an increase in the geographic dispersion of Beta-Stake operators, and the distribution of key shares created by the “Distributed Key Generation” (DKG) ceremony. The goal of Part 1 of TIP-067 is to increase the Beta Staker set from 20 to 25 nodes, and T staked across the Beta Staker nodes by 150M T. ### Proposal The tBTC development team will vet and select 5 professional node operators from applications via this forum to be added to the Beta Staker permissioned group. These nodes will be delegated T to their node from the DAO treasury. ### Duration New Beta Stakers will be required to run their respective nodes until the conclusion of the Beta Staker program, or for a minimum of 12 months, whichever is sooner. It is not possible to exit the Beta Staker program once added, which means that operators must continue to participate until the retirement of the program. ### Requirements Operators of Beta Staker nodes are expected to be extremely responsive, especially in regards to upgrades requested by software contributors. Ideally, they should be able to upgrade their nodes within 24 hours of notification. Operators of Beta Staker nodes must be technically capable. They are responsible for ensuring high availability (more than 96% uptime) and security of the node. A Beta Staker node performs more computationally expensive operations (DKG, threshold signing, etc) compared to a standard Threshold node. To ensure a high level of service, a Beta Staker node requires a machine with: * 4 CPUs * 4 GB of RAM * 1 GB of persistent disk space * 80 Mbps of network bandwidth * Linux OS Additional documentation can be found here: [https://docs.threshold.network/staking-and-running-a-node/tbtc-Beta Stakers-program](https://docs.threshold.network/staking-and-running-a-node/tbtc-beta-stakers-program) ### TACo - Additional Application Threshold Network has two applications that operate on its security model: tBTC and TACo. Beta Stakers that choose to run an additional VPS for a TACo node with their delegation to receive an additional 25% payment. Details on also running a TACo node, to receive 100% of the available remuneration, instead of 75%, can be found here: https://docs.threshold.network/staking-and-running-a-node/running-a-node/self-managed/pre-node-setup. ### Criteria for Selection Eligibility requirements are strict due to the high uptime requirement, and only the best applicants will be selected. Operators must: * Have a demonstrable history of professional validator services. * Submit a written application via this forum with the following details: * Company name * Company website * Company description * Country of operation * Relevant experience * Description of solution design * Description of backup and security principals * Will you participate with both tBTC & TACo? Y/N * Do you commit to participating as a Beta Staker for a minimum of 12 months? Y/N * Be familiar with Threshold Network and tBTC architecture. The DAO will reimburse Ethereum transaction fees (in ETH) directly to the respective operator addresses on a monthly basis. ### Delegation and Terms The DAO will delegate 30M T to each successful applicant. Successful operators will receive a $1,500 USD/month payment for participating in the Beta Staker program. If the provider chooses to run a TACo node in addition to tBTC, the monthly payment will be $2,000 USD/month. Additional terms: * Payment terms are subject to nodes meeting the 96% uptime requirement in the month prior. Uptime below the minimum will result in forfeiture of that month’s payment. * Payments will be made in T in accordance with the T/USD price at 10am UTC on the final day of the month, as reported by CoinGecko. * Cost for the program will be covered by staking rewards generated from the delegated T. * T rewards will be claimable by the Treasury Guild and distributed accordingly. * Any excess T generated above the cost of the program will be burned. ### Indicative Timeline * Nominations Period - December 13th - December 27th * Candidate selection period - December 27th - January 3rd * Technical setup and troubleshooting - January 3rd - January 17th * Treasury Guild Delegation Execution - January 18th * New Beta Stakers added incrementally - January 19th - onward

**TLDR** This proposal would see TACo officially become a Threshold application, with PRE services folded into TACo and discontinued as a standalone app. To motivate long-term service provision on TACo, one-off yield bonuses will be offered to stakers who authorize their tokens to be locked up for durations longer than the minimum deauthorization delay (6 months). Watch the recent **[Staker Townhall](https://www.youtube.com/watch?v=S-xJeNYo87k)** for a deep dive into TACo, **why it’s worthwhile staking on TACo**, and a demo from three Web3 developer teams currently integrating this access control layer into their applications. Proposal contents: (1) Introduction (2) Application contracts (3) Fees (4) One-off bonus for staking on TACo – 50m T (5) Application trust profile **(1) Introduction to TACo** **TACo** (**T**hreshold **A**ccess **Co**ntrol) facilitates end-to-end encrypted data sharing and communication in Web3 applications – without relying on a centralized authority, who might unilaterally deny service or even decrypt private user data. *It is the only access control layer available to Web3 developers that can offer end-to-end encryption that is end-to-end decentralized.* TACo is relevant to virtually any Web3 app/stack that handles private data. Early adopters are building and operating in domains where *compromising on trust minimization simply doesn’t work for the core value proposition*; recovering seed phrases, passing on crypto assets as inheritance, enforcing decryption rights for tokenized legacy media libraries, transferring sensitive model I/O to remote machines, concealing in-game assets, and other use cases. See the [Townhall](https://www.youtube.com/watch?v=S-xJeNYo87k) to understand these use cases better! A TACo user flow is fairly straightforward. At encryption time, end-users specify conditions for accessing their private data (e.g. only share this video stream with the holders of a special purpose NFT). When those conditions are fulfilled and verified by a threshold of TACo cohort members, the cohort provides the data requester with sufficient decryption material to decrypt the data and view the plaintext. Otherwise, the private data remains inaccessible to everyone besides the original data encryptor. Further resources: * [Running a TACo node](https://docs.threshold.network/staking-and-running-a-node/running-a-node/self-managed/taco-node-setup) * [TACo Simple Overview](https://docs.threshold.network/applications/threshold-access-control/conditions-based-decryption-cbd) * [TACo Value Propositions](https://docs.threshold.network/applications/threshold-access-control/value-propositions) * [TACo Presentation at ETHBoston](https://www.youtube.com/watch?v=3kNXuNbWSO0) **(2) TACo's application contracts** From a staking point of view, the TACo application is implemented through a set of smart contracts on both Ethereum Mainnet and Polygon Mainnet. The most important among these contracts is `TACoApplication`, which executes the authorization and deauthorization logic, and consequently, will be connected to the Threshold staking contract. `TACoApplication` will be upgradeable and owned by the Threshold Council. The `TACoApplication` contract, as well as supporting contracts in Ethereum and Polygon, were audited by [Cantina](https://cantina.xyz/welcome). No major issues were found, and the audit report will be published as soon as it’s ready. **(3) TACo's fees at genesis** Duration-based fees will be paid at cohort creation (the ‘base fee’). Adopters will be charged in DAI, proportional to: (i) the number of nodes they rent for the cohort (minimum: 15, default: 30). (ii) the duration of the cohort’s existence (minimum: 6 months, default: 6 months). The base fee is set to **0.35 DAI per node per day**. For the recommended cohort size of 30, this generates **3,832.50 DAI per adopter per year**. There is no free tier of service, besides the limited Tapir testnet. Soon, adopters will be able to generate multiple cohorts to service different components or security levels within their applications, increasing the base fee revenue per adopter. Revenue generated by TACo will go to the DAO Treasury. The DAO will decide exactly how to allocate this revenue in the near future – this proposal does not provide an opinion. Finally, some combination of the following *action-based* fee mechanisms will be developed alongside early adopters and added to future versions of TACo on top of the base fee: (i) Charging per authorization of encrypting device (ii) Charging per decryption request and/or condition verification (ii) Charging per condition creation (iv) Charging per condition update **(4) One-off Bonus for Staking on TACo (50m T)** This proposal would see a special batch of tokens minted by the DAO to incentivize extended commitments to providing the TACo service. This is in addition to and independent from the universal minimum unbonding time (deauthorization delay) of **6 months** for TACo stakers. The required extra mint is estimated to be **50,000,000 T** tokens – see calculation below. Rewarding longer lock-ups is beneficial to Threshold as a whole for the following reasons: * TACo’s early adopters need assurance that the cohorts of nodes managing access to their users’ data will not deplete in number, and ideally retain well above the threshold (e.g. 16-of-30) for years. If a large proportion of TACo nodes have stakes locked for 12+ months, this not only improves the theoretical reliability of all cohorts (i.e. randomly populated), but also allows for custom cohort compositions with a minimum remaining commitment time as a prerequisite for participation. * Although cohort members can be securely replaced, while maintaining a persistent public key to encrypt to, it is preferable for economic and security reasons to minimize the number of node replacement rituals. This is particularly true in the first year following service launch, given that the gas costs of cohort member replacement will decrease with optimization R&D, to be implemented and released in forthcoming versions. * TACo will launch without a punishment mechanism in place, but the specter of slashing and/or compensation withholding for non-availability is a strong incentive to provide a reliable service. The more stakers have committed to long-term token lock-ups, the longer the possibility of punishment is a disincentive against unreliable behavior. * Distributing a small number of extra tokens would be invaluable to TACo’s product-market fit, but have a negligible effect on the overall annual inflation of the supply. For example, in the scenario where 60 active stakers, each of average stake size, chose to lock their tokens for 12 months, this would only require minting an extra 1% yield for each staker, which would total ~7.5m extra T tokens, which would imply an inflation increase of 0.0713%. These 60 stakers’ commitment would have a profound impact on the perception and security of TACo, but would only slightly increase the supply’s annual dilution. * Long TACo lockups will likely have a positive, synergistic effect on tBTC and Random Beacon participation. Although technically the lockup only affects authorizations to the TACo app, the yield-maximizing strategy for stakers is to remain operators for all applications until the lock-up expires, in order to earn the maximum 15% yield. Functionally, stakers will be able to choose between discrete lock-up periods and receive a commensurate bonus: 9 months total (6 month deauth delay + 3 month extension): 0.5% extra yield 12 months total (6 month deauth delay + 6 month extension): 1% extra yield 18 months total (6 month deauth delay + 12 month extension): 2% extra yield 24 months total (6 month deauth delay + 18 month extension): 3% extra yield The breadth of these parameters have been validated via an anonymous survey conducted over the past few weeks, the results of which are below:  The survey results can also be used as a guide for estimating the required sum of tokens to mint, to be distributed to TACo stakers who opt for an extended token lock-up duration. Note that we have no way of knowing for certain which stake sizes will choose which percentage yield bonus, so there may be tokens left over (or less probable; not enough tokens – requiring another minting event).  This simple estimate takes the total sum of staked tokens (~3.1bn) and breaks it down by the percentage of survey respondents that chose each bonus yield option. It then multiplies that by the corresponding bonus yield percentage. This assumes that each survey-taker has the same stake size, and that every staker has to make a decision on the bonus, neither of which are the case – but this method still provides a useful ceiling for the bonus mint sum. This (over)estimate assumes 1 in 3 stakers (equivalent to ~1bn T) will choose a 24-month lockup, which requires minting ~31m T. However, fewer are likely to choose this bonus option. Hence, minting 50m extra T – to be distributed to longer committing stakers – seems to be a safe upper bound. Leftover tokens will be used in the next reward cycle. Please note the following rules apply to the bonus: 1. The bonus will be claimable in the first minting event following TACo’s launch – i.e. stakers will not have to wait for their stake to unlock to withdraw. 2. TACo’s deauthorization delay – the time one must wait between initiating a withdrawal from TACo service provision and being able to complete that withdrawal – is set to 6 months (**182.5 days**). This delay is the default and is entirely independent from the bonus mechanism. For stakers who choose a lock-up extension period for the one-off bonus, they may only initiate the deauthorization delay once the bonus lock-up extension period has elapsed. **Stakers will still earn TACo yield after initiating the deauthorization delay, until the moment they withdraw their stake**. 3. The bonus is a one-off incentive mechanism – stakers will commit to a single token lock-up duration prior to TACo's launch, and post-launch this commitment will not be editable. The opportunity to earn a bonus will not be available post-launch. The deadline for participation in the bonus will be shared in a follow-up post and in the announcements channel on Discord. 4. Post-launch, top-ups to one's stake will not count towards increasing the bonus sum (this will have already been calculated and minted), but **top-ups will be subject to the same unlock horizon**. In other words, you cannot create multiple stake tranches that unlock at different times. A more robust mechanism to incentivize longer commitments may be introduced in later versions, where stakers can freely and arbitrarily prolong their lock-up durations to earn extra yield. **(5) TACo’s trust profile at genesis** From day one, every byte of data encrypted via TACo will be collectively managed by a decentralized cohort of nodes. However, the first mainnet version of TACo comes with certain limitations. The following is not an exhaustive list, rather a focus on trust burdens that require a decision from, or can be optimized by, the Threshold community. For a more comprehensive overview, check out the [Trust Assumptions](https://docs.threshold.network/app-development/threshold-access-control-tac/trust-assumptions) section in the documentation. *Contract ownership* Certain TACo contracts will be upgradeable, and as such, they require an owner. This proposal suggests that the Threshold Council owns all upgradeable contracts. *Management roles* Certain TACo contracts have privileged roles: (1) A “treasury role” to claim fees from the protocol. i. This role interacts with Polygon contracts. ii. This proposal suggests assigning the treasury role to the Treasury Guild. (2) An “initiator role”, which will be the only one authorized to create cohorts during the private beta phase. i. This role interacts with Polygon contracts. ii. This restriction will be removed once the private beta phase is over and cohort creation becomes more permissionless. Note that the initiator doesn’t retain any administrative control over the cohorts after initialization – its utility is purely to restrict when cohorts are created, to avoid the network being griefed by (temporarily expensive) cohort generation. iii. This proposal suggests assigning the initiator role to the Integrations Guild, but other options are feasible too. *Porter gateway* In order to facilitate secure end-to-end communication from users’ browsers and TACo nodes, an intermediary gateway is required. NuCypher will run one of these gateways, but this proposal encourages anyone from the Threshold community to run their own Porter gateways as a public good. TACo adopters can additionally run their own Porter gateways if desired. In any case, Porter gateways don’t have any privileged view over the communications since information is always encrypted end-to-end, although they can potentially be unavailable. Note that Porter gateways are only required when the requesting user is using a web-based application because the nodes use self-signed certificates for HTTPs communication; if other means are used (e.g., a desktop application that uses the TACo Python API), then Porter is not required. *Ethereum and Polygon providers* TACo nodes need to query (and occasionally, transact in) both Ethereum and Polygon, and therefore need an RPC endpoint to access these blockchains. This proposal encourages node operators to avoid all choosing the same blockchain provider, as this presents centralization and DOS risk. In the future, it may be possible to customize cohorts for diverse providers, and therefore there may confer an economic benefit to nodes who proactively increase collective infrastructural redundancy.

### Tl;dr The goal of this proposal is to add 10 community node operators to the tBTC Beta Staker program. ### Background tBTC currently relies on a permissioned group of nodes, referred to as "Beta Stakers", to secure the wallets that contain the BTC that backs tBTC. These nodes are highly reliable, and stake a significant amount of T. The goal of Part 2 of TIP-067 is to expand the Beta Staker by adding 10 additional community run nodes, and T staked across the beta staker nodes by 400M T. An increase in the number of beta staker nodes will increase the geographic dispersion of beta-stake operators, and also increase the distribution of key shares during DKG ceremony to improve system decentralization. ### Proposal The tBTC development team will vet and select 10 community node operators from applicants via this forum to be added to the Beta Staker permissioned group. ### Duration New Beta Stakers will be required to run their respective nodes until the conclusion of the Beta Staker program, expected to occur within 12 months. It is not possible to exit the Beta Staker program once added, which means that operators must continue to participate until the retirement of the program. ### Requirements Operators of Beta Staker nodes are expected to be extremely responsive, especially in regards to upgrades requested by software contributors. Ideally, they should be able to upgrade their nodes within 24 hours of notification. Community applicants will be vetted for demonstrable uptime via a review of historical T rewards, led by the Integrations Guild. Operators of Beta Staker nodes must be technically capable. They are responsible for ensuring high availability (more than 96% uptime) and security of the node. A Beta Staker node performs more computationally expensive operations (DKG, threshold signing, etc) compared to a standard Threshold node. To ensure a high level of service, a Beta Staker node requires a machine with: * 4 CPUs * 4 GB of RAM * 1 GB of persistent disk space * 80 Mbps of network bandwidth * Linux OS Other requirements include: * At least 1 year of historical uptime OR strong community presence and technical skills. * A minimum stake of 40M T, directly owned or delegated. Additional documentation can be found here: [https://docs.threshold.network/staking-and-running-a-node/tbtc-Beta Stakers-program](https://docs.threshold.network/staking-and-running-a-node/tbtc-beta-stakers-program) The DAO will reimburse Ethereum transaction fees (in ETH) directly to the respective operator addresses on a quarterly basis. ### Payment The DAO will make a payment of $1,500 USD/month to each community participant to cover additional overheads. Additional terms: * Payment terms are subject to nodes meeting the 96% uptime requirement in the month prior. Uptime below the minimum will result in forfeiture of that month’s payment. * Payments will be made in T in accordance with the T/USD price at 10am UTC on the final day of the month, as reported by CoinGecko. * Cost for the program will be covered by staking rewards generated from the delegated T in TIP-067 Part 1. * T rewards will be claimable by the Treasury Guild and distributed accordingly. ### Indicative Timeline * Nominations & Discussion Period - December 13th - December 27th * Candidate selection period - December 27th - January 3rd * Technical setup and troubleshooting - January 3rd - January 17th * Treasury Guild Delegation Execution - January 18th * New Beta Stakers added incrementally - January 19th - onward