Implement a “time based voting power” mechanism for the staking contract
I worked on this with Dr.Eggplant, TLDR and TTLDR are his works and he has been helpful to bounce ideas with.
I propose that Pickle Stakers should receive voting power. Because they are not taking as big a risk as Pickle Pool LPs and are not providing value I think they should have less voting power. My solution is:
- Give Pickle Stakers a fraction of voting power relative to Pickle Pool LPs.
i.e. (If LPs have 100% voting power, Stakers will have 50% of that power with the same underlying value)
- To compensate for people trying to buy elections, implement a maturation system
i.e. (A 28 day period where your staked pickles increase in voting power until they reach 100% power…which in combination with 1) is 50% of a Pickle Pool LP’s power
I think the community has voiced loud and clear a demand for voting rights for Pickles staked in the Staking Rewards Contract. Despite already running on a quadratic voting mechanism this could implement an attack vector into our system, if not implemented carefully.
In this proposal I will explain how we can implement such a solution based on weighted voting power with a maturation period which would minimize the attack vector and reward LP’s for their work.
- Implement a reduced voting power approach(1/x) to allow voting in the RewardsStakingContract.
To understand how my proposed solution is working, we first have to take a look at how our current system works.
The voting Power is currently determined by the square root of UNIV2LP Tokens you have in the Pickle Power Pool.
The Value of UNIV2 Tokens is currently 213$, you can check this by pasting the contract adress 0xdc98556Ce24f007A5eF6dC1CE96322d65832A819 into https://yieldfarming.info/tools/uniswap_pair/
The value is determined by:
Knowing this we can say that 1 Voting Power is equal to the square root of value locked divided by the price of 1 UNIv2.
Weight of StakingRewardContract Votes
If we now apply this principle to the Pickles in the StakingRewardsContract we arrive at following formula:
I don’t think that this is the right solution, since StakingRewardContract Stakers would have the same voting rights with no risk exposure or value that they are adding to the system. I thereby propose to weight their votes with only a fraction of the power. (1/X)
Personally I would say half the power seems reasonable, but I am encouraging discussions around this topic.
With my proposed solution of ½ the voting power the distribution would look like this:
2. Maturation period
Based on the first principle, I also want to introduce a “time based voting weight” which has a maturation date of 28 days. This would mean that only after 28 days voters in the RewardsStakingContract would have their full voting Power available to them.
The 28 day period is also content for discussion, therefore I have implemented this as Y below.
I can’t remember a way to state this in mathematical terms, but this should apply:
Visualisation of a weighted approach with maturation period of 28 days
If we combine both approaches with my proposed solutions we would reach the following voting distribution.
Stakers have up to 1 month to achieve maximum voting power which would be 50% of someone who is an LP in the pickle pool with the same underlying value.
my excel sheets for the graphs:
Open for discussion:
What should the weight of voters in the RewardsStakingContract(RSC) be ?
Is the maturation Idea a good one and how long do you think the maturation period should be ?
Is it possible to implement this on a technical level and what would be the difficulties ?
As @projectuwb stated below, Is there any unusal attack vectors that get opened up by this ?
e.g. manipulation of UNIv2 underlying value