Governance Overhaul and Future Rewards

[boatonagoat]

@dudesahn
Seconded, thanks for putting together this synthesis of the views in the thread.

[mattdw]

@dudesahn

• Replacing yCRV rewards with yUSD is an improvement. However, after a lot of thought, I believe we should distribute YFI as rewards to governance stakers in place of yUSD. I know this is controversial, and I used to be against it. But the reason I am for it is not to support YFI price with buying pressure, but instead to put more YFI in the hands of those who are voting and governing the protocol. It is a token meant for governance, and therefore I believe it makes total sense to concentrate it in the hands of those who are actively participating in governance.

This is exactly my feelings when I proposed this about a month ago. Thanks for bringing it back up!

[Coopahtroopa]

Thanks for the summary @dudesahn

My take:

1. Snapshot - Yes
2. Time-weighted Vote - Yes but with modified tweaks to veCRV system (constantly decaying voting power is problematic IMO)
3. yUSD - Yes

Excited to see how these play out!

[jimsox]

@dudesahn

But I also believe yUSD is an improvement over yCRV, especially for small voters, as they are earning more interest as it sits before claiming.

This is the biggest win for the small guy because it lets them not have to claim their rewards. If they are paid with YFI, for them to actually gain something from it (eg add it to their gov stack to compound) they must spend gas to get it. If its yUSD, it can stay there unclaimed but still grow on its own via the yVault.

If the people who can afford to claim more regularly do so, they can convert their yUSD to YFI themselves if that is in fact what they want.

[crepeislife]

Should we move to off-chain voting with Snapshot?

Yes, I feel like it would encourage more participation for those that are holders but cannot necessarily avoid the gas costs, especially on days where it was approaching 500gwei. This is vital to implement but can be re-assessed once the transaction cost issue is remediated by ETH.

Should we allow YFI not staked in governance to vote?

I would vote no. In combination with the next proposal, would ensure that only those with a longer-term, truly vested interest in the protocol (vs just speculation) are considered while voting.

Should we implement a gYFI system with time-weighted vote locking?

I’m for time-weighted vote locking, but undecided on a separate gYFI token. I would not want one implemented if it were transferable. I feel it would inevitably be traded in a secondary market; which dilutes the true holders vs. those that just speculating.

Should we implement yUSD rewards in place of yCRV?

I’m still undecided on this proposal as I would prefer a more “pick what you want” type reward system for staking. Would anyone consider an option that’s elected upon staking that generates the rewards to the user’s preference? (in other words, you can actively change the reward you prefer to receive while any amount of YFI is staked in governance).

Thank you for summarizing the proposals @dudesahn

[darkcoinminer]

I am for exploring off-chain vote aggregation (via Merkle root validation, as suggested earlier).

I am against everything else. It will be too difficult to continuously block exchanges and yield should only come from using YFI itself, not synthetics written against it.

[LapisLime]

I generally agree with this @crepeislife

@crepeislife

I’m for time-weighted vote locking

I disagree that we need vote locking. I’d prefer that holders have choice if that can be consistent with good governance. I believe it can. For example, if vote power (and also perhaps rewards) increased over some period of time, we would not need to lock people into that decision – there would be natural incentives to keep YFI in governance to take advantage of the increasing vote power and natural disincentives when the YFI in removed – all without a lock.

@crepeislife

you can actively change the reward you prefer to receive while any amount of YFI is staked in governance

I like this idea. We should keep in mind that for small holders, it may be most cost effective to have those rewards sit for a while as they accumulate. If there were a way for additional earned YFI to be automaticlly added to a holder’s staking account to be used for additional voting, that could help small holders.

[sadcat]

@banteg

But I think the answer is educating the users that it’s never okay to lend more than 1/3 or your votes.

Voting with lent YFI allows infinite multiplication of voting power. Lend 1 yfi, borrow (using other account, if necessary), lend, borrow… it can continue indefinitely as long as you have enough non-yfi collateral. So lending less than 1/3 has no effect. Even 0.01 yfi is enough for this.
I think voting with yfi in balancer and uniswap pools is fine. Anything that lends yfi - no, including yvault, because it would also lead to double counting.

edit: although allowing yfi elsewhere to vote is likely to increase problems with achieving quorum, so perhaps it’s best to not overcomplicate the system and keep voting just to the gov contract.

[Beepidibop]

@LapisLime

I disagree that we need vote locking. I’d prefer that holders have choice if that can be consistent with good governance.

I was in the same boat until I saw what @banteg said on discord.

I’m also going to copy over my response to that:

My problem with weight decay is you have to constantly refresh your “lock” like currently on veCRV

But now that I think about it some more, this problem can be easily avoided by doing the following:

1. Send YFI to SC with “infinite lock time” while also telling it how much time-weight you want (say 1 yr)
2. The SC doesn’t automatically allow you to withdraw after 1 yr, and your weight doesn’t decay. Instead,
3. You call an SC “withdraw-signal” function which tells it to unlock your YFI within a year. Only when this function is called, your weight starts decaying
4. You get to collect your YFI either on a timed-release or at the end of that 1yr

Example:

1. Wallet A tells SC it wants the maximum weight (say 1yr), but really, Wallet A wants to stake for 2 years and doesn’t want to constantly refresh their stake during the first year
2. Wallet A lets YFI sit in the SC for a year, without interaction with the SC (gas). The SC doesn’t decay their weight because the “withdraw-signal” function haven’t been called
3. Wallet A calls “withdraw-signal” after year 1 is up, planning to withdraw at the end of year 2
4. SC processes the call, starts decaying weight
5. Wallet A collects time-released YFI or the whole lump sum at the end of year 2(edited)

Edit: On deposit, the staker can tell the SC how long their “withdraw-signal” should last, and that is used to determine their weight.
Example:

1. Wallet B haven’t made up their mind on how long to stake, but figures a 3day notice satisfy their needs.
2. Wallet B tells the SC their withdraw-signal should be 3 days long while depositing, SC determines their weight to be 3 days.
3. Wallet B goes MIA for 6 months, weight doesn’t decay (still remaining 3 days).
4. Wallet B signals after 6 months, retrieve coins in 6months+3days, while having 3day weight up until 6months, and start decaying when the “withdraw-signal” is called.

And there should probably be a function that lengthens your signal period so you don’t have to wait to unstake then stake again . But there shouldn’t be one for shortening the period

If we implement it this way, you have the option of choosing whether to vote lock your self or not, for how long, and don’t have to constantly lock/restake it. You can even say you don’t want to lock and receive the regular 1x voting power.

[LapisLime]

@Beepidibop

I was in the same boat until I saw what @banteg said on discord.

Is this the best way to prevent someone fucking up the protocol? If someone did, many would be locked. The first to hit the end of their lock times would get out first. Somone who borrowed the YFI to fuck with the protocol would have an easier time paying back the loan if the value drops.

Edit: I will add that giving YFI holders choice may encourage more YFI to be staked in governance, which has its own benefits, including making it more difficult to mess with the protocol.

[Beepidibop]

@LapisLime

Somone who borrowed the YFI to fuck with the protocol would have an easier time paying back the loan if the value drops.

This is honestly something that I missed. I’ll have to get back to you on that one. It does look like locking benefits the attacker if the attacker borrows YFI instead of buying. Which defeats the argument that the price of YFI will keep the protocol safe.

Question I’m asking myself right now is. How to ensure someone who borrows YFI can’t screw us up while at the same time preventing the scenario of build weight>screw up>dump.

@LapisLime I have made a separate thread discussing preventing YFI borrowers from attacking the protocol, since I think it’s a topic worth discussion in a separate thread.

[jwe000]

I like the proposal for the most part, but I don’t think there should be extra rewards for voting. Just staking in governance should get the same return, and the current method would remain to claim rewards. Having to vote for everything, not just the items someone cares about doesn't make sense. I want to make sure voting power and rewards are not intertwined. If they get intertwined, it could negatively affect the value of YFI affecting everyone.

[LapisLime]

I agree that claiming rewards should not depend on whether you voted or not – just that you are staked in governance. I am however ok with increasing voting power and rewards for those staked longer (up to a limit, say a linear increase for 60 or 100 days).

[1centwhale]

1. No, CEX’s would be awesome to include but only if they meet full transparency requirements that the community can put together. Create strict rules and they can decide if they opt in or out. Eventually full transparency might be worth if for them to keep users.

2. 100% only for governance stakers. I’m also for disincentivizing very risky behavior with YFI. Take risks with basically any other asset but when I saw a large portions of YFI in [most food name] pools it made second guess the whole YFI community.

3. I don’t know enough about it and will likely follow the community thought leaders I align with. This almost makes me wish I could delegate my votes.

[laur_science]

Only YFI staked in governance should get rewards. Staking in governance is like hodling, it gives strength to the store of value property of the token.

For this reason, I don’t agree with that part of the proposal. But definitely… move governance off-chain. For me personally, the costs of voting are too high.

[Consultant]

All valid points…can you take this further and propose your solutions.

[riedbomb]

On a side note can we not have all these new video makers and twitter accounts get any money from us for now just because they saw on twitter our small grants and think we just give away money now.

[riedbomb]

I thought this through more, you know better than me honestly.

I’ll let all of you take the lead and I’ll vote appropriately.

[amphiboly]

I think the proposal is well intentioned and practicable, but I have a few concerns.

1. As @jiecut flagged, this does not prevent voting with borrowed YFI. While @banteg says we can educate users to not lend more than 1/3 of their votes, once again, I think this creates the risk that those education efforts fail and users become upset when they don’t have the voting power they would intuitively expect.

2. Are there other alternatives for reducing gas fees for small voters? I.e. could we subsidize them?

3. If users are afraid of not being able to vote because their YFI is sitting in a vault or some protocol they shouldn’t invest that YFI. I think this model actually promotes good governance because it increases the signalling value of a vote; in order to vote the voter has to forego whatever gains they could have made by depositing their YFI in a vault or some pool.

[amphiboly]

Only YFI staked in governance should get rewards. Staking in governance is like hodling, it gives strength to the store of value property of the token.

Great point.