Who should be able to make a proposal?

What restrictions (if any) should be put in place for those who can make onchain proposals?

Potential options:

  • Must hold X amount of YFI (similar to COMP with 0.1% of the supply)
  • Can only be posted by a select few whitelisted addresses (like @andre.cronje)
  • Other…

My worry is that in its current iteration people will rush to post onchain votes without any inclination of what it entails and no context around what the vote is for.

Anyone down to help buff up the UI on this front to make https://ygov.finance/vote more informative?

7 Likes

One option I thought of is proposals can only be pushed by people who have held YFI for a certain amount of time, irrespective of how much they hold, or at least some kind of dynamically calculated amount that signals interest that also isn’t a hefty price.

2 Likes

I’m all for people being able to make proposals regardless of capital holdings.

The tricky metric is preventing spam/sybil attacks which is the biggest argument for having high capital requirements. (although time-weighted factors def help with this a lot)

To start, I’m all for @andre.cronje being the ONLY whitelisted address able to list new proposals for voting until a more sufficient framework has been established.

3 Likes

Agreeing with @andre.cronje being the only person who can whitelist. For now that is.

Time metric is probably the best you’ll get in the short term to prevent spam. For the long term, well YFI just sitting in wallets for sometime (even like .000001) will ruin this.

I have to agree with your idea that @andre.cronje should be the only whitelisted address for now until things are figured out.

What about some sort of KYC-oriented proposal system? Combine it with time-weighted parameters or relatively high capital requirements and it could be something that works. I’m just throwing ideas around!

1 Like

Whitelisting only Andre is a very short term move, and deeply against what seems to be the ethos of the protocol.

Enforcing X YFI minimum to propose is a step in a more distributed direction. Make users stake the tokens for the duration of the proposal.

Creating a ‘proposal weight’ which is accrued over time by staking YFI and expended in order to submit a proposal may be the most solid, short term.

Please, no KYC.

6 Likes

Very valid comment.

Maybe stated another way - Do we need to limit the number of proposals or simply just increase the difficulty for proposals to actually pass?

2 Likes

This makes a ton of sense. By “proposal weight” that is “expended” over time, do you mean something other than YFI directly that is accrued in order to be spent on submitting proposals?

2 Likes

Increase the difficulty to make a proposal for now IMO. Can move to a weighted or delegate system next.

1 Like

Would that be any different from burning YFI itself on proposals? Also, would there be a way perhaps to provide a certain staking mechanism for people who are specifically interested in submitting proposals in the future? Higher-yield but longer-term lock up or something like that.

1 Like

Yes it’s different than burning to propose because it demonstrates commitment to the protocol without sacrificing the ability to earn fees. It wouldn’t make as much sense to give up your share of the protocol you’re trying to improve through governance.

Rewarding those who submit successful proposals may be a decent incentive to take the process more seriously.

2 Likes

I’m guessing the ‘voting points’ token would be tradable itself?

Also, I was thinking that you give up your current share in the protocol through burning YFI in order to commit to what you believe will improve the protocol in the long run. If you risk having to burn your YFI for no good reason then you would spend more time on the proposal’s quality and relevance. If it does go through, then you get some sort of extra yield over some period of time.

Again, I’m throwing ideas around as much as I can…

It’s an interesting idea, just a very high stakes way to show commitment. What if the proposal doesn’t pass?

Ideally the ‘voting points’ would not be transferable / trade-able and simply be displayed in the ygov dashboard. Can be an ERC20 for on chain presence. Forces people to earn the ability to propose, showing commitment by holding or staking the token over time.

1 Like

Forgive me, but I don’t see where the disincentive to waste ‘voting points’ could possibly come from if the underlying YFI remains necessarily untouched! I thought perhaps ‘voting points’ could be speculated upon like in the way GAS (NEO transaction fuel) is. Then there is a continuously priced asset that one could lose instead of market-selling for guaranteed profits, which maintains the incentive for accumulating ‘voting points’.

To answer your question, if the proposal doesn’t pass, then there could be a mechanism to erase the value you could have gained if you staked in order to receive the potential excess yield designated to those who submit a passing proposal, but at the same time not lose all the yield you could have secured by simply staking YFI as a regular staking participant. So there would be four potential yields: one for simply staking (call it A), one for risking and creating a successful proposal (call it B), one for risking and not creating a successful proposal (call it C), and one for risking and creating a successful and passing proposal (call it D).

This way, D > B > A > C in terms of payout. Maybe all of them should receive some payout?

I would say that a “successful” proposal shouldn’t rely on whether or not it’s passed, but rather should rely on whether or not it was relevant/widely discussed. I guess this begs the question of how to account for potential spamming of fake discussion in governance forums to give off the illusion of “widely discussed”.

Hopefully I wrote this clearly enough to be critiqued, I am not so technically-trained as probably the most of you…

even small holders can have good ideas, if proposals were in draft status until “liked” by enough token holders to move it to a vote, that would bring the best ideas to the top

4 Likes

I agree with @michaeljohn. There should be another layer before the proposals make it to voting rounds.

Drafts should be voted to be accepted by the governance members. Highly unpopular drafts should be either purged or archived such that spamming doesn’t affect the UI/UX.

Once a draft is accepted, then it should proceed to actual voting rounds to decide on the execution of it.

However one downside is that the process is going to be a lot slower since it needs to pass 2 periods of voting. A way to mitigate this is to set a threshold of min voters on drafts and also a end block number. If there are sufficient number of “YES” on a draft, anyone should be able to call a function to move that draft to a proposal stage.

4 Likes

I also support a petition-like process as a filter.

For critical, quick decisions maybe an additional whitelist can be maintained. That would be a hybrid system similar to the state where the voted executive (whitelist) can act short-term, while parliament (YFI hodlers) set the larger framework through legislattion.

In any case I would suggest we look into the governance of decred. That seems to work well.

The idea of having draft proposals is good.
While drafting one, I read the following related threads on the users’ account of staked YFI of Pool #4

On a side note to deter voters apathy

The UI can remind voters that voting will require a timelock when they last voted for a proposal.

Also displaying voter’s current choice on the current proposals is nice too

How can I tell if I have already voted?

Absolutely love the draft idea before a proposal can be voted on officially. This petition style I think is a great idea, and should be easy to implement without costing gas right? You would just have to sign a message if you want the proposal to make it to the voting floor. Maybe set a min number of votes, or percentage of YFI holders / LPs that it takes to become an official proposal?

2 Likes

Looking at what’s going on right now, quorum may actually serve as a great blocker to what does and doesn’t pass. My immediate next question would be how we can clean up the UI to prevent proposals from being spammed

1 Like