TIP-032 Council decision: Reward allocation between tBTCv2 & PRE (overall target APY = 15%)


With the forthcoming launch of tBTCv2, the multi-app Threshold network is becoming a reality! Where else can you provide important, foundational services to both the Web3 (PRE) and DeFi (tBTCv2) worlds, using exactly the same collateral? It’s hard to think of a more capital-efficient diversification strategy out there.

This important juncture also requires the Threshold Council to proactively allocate rewards to the two co-existing applications – that is, splitting the total target APY of 15% across (1) tBTCv2 and (2) Proxy Re-Encryption. This yield will fall within an inflation/dilution ceiling of 15% – but in reality is likely to be significantly lower. That annual inflation rate is currently under 5%.

Token-holders control the top-line dilution figure, which avoids stakers ‘voting themselves a salary’, whereas the Threshold Council controls the allocation between apps – bringing greater agility in response to external events. For example, if a critical mass of tBTCv2 adopters (or prospective adopters) vocalized a preference for greater ‘decentralization’ – i.e. selecting from a larger node population, or even increasing each wallet’s <m-of-n parameters> – then the Council can speedily increase the application’s relative reward rate and attract dormant/prospective stakers to tBTCv2.

Community Input

Although the Council will sign the transaction and retains ultimate authority regarding the allocation, opinions from the community are encouraged – please share your thoughts here!

Some starter concepts:

  • Since the actual, absolute sum of tokens distributed (the issuance) fluctuates day-to-day, depending on the staking rate, it is easier to reason about the target APY (the annual growth in one’s stake). Currently, this APY is set to 15% and is entirely allocated to the PRE app.
  • Some portion of that 15% should now be allocated to stakers who spin up and run the tBTCv2 application.
  • This portion does not need to be static – it can be ramped up according to a schedule or based on milestones, as in the proposal below.
  • Although stakers do not have to move capital in order to support tBTCv2, there is non-trivial work involved in becoming a functional tBTCv2 node. This includes the initial set up and configuration effort, general maintenance/devops and availability requirements to avoid being slashed.
  • Hence, a guiding principle for all proposals might be sufficiently incentivizing existing PRE stakers to take the plunge and authorize their stake to this new and arguably more demanding application.
  • It is worth mentioning that tBTCv2 is not the end of the story. There are other Threshold applications on the horizon, with unique operational requirements and traction/fee potential.

Although the near-term split between tBTCv2 and PRE is the primary focus of this post, broader thoughts on reward design going forward may also be helpful.

Starter Proposal

We will propose to the Council that rewards are split according to the following schedule, where tBTC’s and PRE’s share of the rewards increases and decreases by 12.5% every month, respectively.

Month % Rewards to PRE % Rewards to tBTCv2 PRE Target APY tBTCv2 Target APY
Aug ‘22 100% 0% 15% 0%
Sept ‘22 75% 25% 11.25% 3.75%
Oct ‘22 62.5% 37.5% 9.375% 5.625%
Nov ‘22 50% 50% 7.5% 7.5%
Dec ‘22 37.5% 62.5% 5.625% 9.375%
Jan ‘23 25% 75% 3.75% 11.25%
Feb ‘23 onwards 25% 75% 3.75% 11.25%

This simple calendar is intended to coincide with the tBTCv2 release schedule – particularly quickminting functionality, which is due in January 2023. It also accommodates feedback from staking providers, who generally prefer a slower ramp-up as they prepare to support tBTCv2 node operation.

However, it is possible to tie the updates in the reward split to something other than time, provided that it is objective/on-chain (i.e. not ‘when x development milestone is completed’). For example, changes in the reward % allocated to tBTCv2 could be directly prompted by reaching predefined totals of BTC deposits – the idea being that the greater the sum of wealth managed by tBTCv2 nodes, the greater the incentive for collusion attacks, and therefore (arguably) the greater value in attracting more independent operators. On the other hand, tying rewards to deposits may be putting the cart before the horse – inasmuch as the primary purpose of rewards being subsidization in lieu of a sustainable fee market, so correlating rewards with commissions may not address the cold start issue.


Thank you for this proposal.
Exciting to see tBTCv2 becoming a real thing. Having a simple schedule that brings us to the final rewards split between PRE and tBTC during multiple months is a good approach imo.

I guess a fundamental concern for every node operator is not to skip any reward. Being the proposed schedule pretty tight I think we need more detailed information in regard to
what steps do stakers have to follow and when should that happen ?


Given the estimated launch is ~1 month away and there’s no test client for stakers and infrastructure providers to evaluate yet, I think it makes sense to start the initial tBTCv2 rewards at a smaller %, perhaps 12.5% rather than 25%.

I think very few, if any, infrastructure providers will be able to be online with less than 1 month preparation.


Updated split calendar based on @maclane’s feedback. I think the eventual equilibrium (now reached in Feb 2023) should remain as is – i.e. 25% of rewards reserved for PRE.

The Council could also execute the each scheduled re-allocation at the end of the month – i.e. the first rewards for tBTCv2 would commence towards the end of September.

Month % Rewards to PRE % Rewards to tBTCv2 PRE Target APY tBTCv2 Target APY
Aug ‘22 100% 0% 15% 0%
Sept ‘22 87.5% 12.5% 13.125% 1.875%
Oct ‘22 75% 25% 11.25% 3.75%
Nov ‘22 62.5% 37.5% 9.375% 5.625%
Dec ‘22 50% 50% 7.5% 7.5%
Jan ‘23 37.5% 62.5% 5.625% 9.375%
Feb ‘23 onwards 25% 75% 3.75% 11.25%
1 Like

Executing the reallocation at the end of each month by the Council makes sense since provides some flexibility to prevent needlessly incentivizing rewards and adjust accordingly.

A seemingly simple initial milestone is the availability of the test client to kick things off. Without the test client, starting to incentivize rewards would presumably be unnecessary. Would the Council have the implicit authority to shift the timing if the test client wasn’t available at the start of September but instead at the start of October? So effectively, the intended 12.5% tBTC rewards increase carded for the end of September would be delayed to the end of October - subsequent monthly increases would be delayed by a month. Alternatively, to still hit the Feb’23 intended ratio, an adjustment made to the monthly increase percentage if required - although depending on how drastic such a change would be it may require broader DAO discussion…?

Unsure if there are any other possible clear-cut milestones within the rest of the proposed timeframe that would make sense to use and how those may affect the allocation of tBTC. Perhaps if not currently foreseeable, those updates can be up for discussion and revisited at the appropriate time.


It also makes sense for tBTC v2 rewards to officially start on Oct. 1st but anyone who sets up a node before Oct. 17th earns full rewards for the month.

To @Eastban’s point this gives everyone in the DAO enough time to set up their nodes so as to not miss any rewards.

The split for the month would stay the same.