Stable Yield + Conventional Rewards Architecture
The overall reward mechanism architecture comprises three layers, from top to bottom:
(1) DAO + Multi-sig council
(2) Inflation Contract
(3) Application
(1) The DAO mints a top-level sum of issuance (e.g. 25m tokens) on a quarterly basis. This is then split into subsidy budgets by the Multi-sig council and allocated to Threshold’s various applications – e.g. tBTCv2 will receive 10m tokens, PRE gets 5m, etc.
(2) The Inflation Contract provides special methods for applications which require the maximization of node population (at network genes is: tBTCv2, future: other apps) . This is achieved via the dynamic nominal inflation + stable yield mechanism detailed above. For those population-sensitive apps, the DAO mints, and Multi-sig council allocates, sufficient issuance for the ‘worst-case’/maximal participation scenario – e.g. if 90% of all tokens are authorized to tBTCv2, then a 10% target yield (APY) requires 9% nominal inflation (this equals some absolute # of tokens sent to the Inflation Contract – accounting for the fact it’s quarterly and the evolving total supply). The Inflation Contract contains methods that calculate a daily issuance figure for each application, based on the inputs of (a) total supply and (b) number of tokens authorized to the application in question. The contract then transfers this output issuance to the application contract once per day.
(3) The application contract then distributes the daily sum of tokens received from the Inflation Contract to stakers using simple, Unipool-style logic. The application distributes all of the tokens it receives per day.
*Note that population-sensitive apps like tBTCv2 will almost certainly have tokens left over and undistributed, held in the Inflation Contract, at the end of every quarter. The Multi-sig council manually adjusts subsidy budgets to account for this – e.g. if the initial (‘worst-case’) subsidy budget was 10m, and 5m were distributed, then in the next quarter the Multi-sig council would allocate ~5m to that application.
*This design allows the flexibility of applying the stable yield methods to any application in the future – for example, if a design change means that Random Beacon actually needs to maximize its node count or stabilize yield for some other reason.
*Note that if it proves to be overly costly (e.g. due to a spike in gas prices), the Inflation Contact could transfer issuance to applications more infrequently (e.g. weekly) while still largely preserving the predictability and sustainability benefits of the Stable Yield mechanism.
*This model leverages Multi-sig council-driven incentive adjustment, rather than capping staker numbers & a delegation system, in order to drive participation into/away from certain applications – e.g. too many PRE nodes might mean dropping the annual nom. inflation from 4% to 2%.
*Note that all applications will receive issuance via the Inflation Contract layer, but not all have this issuance adjusted daily by stable yield methods.
*The maximum dilution of passive holders annually is the sum of (a) the target yield for stable yield applications and (b) the nom. inflation for other applications – e.g. 6% tBTCv2 + 2% PRE + 1% Random Beacon implies a dilution ceiling of 9% per year.