[Proposal] Voting mechanism for staked Pickles

[0xBoxer]

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.

TLDR:

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:

1. 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)

2. 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

Context:

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.

Proposed solution

1. Implement a reduced voting power approach(1/x) to allow voting in the RewardsStakingContract.

Current System/Background

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.

TTLDR:

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.

References:
my excel sheets for the graphs:
https://1drv.ms/x/s!AscDEOrmHdQCqkXXB_jGwoHDh00c?e=s1KPZQ)

prior discussions:

Voting rights for P2(ETH/PICKLE) + Pickle Stakers

There seems to be a reasonable discussion for including Naked Pickle stakers into the existing governance (voting) process. I’ve had some initial thoughts on this and just wanted to jot them down here to reference later + start the convo going for how others might imagine it could work to include them into the voting process. I’ve been toying around with the idea of using either a “cubic” or “quadratic squared” vote qty to align their structure with the existing whale-limiting quadratic method…

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

[Dr.Eggplant]

Truly fantastic work @0xBoxer. Thank you for consolidating all the discussions on this topic from Discord and these Forums into the most thought out and quantitatively driven proposal we’ve had on the topic yet.

I personally believe the maturation period for maximum voting weight should be 28 days (1 month) and Staked Pickles should receive up to 75% of the voting power that Pickle Pool participants have.

Looking forward to everyones thoughts!

[Rooster_Cogburn77]

Great work on putting this together!

I like the 28 day maturation period for stakers.

In regard to voting power, I am for capping it at 50%, if not less. Very little risk in staking pickles and the LP providers should maintain a clear voting advantage. Would not be mad about seeing it closer to 33%, but 50% is not terrible.

Thanks for the effort put forth in this proposal!

[projectuwb]

@0xBoxer mate, thanks for such a detailed post on this. I have really wanted to vote on a lot of the PIPs but have been unable to due to my inability to take the risk of being in the death pool. I agree with your proposal for 50% voting rights on the basis that Pickle Stakers (long term) take about 50% of the risk as Power LPs if they hold through the ups and downs. The maturation period also in my opinion is reasonable. Will be really interested to see if someone can think of the unusual attack vectors on governance with this proposal.

[Peachy]

This is a solid effort towards achieving the goal of inclusiveness for all pickle privates.
I don’t really have any criticism to offer.
Well done!

The maturation process seems logical and fairly straight-forward to implement as it’s quite similar to the AMPL Geyser code that’s been utilized frequently already.

[2x1q7f9]

Pickle/ETH LPs do not assume as much risk as Pickle holders as half the notion is exposed to ETH, so they are only taking on half as much risk. A little more due to IL but not nearly enough to bring it close to 100%. If the price of Pickle falls 50%, they will lose just over 25% whilst Pickle stakers lose all 50%.

As a result, Pickle holders should have a voting power that exceeds LPs. They should also receive yield that exceeds LPs. Currently the yield to the Pickle/ETH pool is purely from emissions. If some of those emissions are redirected towards jar emissions, then that would provide higher yield to the strategies and attract more capital which would result in higher revenues for the protocol. This revenue then goes back into the dev fund and the treasury, and the excess gets paid out to Pickle holders thus increasing the yield for staking. Devs now have more capital to work with and can look to expand if they want. Things scale. Pickle grows.

Think the weight should scale up to a maximum of 2x that of LPs on voting power.

[Dr.Eggplant]

Totally fair point and good observation! The narrative should be reframed from:

Pickle Pool is taking on more risk by being a LP

to more accurately…

Pickle Pool is providing a service by providing liquidity and should be rewarded.

This will change how we see things. Perhaps an idea could be to make STAKER and LP voting equal to a 1:1 ratio but still have Stakers have the 28 day ramp up period to encourage long-term holding?

If someone wants to become a LP they don’t have that period and can vote immediately.

Thoughts?

[0xBoxer]

paging @leekuanjew, our personal professor of tokenomics to explain this to us humble students

[2x1q7f9]

Yes, and those rewards should be scaled down over time. Emissions should be treated as targeted inflation and should be pointed at whatever needs to be incentivized. Incentivizing liquidity for the token is important, incentivizing liquidity for the strategies is even more so. The former gives Pickle value based on liquidity, the latter gives Pickle value based on revenues and will be more than enough to support price in secondary markets.

[yyctrader]

Great proposal!
I fully support voting rights for stakers…an essential next step towards a true DAO.

@leekuanjew Please decipher the math for us mere mortals

[Tomato_Juxx]

Great proposal! I’m all for it!

Only one survey is missing to gauge the opinion of the community

[0xBoxer]

I’ll add the Sentiment vote tomorrow or in the next few days.
I would like to hear more opinions on this from the dev team (@BigBrainBriner @0xpenguin @Larry_Cucumber) and other community members to maybe change a few parameters and hear about the feasibility of such endeavors. Having a vote now already is only noise, not signal.

[chimaera]

Great proposal on a topic that I think is fair to say, one that has almost universal community support and has done since staking was introduced.

I’m for 50% (least arguable and I think @Peachy 's cubic approach was close here ) and 1 month (long enough to prevent “stake and vote then dump” approach but not so long it’s out of sight)

It’s also one that the Devs have been notably quiet on … Which means I expect this combination of LP and Staking vote rights is a considerable undertaking. Even so there comes a point where a strong community that wants/needs to be able to have a say in governance is arguably more important than a new strategy.

[leekuanjew]

Great proposal, @0xBoxer. I have no issues with your maths. Let me take the time to elucidate a point on tokenomics rather than the voting power itself.

First, to say, I am not against giving voting power to stakers, but we’d need to rebalance the staking rewards (share of protocol fees). Currently, all the excess above Treasury cap goes to stakers. In fact, the main issue with these type of changes to the protocol is we continue to add incentives to stakers without balancing them properly with additional incentives to LPs/farmers.

The crux of the matter is what @Dr.Eggplant mentioned, that an LP is providing a service to the protocol. A service that, if it weren’t rewarded properly, would hurt the health of the protocol. The biggest beneficiary of high liquidity is actually the staker, not the LP itself. For that reason, we need to balance the distribution of protocol fees (currently given only to stakers above the treasury cap) according to voting power. This is to avoid “overrewarding” stakers – this becomes more important as our emissions curve starts to flatten and we get more and more from protocol fees. We shouldn’t “flip” these APYs anytime soon.

My intuition tells me 28 days is a relatively short period to achieve maximum rewards, 3–6 months would be more appropriate. However, the incentive would need to be boosted as well. Meaning, the number of rewards for stakers should increase with voting power, to make it worthwhile for people to go for the maximum voting power factor.

Another issue we should think about with any novel system is engineering time. This proposal is different enough from contracts deployed by, say, Curve, (and I think mStable) where voting power is a boost to rewards given as an LP. So, we’d have to basically develop this implementation fully in-house. Particularly if we follow my corollary of balancing new monetary incentives so as to not encourage destabilizing the system in favour of naked staking, we’d need a mechanism for LPs to capture their fair share of protocol fees set for distribution to PICKLErs.

[BigBrainBriner]

@0xBoxer

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.

Unfortunately, tracking the number of days staked is not possible with the current StakingRewards contract. There is no record of which you can know the last time something was staked. It gets confusing if you stake X amount today and then stake Y amount tomorrow. This would require a significant contract rewrite.

Beyond that, it’s unfair to characterize LPs voting power as being simply derived from the underlying assets of the Univ2 LP tokens.

Like @leekuanjew said, they are providing a service and they take on massive IL risk. These are premiums that are left out of the original equation. There is also a presumption of sophistication that you get from LPs which you may not from naked stakers since they can just pop in and pop out (although admittedly a large part of this is solved by the maturation idea).

That is not to say that I don’t believe stakers should have some kind of voting power, but the practicality and the incompleteness of the equations are just not convincing enough for me at this point.

TLDR:

• tracking time staked is tough (requires writing new smart contract)
• value of LPs cannot be fully captured by the equation at the premise
• the value that LPs bring vs naked stakers are qualitatively different and would require a lot more rigorous mathematics to sufficiently model, and I would argue is actually impossible to reconcile as there are too many intangibles, but I am open to changing my mind if a convincing argument arises

[0xBoxer]

I appreciate your input on this topic and see the points you are raising, but I think some of your criticism is unwarranted.

@BigBrainBriner

Beyond that, it’s unfair to characterize LPs voting power as being simply derived from the underlying assets of the Univ2 LP tokens.

I merely put the content of how we calculate voting power currently in equations.
It may be unfair to characterize LP’s voting power only from the value of the underlying assets, but that is the way the system is currently working.

I agree that the LP’s are valueable actors in the ecosystem, have to be incentivized and should have more voting power inside of the system.
That’s why I chose to go down the route of discounting the voting power of naked stakers.

In my Eyes we “only” need to find a fair balance between the voting power of Stakers and LP’s. The determination of voting Power of LP’s is already in place, therefore I think it’s fair to apply that same methodology to stakers and discount their voting power based on the lack of value they are providing for the ecosystem.

@BigBrainBriner

Unfortunately, tracking the number of days staked is not possible with the current StakingRewards contract. There is no record of which you can know the last time something was staked. It gets confusing if you stake X amount today and then stake Y amount tomorrow. This would require a significant contract rewrite.

That’s unfortunate, but was to be expected.

This is a topic more technically minded people can surely discuss with more success than I can, I think the maturation Idea is pretty neat and would love to see it implemented.

@leekuanjew

Another issue we should think about with any novel system is engineering time. This proposal is different enough from contracts deployed by, say, Curve, (and I think mStable) where voting power is a boost to rewards given as an LP. So, we’d have to basically develop this implementation fully in-house. Particularly if we follow my corollary of balancing new monetary incentives so as to not encourage destabilizing the system in favour of naked staking, we’d need a mechanism for LPs to capture their fair share of protocol fees set for distribution to PICKLE rs.

Taking into consideration these remarks as well, I think that at some point in the future we should combine all these reforms to rewards and voting into one single act that’s going to eat up a lot of engineering time. Therefore it seems the best cause of action is to let this topic rest for now and revisit it at a later point when we have found consensus and mechanisms for the points raised by @leekuanjew.

[Dr.Eggplant]

I don’t think the topic should be let rest. If it is allowed to rest it has a far less likelihood of being picked back up.

The reality is solving this problem is going to be time-intensive, complex, and frustrating, but that’s OK.

If we break this problem down into manageable steps that we will solve for, it becomes tackleable.

We all agree that stakers should receive some voting power. Then, the first and most fundamental qustion we should reach a conensus on before technical implementation discussion is this:

How much voting power and over what time frame?

Let’s focus the discussion on this.
I believe stakers should receive 75% voting power and a 28 day ramp up period. My original opinion hasn’t changed. I believe 3-6 months as @leekuanjew mentioned (great post ty) is too long. In DeFi that may as well be 100 years.

So let’s focus on the bolded question above. I will re-circulate this forum post to the community to solicit more opinions.

[Peachy]

Have you look into the AMPL Geyser smart contract for how they do it? I’m totally not solidity savvy, but they handle things like X amount staked today and Y amount staked tomorrow as 2 different events with their own rewards multiplier (unlocking). Just something to consider

[Mah_Dills]

I was thinking the same thing here about the 75% weight. @0xBoxer love this proposal and calculations. The staking weight should be 75% LP (pickle power) voting power. Make that one adjustment and this has my full support.

[Dr.Eggplant]

Bumping this to the top.