Closed derekpierre closed 3 years ago
Merging #87 into master will increase coverage by
0.31%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #87 +/- ##
==========================================
+ Coverage 51.69% 52.01% +0.31%
==========================================
Files 11 11
Lines 1062 1069 +7
==========================================
+ Hits 549 556 +7
Misses 513 513
Impacted Files | Coverage Δ | |
---|---|---|
monitor/supply.py | 98.91% <100.00%> (+0.08%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update dfe7082...14e8ceb. Read the comment docs.
One of the interesting things here is that in our sub-stake allocation calculations we did the following for determining the locked periods for a sub-stake,
round(i * 30.416)
i
is the number of months for the duration.Eg. for 24-month allocation eg. SAFT2 we did
round(1 * 30.416)
= 30 locked periodsround(2 * 30.416)
= 61 locked periodsround(3 * 30.416)
= 91 locked periods ...round(24 * 30.416)
= 730 locked periodsTherefore when trying to do the opposite for the
supply_information
endpoint for determining number of already vested tokens i.e. using how many months have transpired based on the number of days since launch, our calculation becomes tricky, because the original calculation of number of periods may have rounded up or down. We want to know given that the time is today, and x periods (days) have transpired since launch, how many months of vesting have occurred and therefore we can determine the number of tokens that have now become unlocked.Determining the days transpired since launch is easy since the number of days can be determined by a maya datetime. However, when determining the number of months from those days, the calculation becomes nuanced.
A simple solution is
days_transpired / 30.416
for the number of months transpired but this is a float - do we round up or down? Because the original calculation that was done (round(months * 30.416)
) can round up or down, we need to do some extra work.Take the scenario where 30 days have transpired since launch,
30 / 30.416
= 0.9863 months.round(1 * 30.416)
= 30 days.90 / 30.416
= 2.959 months which if I round up is 3. However for 3 months to pass from the allocations calculationround(3 * 30.416)
= 91 days needs to have transpired but in this case, only 90 days have passed.Therefore, to correctly calculate the months transpired based on the days transpired, I do the following:
actual_days_transpired
using difference in maya datetimemonths_transpired = actual_days_transpired / 30.416
ceil_months_transpired = math.ceil(months_transpired)
expected_days_transpired = round(ceil_months_transpired * 30.416)
actual_days_transpired >= expected_days_transpired
(really just equality since actual_days_transpired can't be greater than expected_days_transpired because we useceil
)math.floor(months_transpired)
See the unit tests for some concrete examples of my thinking.