|
| 1 | += The rewards pool |
| 2 | + |
| 3 | +A rewards pool is a contract that accepts arbitrary assets and mints a single |
| 4 | +reward token. Recipients of the reward token can at any time turn it in for a |
| 5 | +portion of the rewards in the pool. |
| 6 | + |
| 7 | +A rewards pool maintains a governable list of recipients and relative reward |
| 8 | +rates. For example, a rewards pool might have two recipients — a WETH |
| 9 | +collateral pool, and a WBTC collateral pool, with respective reward rates of 1 |
| 10 | +and 2. |
| 11 | + |
| 12 | +Rewards tokens are minted constantly over time and distributed according to the |
| 13 | +relative reward rates. |
| 14 | + |
| 15 | +== Accounting for rewards distribution |
| 16 | + |
| 17 | +Given the above scenario, at rewards pool creation. 3 rewards tokens are minted. |
| 18 | +1 is reserved for the WETH collateral pool, and 2 for the WBTC collateral pool. |
| 19 | + |
| 20 | +Every tick, an additional 3 rewards tokens are virtually minted. |
| 21 | + |
| 22 | +.Virtual rewards |
| 23 | +[frame="topbot",options="header"] |
| 24 | +|============================================== |
| 25 | +|Time | WETH virtual rewards | WBTC virtual rewards |
| 26 | +|1 |1 |2 |
| 27 | +|2 |2 |4 |
| 28 | +|3 |3 |6 |
| 29 | +|4 |4 |8 |
| 30 | +|============================================== |
| 31 | + |
| 32 | +At tick 5, if the rewards rates are changed, say to 1:1, the rewards tokens are |
| 33 | +realized, then the virtual minting continues at the new rate. |
| 34 | + |
| 35 | +.Virtual and real rewards |
| 36 | +[frame="topbot",options="header"] |
| 37 | +|========================================================================================== |
| 38 | +|Time | WETH virtual rewards | WETH real rewards | WBTC virtual rewards | WBTC real rewards |
| 39 | +|1 |1 |1 |2 |2 |
| 40 | +|2 |2 |1 |4 |2 |
| 41 | +|3 |3 |1 |6 |2 |
| 42 | +|4 |4 |1 |8 |2 |
| 43 | +|5 |5 |5 |9 |9 |
| 44 | +|6 |6 |5 |10 |9 |
| 45 | +|7 |7 |5 |11 |9 |
| 46 | +|8 |8 |5 |12 |9 |
| 47 | +|========================================================================================== |
| 48 | + |
| 49 | +Similarly, any rewards tokens that are exchanged and burned for the underlying |
| 50 | +pool rewards realizes all reward token minting before the exchange occurs. |
| 51 | + |
| 52 | +This structure should make it clear that reward pools scale in the number of |
| 53 | +ongoing reward recipients — with implications for the <<on-chain-efficiency, |
| 54 | +number of assets>> supported as collateral in a coverage pool. |
| 55 | + |
| 56 | +== Relation to collateral pools |
| 57 | + |
| 58 | +A coverage pool has a single rewards pool that receives and manages all |
| 59 | +underwriter earnings. Each single-asset collateral pool is assigned a relative |
| 60 | +rate in the rewards pool, establishing a way for governance to incentivize |
| 61 | +different assets to target a particular pool composition. |
| 62 | + |
| 63 | +If an asset that's accepted as collateral by the coverage pool is intended as |
| 64 | +underwriter rewards, it should first be deposited in the coverage pool, and the |
| 65 | +underwriter token sent to the rewards pool. Following this pattern means a more |
| 66 | +capital-efficient coverage rewards mechanism, though it also means rewards are |
| 67 | +subject to exit markets. |
| 68 | + |
| 69 | +== On-chain efficiency |
| 70 | + |
| 71 | +There are two bottlenecks in efficient runtime on the EVM with this structure. |
| 72 | + |
| 73 | +The first is the number of reward recipients. Each rate change and reward token |
| 74 | +burn require iterating through all recipients, computing rewards, and minting |
| 75 | +tokens. These costs are ultimately shouldered by reward beneficiaries, and place |
| 76 | +a ceiling on the number of simultaneous reward recipients. |
| 77 | + |
| 78 | +The second is the number of assets being rewarded. Anyone can send a reward pool |
| 79 | +whatever tokens they'd like. Instead of using an allowlist or pushing the cost |
| 80 | +onto reward token holders at redemption time, a short denylist can be used to |
| 81 | +avoid mischief, and reward token holders can decide which tokens they'd like to |
| 82 | +be sent at redemption. |
0 commit comments