[PROPOSAL #][LAST CALL] raise the Governance `MinDeposit` to 500 ATOMs

[Govmos]

Change log

• 2024-02-01 Created initial post
• 2024-02-16 Moved to “Last Call”. As the poll is currently hesitant between 500 and 1000, we’ll give it another week and move on-chain with the lowest barrier (500) unless the poll shifts significantly enough towards the higher value.

Summary

This proposal aims to raise the min_deposit parameter of the Governance Module from the existing 250 to 500 ATOMs, effectively doubling it.

Details

Looking through the recent history of on-chain proposal for the Cosmos Hub chain, we can see that a significant share of the votes are reaching a NO WITH VETO consensus (shown as a light red color in the chart below):

Source: Mintscan

Among the latest 50 proposals, we have encountered this situation 16 times (32,00% overall). All these related to spam proposals containing harmful links. Despite the fact that most of the block explorers and wallets have built solutions to filter those risks to the end user, it is legitimate to ask if we shouldn’t take action against this anyway.

The aforementioned numbers show that almost a third of recent proposal represent unnecessary pollution (be it harmless spam or malicious links). This is evidence to the fact that the current minimum deposit might not be restrictive enough.

---

For context, under the current running SDK version (v0.45.16) the governance module deposit functions like this:

Deposit:
To prevent spam, proposals must be submitted with a deposit in the coins defined in the MinDeposit param. The voting period will not start until the proposal’s deposit equals MinDeposit.
When a proposal is submitted, it has to be accompanied by a deposit that must be strictly positive, but can be inferior to MinDeposit. The submitter doesn’t need to pay for the entire deposit on their own. If a proposal’s deposit is inferior to MinDeposit, other token holders can increase the proposal’s deposit by sending a Deposit transaction. The deposit is kept in an escrow in the governance ModuleAccount until the proposal is finalized (passed or rejected).
Once the proposal’s deposit reaches MinDeposit, it enters voting period. If proposal’s deposit does not reach MinDeposit before MaxDepositPeriod, proposal closes and nobody can deposit on it anymore.

Source: Concepts | Cosmos SDK

---

One would easily argue that raising the MinDeposit can also deter legitimate proposers to reach on-chain votes. To answer this we remind readers that we have a collective bid mechanism (as mentioned in the above quote) to alleviate this concern. It is also worth mentioning future SDK updates:

• In the forthcoming SDK v0.47, the module will be updated to introduce a BurnProposalDepositPrevote parameter which can toggle on/off the burn of the deposit if it doesn’t match the MinDeposit by then end of MaxDepositPeriod.

• In the future, SDK v0.50 will add another one called MinInitialDepositRatio initially set at “0.1”. This guaranties a minimum initial deposit of 10% of the MinDeposit value. If we raise this to “1000-2000” as this proposal suggests, this would mean a minimum 100-200 ATOMs required for the proposer, the remainder being possibly deposited by the community in general during the following 14 days.

According to these current and future conditions, we think the proposal offers a reasonable opportunity to reduce the number of spam proposal to reach on-chain without compromising legitimate participation and overall community inclusion.

Parameter and new value

Subspace	Key	Type	Value
gov	MinDeposit	array (coins)	[{“denom”:“uatom”,“amount”:“500000000”}]

[
  {
    "subspace": "gov",
    "key": "MinDeposit",
    "value": [{"denom":"uatom","amount":"500000000"}]
  }
]

We invite participants to vote for the amount that seems to be the most appropriate to them:

• 500 Atoms
• 1000 Atoms
• 1500 Atoms
• 2000 Atoms
• 2500 Atoms
• Stay at 250 Atoms

Timeline

We hope to bring this proposal to vote after a minimum 14 days consulting period in this forum (leading to the 14th of februry). In the meantime we invite the community to participate in the debate and eventually propose readjustments with their reasoning as a reply post below.

---

Thank you for your attention,
Govmos

[jtremback]

I’m strongly opposed to this personally. 2000 ATOM is like $20k. That puts governance proposals firmly out of the reach of most people

[Govmos]

We are also opened to lower the barrier if participants think this is too high. We seek a global consensus and will listen to everyone’s feedback to adjust if necessary. 2000 is only our base suggestion, not an imposed decision.

[freak12techno]

I don’t think it’s a bad idea to increase the min deposit, but 2000 ATOM is waaay too much.

From my personal experience as a validator on the bottom of the active set, when I tried to submit a proposal on chain even with 250 ATOMs, it was a big struggle, and even depositing all of my ATOMs wasn’t enough so I had to ask my friends to help me getting the proposal into the voting period (which eventually happened thanks to them), and increasing it by 8 times would eliminate the possibility for the smaller validators to propose changes to the network completely.

[CML]

@Govmos

We are also opened to lower the barrier

When you say “We”, just who exactly are you speaking for? Who are you representing?

Also, there are other ways to improve the Proposal process. That can reduce spam proposals without increasing the cost of entry.

For Example:

A Section for “Arguments Against this Governance Proposal”

In the spirit of fostering transparent, informed, and balanced decision-making within our community, I propose that all governance proposals must include a dedicated section titled “Arguments Against this Proposal.”

This requirement aims to ensure that every proposal presented for community consideration comprehensively addresses not only the benefits and positive aspects but also the potential drawbacks and opposition viewpoints.

The “Arguments Against Proposal” section should be authored by community members who express opposing viewpoints in the hub proposal forum. This group should form a small coalition working collaboratively to draft the “Against” section.

This inclusive approach allows for a diverse range of perspectives to be integrated into the proposal-making process. It is a more effective strategy than increasing the cost of entry for proposals, which could inadvertently become counterproductive. Raising entry costs will create barriers that may fuel negative sentiment towards controversial proposals.

By actively involving members who disagree with a proposal in its formulation to present their viewpoints, we ensure that the process remains accessible and open to all, fostering a healthier and more balanced community dialogue. This method not only democratizes the proposal process but also mitigates the potential for spam votes, ensuring that every proposal reflects a comprehensive understanding of the community’s diverse opinions.

Below are the arguments supporting the inclusion of this section:

1. Enhances Transparency: Including arguments against a proposal directly within the document ensures that all community members have access to a full spectrum of viewpoints. This transparency is crucial for trust-building and for preventing the oversight of critical issues that might not be immediately apparent.

2. Encourages Critical Thinking: By systematically presenting counterarguments, proposal authors and community members are encouraged to engage in critical thinking. This process helps in identifying and addressing potential flaws or weaknesses in the proposal, leading to more robust and resilient solutions.

3. Promotes Informed Decision-Making: Voters are better equipped to make informed decisions when they have access to both pros and cons. Understanding the potential risks or downsides of a proposal is just as important as understanding its benefits. This balanced perspective is essential for the long-term health and success of the ecosystem.

4. Fosters Constructive Debate: A mandatory “Arguments Against” section invites open and constructive debate within the community. It acknowledges that dissenting opinions are not only valid but also valuable for achieving comprehensive community governance. This open dialogue can lead to more nuanced and widely accepted proposals.

5. Demonstrates Maturity and Confidence: Willingly presenting counterarguments demonstrates the proposal authors’ confidence in their proposal and their commitment to the community’s best interests. It shows maturity in acknowledging that no proposal is perfect and that every idea can be improved through community input.

6. Reduces Polarization: By presenting a balanced view, we can reduce polarization within the community. When members see that their concerns and objections are recognized and considered, they are more likely to engage in constructive discussion rather than adversarial opposition.

7. Prepares for Implementation Challenges: Understanding the arguments against a proposal can help in preemptively addressing the challenges that may arise during implementation. This preparation can lead to smoother execution and higher chances of success.

Mandating an “Arguments Against this Proposal” section is a step towards more democratic, informed, and effective governance. It respects the diversity of opinions within our community, strengthens the decision-making process, and upholds the principles of transparency and accountability that are foundational to our ecosystem. By adopting this requirement, we can foster a more inclusive and thoughtful governance culture that is capable of navigating the complexities of our growing and evolving community.

[Tagu]

This kind of changes should be done gradually so I think 500 Atom as a first step is enough. Then, let’s look again at the data after a few months.

[Govmos]

@CML

Also, there are other ways to improve the Proposal process. That can reduce spam proposals without increasing the cost of entry.

For Example:

A Section for “Arguments Against this Governance Proposal”

You have raised a very interesting point with the proposition to include “Arguments Against this Governance Proposal” which we should consider to enhance our current proposal framework. We suggest you to submit a separate post in the Governance Meta section of this forum.

[Regarding the "we", I speak in the name of the entire PRO delegators' team.]

Back to the topic, despite the good idea you proposed, this is not going to offer any solution to the current spam problem. None of these people will use your formatting suggestions, they are just using the current low deposit amount to abuse the governance system. The only way to remove that behavior is to increase the pain level we inflict when the rules are broken. They are playing the basic “game theory” strategy here. Shall we note that the last 5 proposals in the Hub are spams. Something needs to be done. Raising the minimum deposit is the logical response to this problem, early feedback has suggested to opt for a gradual increase, and we will listen to this feedback, as well as the future posts during the 14days consultation period.

[Govmos]

You seem to question the legitimacy of our data and claim this is evidence of our harmful motivation. This is concerning to say the least and we hope that you’ll stop that damaging behavior inside the forum. Moreover, opposing claims that our data is flawed can’t be left unchecked.

@CML

The actual data is, out of 138 proposals, only 1 proposal (Prop 73) was outright rejected as spam based on “No with Veto”. That amounts to a small amount of only 0.007% (Less than 1%)

This quote is indisputably wrong. We provided an historical chart, showing the last 50 proposals broken down by their end voting results. On this sample, everyone can verify the 16 vetoed votes which are all spam proposals. Everyone can dig into the data by looking at the source we provided.

@CML

Red bars on a bar chart do not automatically signal spam nor does it represent NWV. Most of the red were a majority of “No” votes.

This is purely wrong as well… Anyone can verify that by looking at the source provided earlier. The light red color represents the amounts of NWV, as evidence to this screenshot displaying the voting detail:

Moreover everyone can follow the link provided and verify that every single one of those 80%+ vetoed proposal where spam related proposing fake “airdrops” for most of them. This is the reason why validators veto them according to the hub voting policy. The fact that the proposers keep posting new proposals despite the loss of their deposits is clear evidence that the minDeposit should be raised. How much that raise should be is the purpose of that discussion.

To conclude, your constant questioning of our motivation to distract people from the actual proposal debate is counter-productive. The worst part of this comes from your claims that our data is inconsistent when the one you provide as counter argument is blatantly false.

[Tagu]

What do you mean? Just went on Keplr and among the last 10 proposals, 6 are obvious spams rejected with VETO.

I’m not sure over exaggerating and being dramatic with long posts that don’t say much is useful.

[CML]

It appears that I was mistaken. My view of the votes were being filtered, preventing me from seeing the vetoed proposals. Therefore, I will issue a public apology for questioning the accuracy of your data when it was my post that was inaccurate. This situation underscores the value of our public forums for discussion. I will remove the incorrect data. But I will still continue to comment on proposals.

Let’s be clear, I was questing your data and presentation as it did not align with what I was viewing. I don’t see the details when I click on your chart. All, I see is just a bar chart.

Now that I see the actual data, I can understand the reasoning for this proposal.

I have deleted the post since the post was mostly a flawed interpretation on my part. I will accept the public shame for my mistake.

[waqarmmirza]

If only we need to increase the deposit fee. We shouldn’t increase more than 500 Atom.

[CML]

Upon analyzing the data, I can now advocate for raising the minimum deposit requirement. The data compellingly shows a need to increase the minimum deposit to mitigate spam proposals.

Introducing tougher penalties for spam proposals can be an effective strategy to combat this issue. Perhaps implementing the increases incrementally over time might be a good approach. For example raising deposit fees, maybe starting with a 100 to 150 Atom increase. Then wait and evaluate the data to see if there is a decrease in spam. This incremental approach allows for subsequent data reviews to assess the effectiveness of each increase, aiming to find a balance that discourages spam without hindering genuine participation.

If a proposal is marked as spam by receiving a “No with Veto” (NWV) vote, then the deposit should be forfeited entirely to the Community Pool (which I believe is already the case).

I agree that the approach can serve both as a deterrent and as a means to improve the quality of proposals. Although this may challenge smaller entities in submitting proposals, it does not exclude them. They can gather support and funding from the community, fostering a cooperative approach to governance and enhancing the community’s collective decision-making.

[JulienViolet]

I respectfully disagree with this strategy.

@CML

Introducing tougher penalties for spam proposals can be an effective strategy to combat this issue. Perhaps implementing the increases incrementally over time might be a good approach. For example raising deposit fees, maybe starting with a 100 to 150 Atom increase. Then wait and evaluate the data to see if there is a decrease in spam. This incremental approach allows for subsequent data reviews to assess the effectiveness of each increase, aiming to find a balance that discourages spam without hindering genuine participation.

Given Cosmos’s significant market cap of $3.50B USD, the extent of scam proposals is not just alarming, but also unacceptable. @Govmos data has clearly demonstrated the severity of this issue. I prefere a more assertive response: a substantial increase in deposit fees from 250 to 1000 Atoms.

Such a decisive action would serve as a strong deterrent against malicious activities and prepare us for a more secure future. It’s time for a robust cleanup to welcome progress.

[tknox35]

Do the votes to veto these scam props usually reach quorum? A quick look says yes. If so, I think raising the minimum is acceptable to raise the stakes for the scammers.

It shouldn’t be an outrageous amount, but I think doubling it makes sense.

Surely there are even more things that can be done to prevent this gross behavior, though.

[Govmos]

Early community feedback seems to confirm that as well. We will wait the minimum 14 days and the closure of this vote before proceeding on-chain with the amount gathering the more votes. At the present time is appears to be 1000 Atoms. We will align with the community’s choice.

[jtremback]

Let’s be clear: Spam is a front end issue. Simply getting spam onto a blockchain has no benefit to the spammer. Today, anyone can put spam and malicious links into the memo field of any transaction.

What’s the difference with governance proposals? Mintscan and Keplr show them prominently on their sites. This gets the spammer in front of eyeballs.

The solution to spam is thus for the frontends to be more selective about what they show. They already took some great steps last year by hiding proposals with a high NWV percentage, but I believe these proposals are still visible briefly before enough NWVs are kicked in.

Some of you in this thread seem pretty eager to do data analysis, which is great, so maybe you could study the circumstances under which spam proposals are still visible on popular block explorers and wallets. This will allow us to formulate a strategy for dealing with them.

One idea would be to have them hide proposals that have not yet received at least one YES vote from a validator. This might hide spam proposals before they have enough NWV to hide, without impacting legitimate proposals too much.

Increasing the deposit is not only undemocratic, it is likely to be ineffective. Clearly there is enough money to be made off of spam that they can afford a burned deposit. What if raising the deposit still does not make it unprofitable?

[Guinch_Roze]

we can do a reversal governance proposal if it did not hit the goal

[Guinch_Roze]

one must be careful with such an increase in mindeposit. this should not slow down the posting of the proposal online because of this barrier to entry to collect funds

[freak12techno]

I’d suggest doing it gradually. Like, increasing it by 50 ATOM making it 300, then 350 etc. with multiple proposals, having some time between them to evaluate if it actually helps fighting scam proposals and increasing it even more. Because it’s effectively making it difficult for some reasonable parties to submit their proposals.
If you’re a top-ranked validator, it’s not a problem to get that amount of tokens, but if you are somewhere at the bottom of the active set, or if you are not a validator but just a community member that wants to voice their opinion and propose changes or whatever but doesn’t have enough tokens, it’ll become way more difficult with the increase of the deposit. So I suggest being extra careful here instead of going all in, what do you all think?

[Govmos]

@jtremback

The solution to spam is thus for the frontends to be more selective about what they show. They already took some great steps last year by hiding proposals with a high NWV percentage, but I believe these proposals are still visible briefly before enough NWVs are kicked in.

We really like that idea, along with your proposal to suggest hiding proposals until they receive at least one YES vote from any validator. This would shift the visibility problem to a reputation front, as any validator voting in favor of a spam proposal would clearly discredit its governance capability.

Despite finding your solution very elegant, there is one caveat—it relies on private parties (explorers) to use the proposed filtering process. We still believe this problem should be addressed on both fronts, by raising the minDeposit and improving explorer filtering.

Moreover, we also tend to think that raising the capital requirement to access on-chain should be sufficiently restrictive to compel proposers to come here and debate first. We could easily imagine that a minimal consensus should be reached here, with participants collectively depositing to reach the minimum threshold. After all, the argument that “the submitter doesn’t need to pay for the entire deposit on their own” is a solid response to oppose the antidemocratic criticism. Most of our democracies actually function this way, with collective debate and amendments before proceeding to the actual vote. From that point of view, raising the deposit could turn out to be a net improvement to the quality of preliminary debates.