Implement a logarithmic timeweight in V2 release

Current state: Currently, V2 is set to roll out using a linear timeweight to mitigate rewards to users that stake last minute.

Issue: This timeweight maxes out reward after just 6 hours. Users can still stake a relatively short amount of time prior to expansion events and extract significant value.

Proposal: Implement a logarithmic timeweight in V2 release. This timeweight increases resistance to short-term value extraction as the average user's staking days rise. The timeweight has individual timestamps for each staking event, and resets multipliers on a per-account basis upon an unstaking event of any amount.

Formula for timeweight multiplier in days: y=1+log(t+1) Formula in hours: y=1+log((t/24)+1) Formula in minutes: y=1+log((t/1440)+1)

Above formulas use y as the multiplier and t as time in respective units.

This timeweight continues to increase throughout each seigniorage as long as users do not unstake any MIS. An unstaking event of any amount resets all multipliers across all deposits to that account.

Multiplier Table for Reference (Rounded to 2 decimal places, but the timeweight will be accurate to eight) 0 days: 1.0 1 day: 1.30 2 days: 1.48 3 days: 1.60 4 days: 1.7 5 days: 1.78 6 days: 1.85 7 days: 1.9 8 days: 1.95 9 days: 2.0 10 days: 2.04 20 days: 2.32 30 days: 2.49 40 days: 2.61 50 days: 2.70 99 days: 3.0 999 days: 4.0 9,999 days: 5.0

As shown, the timeweighted log multiplier always increases as users stake longer. Epoch events do not reset any multipliers as long as the share holder did not unstake any shares. This multiplier decreases in speed such that staking for a moderate time will glean most of the benefits, I.e. to get to a multiplier of 3.0 you need to stake 99 days but for 1.5 its roughly just two days. Logarithmic timeweights have a "catch up" effect, that is, if someone has staked for x days, when you wait x days yourself, you'll be at almost the same multiplier.

The logarithmic timeweight uses individual timestamps for each staking event of any Mithril Shares, so if a user were to stake 100 MIS, wait 50 days, and then stake 100 more MIS, they’d have an effective 370 Mithril Shares in the pool. Afterward, if they unstaked 50 MIS, they'd reset the multiplier and have only 150 effective Mithril Shares in the pool.

Timeweighted multipliers do not increase the total amount of Mithril Cash minted, instead increasing the amount of effective Mithril Shares in the boardroom, altering payout proportions to favor long-term investors. Here's an example of how 30,000 MIC would be distributed if the entire pool consisted of two users that both have 50k MIS but stake it at different times.

User 1 stakes 50,000 MIS in the pool and waits 9 days for an epoch. User 2 stakes just moments before the epoch with the same amount of MIS. Total, there will be approximately 150,000 effective MIS in the pool with only these two users. Most of the newly minted MIC will go to the user who has waited longer, as user 1 has 100,000 effective MIS (50k times 2.0) but user 2 has only 50,000. If total MIC payout is 30,000, user 1 gets 20k and user 2 will get 10k.

Although this timeweight increases forever, the rate of increase slows down fast. It takes 99 days to get to a 3.0 multiplier, but 3 years is needed to reach 4.0. Should users wish to achieve a 5.0 multiplier 28 years is needed, and to reach a 6.0 multiplier, keys would need to be passed down generations, achieving 274 years of uninterrupted boardroom staking. As users that do not unstake in the near future apply no sell pressure, they should be rewarded the most.

Expected result: Long term increase in resilience protocol resilience. The boardroom will become exponentially more resistant to short-term profit seekers the longer the average user is staked.

Challenges: V2 will be delayed to or around 3/24. The delay will cause more MIS to be minted than is allocated for in V2. Only 350k MISv1 will be allowed to migrate, but with this delay a total of more than 350k MISv1 will be minted so there is a chance a sizable portion of MISv1 will not be migrated.

Voting options:

• Implement Log in V2 release: V2 comes out on or around 3/24
• Implement Log after V2 release: V2 comes out on or around 3/3, and log timeweight on or around 3/30
• Keep timeweight linear: V2 on or around 3/3