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