rewards halvening #577
rewards halvening #577
Conversation
I mean we could but it does add additional risk and will make it that bit more difficult to test and verify before going live. I think merging on the day is likely the best scenario here. The plan is to implement the reward curve into the code post this halving |
|
Would it make more sense to define some constant that is halving? So instead of having to manually halve all of the constants in the tests, we can just divide them by the constant? |
andymck
force-pushed
the
andymck/rewards-halvening
branch
from
826a2b8
to
60c6ce1
Compare
| @@ -18,7 +18,7 @@ const DEFAULT_PREC: u32 = 15; | |||
| lazy_static! { | |||
| // TODO: year 1 emissions allocate 30% of total to PoC with 6% to beacons and 24% to witnesses but subsequent years back | |||
| // total PoC percentage off 1.5% each year; determine how beacons and witnesses will split the subsequent years' allocations | |||
| static ref REWARDS_PER_DAY: Decimal = (Decimal::from(65_000_000_000_u64) / Decimal::from(365)) * Decimal::from(1_000_000); // 178_082_191_780_822 | |||
| static ref REWARDS_PER_DAY: Decimal = (Decimal::from(32_500_000_000_u64) / Decimal::from(366)) * Decimal::from(1_000_000); // 88_797_814_207_650.273224043715847 | |||
There was a problem hiding this comment.
Is the 366 because 2024 is a leap year? Are rewards not allocated per 365 days?
There was a problem hiding this comment.
correct its due to 2024 being a leap year which is accounted for in the number of days
This updates the iot and mobile verifier to account for the rewards halvening to be applied in August