The current parameters are not productive due to the low circulating supply of IPT. By my tally, there is approximately 18 million IPT in the wild, and the more realistic voting supply is likely closer to 9 million. However, with the GFX Labs Delegation Program coming into effect in the coming weeks, we can likely expect the voting supply to increase between 2-5m.
At this time, I believe the key parameters to update are the following:
Standard Proposal Parameters
proposal threshold: 200,000
quorum threshold: 2,000,000
Optimistic Proposal Parameters
optimistic negative quorum threshold: 500,000
By decreasing the proposal threshold, approximately 25 addresses would have proposal power, and that number will likely increase to 35 after the Delegation Program takes effect. Decreasing the quorum from one million to five hundred thousand should be a sufficient improvement.
If we find that too many proposals are being made, we can increase the proposal threshold, or if we find the quorum threshold is too easily achieved, we can increase it.
Big fan of this conceptually, but I think it would be more effective to make the quorum thresholds percentages of the IPT float at the time the proposal is created. Otherwise, as more IPT enters the market these thresholds will constantly have to be voted on.
While I agree with the concept, the execution is complex because we’d need to develop an onchain oracle. As a part of that oracle, we’d need to check the balance or several addresses that could change at any time. To effectively manage the oracle would require an onchain proposal. At that point, we might as well update the parameters manually.
I don’t want to rule it out if someone has a good idea, but my current thought is that the risk/reward wouldn’t be worth it.
Unfortunately came too late to this discussion. Wondering why this wasn’t brought up during the meeting so we could discuss. Maybe it was in the second meeting.
It is not clear to me why one would use a different ratio. proposal threshold goes from 1M to 200K (1/5) yet the rejection is 2M to 500K (1/4).
I would have preferred to see a more moderate change here to like 500K proposal threshold and 1M rejection, but don’t think this includes as many people as you want.
I think my problem here is that I don’t see a decent analysis that indicates the additional 10 wallet addresses are going to be significantly active (and if so) why they could not get additional IPT delegated so they can be more active.
Right now completely undecided on this proposal and I have 2 days to figure out which way to vote, even then my own total voting power can’t block this.
I also really want to see more discussion on these kinds of changes and a little bit more lead time to a RFC, to proposal discussion loop. In generally I really want to see a more formal governance timeline process so I can know when I should expect to see proposals in RFC (like the above) be turned into a formal IPIP so I can make sure to comment on these while in RFC before they turn int IPIPs that I then have to decide how to vote on.
Again apologies I have been significantly busy with year end/start issues at work and family so I only have been looking in at best weekly and these proposal RFCs don’t really stick out at me, NOR is there a post showing they are formally going to governance for vote.
I am still digesting the implications of these changes within the scope of how optimistic proposals work.
I also would like to see a list of wallets that can propose, and block since I think there are only perhaps what 4 wallets that can block a proposal themselves where as maybe 30-40 can propose. I think this puts a lot of weight on the 4 wallets that can block vs. the 30-40 who could just do multiple proposals.
One other point, can we put up a deposit to submit a proposal (that can be slashed if the proposer is deemed malicious) and a bounty if the proposal succeeds?
Hi @IPTMan, the proposal came after the first meeting and was discussed in the second meeting. I agree we can have a social structure around how proposals go from idea to implementation. As for proposal 17, the forum post was up for 18 days and discussed on the most recent call.
When it comes to reducing the proposal threshold, the only concern is spam. Some DAOs like to have a very high proposal threshold (Uniswap @ 2.5m UNI or ~$16m), and others have a very low threshold (Curve @ 2.5k CRV or ~$2700). Since Interest Protocol is relatively new and small, we’re still figuring out what reasonable governance parameters should be. What ultimately matters the most is the quorum threshold. For now, we should error on the side of being more accessible to delegates, and if we do run into spam issues, we can always amend the system.
As for the quorum threshold, 10m to 2m might seem like a big change, but once you take into account the circulating supply, I think it will still be non-trivial to hit. In the event the protocol feels as though it’s too easy to pass a proposal the parameters can always be changed.
If the proposal passes, approximately 20 addresses will be able to make a standard proposal. To defeat a proposal, any voter may vote against the proposal, and if the against votes outnumber the for votes (or if the quorum is unmet), the proposal will fail.
Yeah I got busy in life. Probably looked in once but missed it.
I agree with you the quorum threshold is an important quantity, thank you for pointing that out. Since we were only doing the optimistic proposals I don’t think i had a good handle on the other proposal parameters.
And like you said if we get too many proposals and have to turn them down then we can rethink this.
Thank you for the discussion. At this point I see no huge reason to stop this and as an experiment in governance change to observe a response probably useful and valid.