cgp | title | date-created | author | status | date-executed | governance-proposal-id |
---|---|---|---|---|---|---|
33 |
Activate Dynamic Voting Reward Rate Adjustment Factor |
2021-06-29 |
@tobikuhlmann |
EXECUTED |
34 |
This change activates dynamic staking reward rate adjustment by setting the staking yield adjustmentFactor
to a positive value of 0.00000112799. Currently the staking reward rate adjustmentFactor
is at zero which keeps the staking reward rate constant at 6%.
Staking and voting in Celo competes with other uses for the CELO token. With competing reward opportunities like Ubeswap yield farming for CELO evolving, it is becoming more and more important that the voting reward rate can adjust quickly to ensure reasonable voter participation, as we may see the voting participation drop. It is important for the security of the network for staking to be sufficiently attractive, and the dynamic voting reward rate adjustment ensures so.
The dynamic target voting reward rate adjustment factor adjusts the target voting reward rate automatically based on deviation of actual voting CELO fraction to target voting CELO fraction in every epoch. The target voting percentage is currently set to 50%, with the actual voting percentage being ~60%. CGP 34 proposes to increase the voting percentage target to 60%. If the voting percentage is below the target at the end of an epoch, the staking reward rate is increased; if the voting percentage is above the target at the end of an epoch, the staking reward rate is decreased.
Parameter Details:
- targetVotingYieldParams.adjustmentFactor: 0 --> 0.00000112799
- targetVotingYieldParams.max: unchanged 0.0005 ((x + 1) ^ 365 = 1.20)
The size of the staking reward rate adjustment in every epoch is calculated by multiplying the difference of the voting percentage and the target voting percentage with the adjustmentFactor
. With a target voting percentage of 60%
or 0.6
as proposed in CGP 34, the maximum distance from target is 0.6
. With the proposed adjustmentFactor
of 0.00000112799
, the largest possible change of the annualized staking reward rate over the course of one year therefore is (1.00016 + 0.6 * 365 * 0.00000112799)^{365} - (1.00016)^{365} = 0.1 = 10%
. This would only occur if the voting percentage would reside at the extreme of 0% at every epoch of the year.
Since the current voting percentage is at ~60% and the target 50% (If GCP 34 to increase target to 60% would not pass), the target reward rate would reduce from 6% to ~4.4% over the course of one year, if voting participation would stay constant at 60%. (1.00016 - 0.1 * 365 * 0.00000112799)^{365} - (1.00016)^{365} = -0.01581
.
If CGP 34 passes and the target voting percentage increases to 60%, almost no adjustment is expected when the actual voting percentage remains at ~60%.
The related targetVotingYieldParams
parameter max
, which provides an upper bound above which the staking yield would not be increased dynamically, remains unchanged (at 20% annually) by this proposal.
- Set EpochRewards Adjustment Factor
- Destination: EpochRewards, setTargetVotingYieldParameters
- Data:
- max = 500000000000000000000 (0.0005 * 10^24)
- adjustmentFactor = 1127990000000000000 (0.00000112799 * 10^24)
- Value: 0 (NA)
Check that the targetVotingYieldParams.target
through [getTargetVotingYieldParameters] is dynamically adjusted (no longer static at 0.00016 (value that represents annual 6% yield (x + 1) ^ 365 = 1.06).
https://explorer.celo.org/address/0x07F007d389883622Ef8D4d347b3f78007f28d8b7/read-contract
- Voting participation could be too sensitive to target voting yield changes. The value of
adjustmentFactor
could be too large in that case. However, the opposite has been the case so far: Voting reward rate has decreased from 0.06 to 0.053 and voting CELO fraction has been increasing from ~0.5 at epoch 50 to ~0.6 at epoch 400 - Voting participation might not be sensitive enough. The value of
adjustmentFactor
could be too small in that case to effectively increase voting participation when it’s dropping. In that case, however, a small adjustmentFactor would be better than none at all, as it is currently.