Update calculation of months transpired since launch for `/supply_information` endpoint

[derekpierre]

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)

• 30.416 is 365/12 i.e. an average of the number of days in a month
• i is the number of months for the duration.

Eg. for 24-month allocation eg. SAFT2 we did

• Sub-stake_1 had a duration of 1 month i.e. round(1 * 30.416) = 30 locked periods
• Sub-stake_2 had a duration of 2 months i.e round(2 * 30.416) = 61 locked periods
• Sub-stake_3 had a duration of 3 months i.e. round(3 * 30.416) = 91 locked periods ...
• Sub-stake_24 had a duration of 24 months i.e. round(24 * 30.416) = 730 locked periods

Therefore 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,

• months_transpired = 30 / 30.416 = 0.9863 months.
• If we just round down, then technically this is 0 months of vesting, however, it should be 1 month because round(1 * 30.416) = 30 days.
• I can't round up because it may work in this instance (after 30 days), but what if 90 days have passed:
  • 90 / 30.416 = 2.959 months which if I round up is 3. However for 3 months to pass from the allocations calculation round(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:

1. calculate actual_days_transpired using difference in maya datetime
2. determine months transpired without rounding i.e. months_transpired = actual_days_transpired / 30.416
3. round up the months transpired calculation i.e. ceil_months_transpired = math.ceil(months_transpired)
4. calculate the expected number of days to transpire for the rounded up months transpired based on the allocation calculation i.e. expected_days_transpired = round(ceil_months_transpired * 30.416)
5. Check whether actual_days_transpired >= expected_days_transpired (really just equality since actual_days_transpired can't be greater than expected_days_transpired because we use ceil)
   • If True -> then sufficient days have passed and return months transpired = ceil_months_transpired
   • If False -> then insufficient days have passed and months transpired should be rounded down i.e. = math.floor(months_transpired)

See the unit tests for some concrete examples of my thinking.

[codecov-io]

Codecov Report

Merging #87 into master will increase coverage by 0.31%. The diff coverage is 100.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.