MIP.C2-0024: Update Contract Parameters on Tally

Submitting Author

Abstract

I would like to propose an update to the contract parameters on tally, with the aim of improving overall consensus and security. At current, the parameters are set to the following;

image

Proposal threshold” - The minimum amount of MahaX required to submit a proposal on tally.
Quorum needed” - The minimum amount of Total MahaX required to pass a proposal.
Proposal Delay” - Execution delay of pass proposal.
Voting period” - The time opportunity for governors to vote.

In addition, there is an execution delay if a proposal is passed.

The proposed changes are;

  1. Increase Proposal Threshold to 2500 MAHAX (currently 250)
    This is essentially reverting to a previous criteria, however the cost is much lower now. With voting rewards/incentives, increasing this will help prevent spam proposals and encourage delegation groups. I would like more feedback on this, perhaps we could also use a distribution mean.

  2. Increase Qurum Needed to 100,000 MAHAX (currently 50,000)
    Currently with almost 500k MahaX, raising this to 100k would mean approximately 20% minimum. The last proposal hit just short of 200k (40%).

  3. Increase Proposal Delay to 14 days (currently 1 day)
    This gives more time to veto any potential malicious proposal that may pass.

  4. Increase Voting Period to 7 Days (currently 4 days)
    This just allows bit more opportunity for people to review and vote. .

  • Approve
  • Reject

0 voters

Agreed with points 1 and 2 but don’t understand why 7 days?

It is so each proposal will at least cross over a weekend, to better accommodate any that may be too busy during the week to review, comment and vote.

I agree on points 1 and 3.

To point 3: I think one week time for voting is good. Everyone finds a few minutes to deal with a proposal and vote. With the time extension, of course, the whole period becomes very long. Apart from the planning and discussion of a proposal, we then have additional 1 day delay + 7 days voting + X days execution delay (with the first proposal the execution delay alone was already 12-14 days). So it takes a long time until anything is implemented.

To point 2: I would set it lower for now (maybe 100k) and then increase it later. The MahaX holders must first familiarize themselves with votings. We have also to keep in mind that we vote on ETH chain and that gas costs can quickly be much higher for a while. The more proposals there are then, the more the gas costs add up (With 7 days voting time, however, you can again better wait for favorable fees. But more votes = more gas costs). This will discourage many from voting. Especially people who have only little voting power. When it comes to proposals that do not seem very important, such as new gauges, many will probably abstain from voting.

Do we have the possibility to define two different quorum minimums?

E.g. maybe 150-200k for core votes (if it is e.g. about the system, Arth, changes of tally parameters or other important votes).

and e.g. only 100k for less important, but more frequent votes like e.g. for new gauges.

As for gas costs, voting rewards can offset this and also there is option to delegate and receive rewards without needing to sign each vote.

I would anticipate >150k Mahax participation going forward, more so with what is coming this quarter. Stepping it to 100k just means we would be clogging up another 21 days with a small 50k adjustment in a few months time later. Better to set this now at an achievable level so the proposal queue is available for gauges and other things.

Thanks mike for this.

I appreciate these changes because it’s also come to our notice that there are a few whales accumulating MAHA at these prices; not this it’s a bad thing, (it’s definitely great that we still have buyers in the market) but this brings up a big concern of centralization because at the current threshold of just 50k MAHAX to pass a vote, this one wallet can easily twist the outcomes and defeat the whole purpose of having a governance to secure the ecosystem in the first place.

I’d further recommend extending the timelock to 14 days? so that we give the community enough time to think about veto’ing a proposal if found malicious.

Regrading this yes. It’d make sense to have another governor/timelock set up for the core votes however we would need to put in some effort to understand what permissions/votes should be set up to which governor.

I don’t think this is a problem because in the end the executed code becomes law. And if that new law is not scrutinized well enough then things can get ugly.

Yes, it’s known that ETH usually is a whale’s playground however overtime we have a budget of MAHA that can be used to subsidize gas costs, which means voters will be able to make decisions for free.

Also to note that gas costs and voting incentives should encourage people to delegate their votes to more active DAO politicians.

1 Like

Only yours and Steven’s wallet are publicly known, so we shouldn’t weight delegating votes so highly yet, as long as there is no greater diversity.

Don’t misunderstand, I know that you both stand 100% behind the interests of MahaDAO.

True. Delegating votes is still (in my opinion) heavily under-utilized within the crypto space. In our roadmap for governance we have new plans to make delegation even simpler and easier however we need to focus on some core metrics such as number of holders and participation rate.

With regards to if we should make it 150k or 100k for a vote to pass, I guess having more proposals will allow us to gauge as to which is better.

So I’d suggest that we keep it to 100k for now and if we pass a few more proposals with a higher voter turnout, then we can raise it up to 150k

2 Likes

Ahh, makes sense – I misunderstood it to be a submission delay. I’ve edited the proposal to;

  • Proposal threshold: 2500
  • Qurum: 100k
  • Proposal Delay: 14 days
  • Voting Period: 7 days

If we’re all good with this, I think can submit to tally soon. :pray:

2 Likes