I totally agree, good propolsal.
So what numbers are we looking for here? Letās throw some metrics out there that weād like to see so we can put together some rudimentary levels with some blockchain crawlers. Itās easy enough to parse the blockchain with a python script and if enough people are gathering info we will make quick work of this part of the proposal math.
It seems like the fairest way to assess loyalty is time staked (maybe a metric derived from combination of time and value staked)? Perhaps the total available to borrow before non-stakers have access could be proportional to this metric for each individual/wallet? and there is window of time to claim what youād like to claim out of your allocated opportunity amount before the public is allowed to feast on MIMs?
A potential issue when calculating loyalty or ālevelsā as theyāve been referred to above is that you donāt want someone with a large holdings for a short time to be measured as more loyal than someone with a small balance but holding since day 1.
The whole point of this is to ensure everyone can get some MIMs for being a part of the revolution.
It seems like fundamental information would be:
A) number of folks staking.
B) distribution of staked amounts among stakers.
C) Whatever else we think would be a good proxy for loyalty to the protocol.
Maybe liquidity providers of sSPELL/SPELL pools on smaller chains can also be rewarded some loyalty for providing that service? Of course weād rather everyone staked every solitary spell they have but this action permits the creation of more staking addresses which is beneficial to the protocol, though to a lesser degree. Something to consider as the proposal matures.
The more individual people that have access to MIM to cycle around the economy the better for sSPELL holders and the protocol in general.
Sorry for the long winded response, one last thing. Wouldnāt another way to solve the replenishment demand problem to be to issue the MIMs to the cauldron over a longer time period once sSPELL front runner window expires? maybe 0.5-1 million MIMs/hour for a given cauldron?
Spread sheet is updated (link above) with more detail on what difficulty vs levels vs end over end requirements etc. The models can be plugged away with, just make a copy of the sheet first.
Something that stands out on the 2nd tab is how fast the presale pool runs out of MIM. The current figures set a desired level of 10k MIM per person/address, which is a reasonable ask right? The data suggests otherwise.
Take a look and let me know if you see anything wrong with the math. We might have to reduce the per-person/address MIM allocation target down to a smaller amount like 2k for the time being.
I believe all the calculations are accurate. If anyone has time to review leave comments in the doc and here so I can update.
1 Like
This is great, you should write it up as an AIP and post it in the Governance Proposals section of the forum before we go to the snapshot phase. I like the idea of a ātaperingā or quadratic function to weight being applied, looks like the below square root graph. Ensuring large whales dont have a disproportionate ability to secure MIM
Check out what I have so far in the spread sheet I linked above. The level to hold time is using normal distribution with a given peak difficulty in end over end sspell holding requirements.
You need nothing to start with, anything above 1 sspell should qualify you to start on the first 30 day hold. Depending on what version of the bell (Mu: 0, -2, 2, etc) we want to go changes that level 1 entry point which is also selectable in 4 25% increments.
Each entry level represent a 25% claim towards the maximum amount of MIM reserveable per address and can range from starting with 1 sSPELL to 100k if you want to make the final entry point for whales only. The best part about all of this is every parameter is programable and can be shifted on the fly.
Before going any further and investing anymore time in this I would hope for feedback from an abracadabra dev on what metrics we have at hand to wire into the system. I have outlined a few above that would be really helpful to automate this curve. For example can we detect how long a presale lasts? We should be shifting the difficulty, Mu & STDEV values to attempt and maintain something useable like 2 hours before selling out.