x/gov min proposer deposit

[robert-zaremba]

Summary

Add x/gov min-proposer-deposit param to require a deposit from proposer when adding proposal.

Ref: #11130 (reply in thread) by @anilcse

Problem Definition

Today anyone can create proposals for free (only tx cost) and spam the the gov view. These proposals won't advance to voting phase, unless they will got enough deposit, but will spam the views.

Proposal

Require additional, small deposit from the proposer when submitting a gov proposal.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[Kwaskoff]

Yep! Right now we can see this situation
And we really need special fee for publication message in proposal zone

[alexanderbez]

@p0mvn already did this phenomenal work for Osmosis' fork of the SDK here: osmosis-labs#296 -- we should just simply upstream this to the core SDK repo.

[robert-zaremba]

If we implement it in a non API breaking way then we can backport that feature to 0.46.

[alexanderbez]

If we implement it in a non API breaking way then we can backport that feature to 0.46.

I don't think that's really possible. I think we should just upstream the Osmosis feature.

[p0mvn]

I have already started moving the change here. The change breaks the gov proto and requires parameter migrations. However, I don't think there are any other API breaks.

One other caveat with the work in osmosis-labs#296 is that it does not burn the deposit unless it is vetoed or does not move to the voting period. This is contrary to the conclusion in #11130 (reply in thread)

In Osmosis, we estimated that it would be too costly to spam a lot of proposals and then fully fulfill the deposit. However, I can extend osmosis-labs#296 to fulfill the conclusions from #11130 (reply in thread) if that is still desired?

[alexanderbez]

I have already started moving the change here. The change breaks the gov proto and requires parameter migrations. However, I don't think there are any other API breaks.

Yes, this is fine and expected :)

One other caveat with the work in osmosis-labs#296 is that it does not burn the deposit unless it is vetoed or does not move to the voting period. This is contrary to the conclusion in #11130 (reply in thread)

In Osmosis, we estimated that it would be too costly to spam a lot of proposals and then fully fulfill the deposit. However, I can extend osmosis-labs#296 to fulfill the conclusions from #11130 (reply in thread) if that is still desired?

This is a great question. I would lean towards the solution/approach Osmosis took, but I'd like to hear input from others. @hxrts @marbar3778 @AmauryM

[robert-zaremba]

x/gov min proposer deposit and #11130 are two different features.

In #11130 we still need to get into conclusion if we want to apply a margin (allowing proposal withdraw until voting end or voting_end - 10%voting_period - so applying a negative margin).

[p0mvn]

x/gov min proposer deposit and #11130 are two different features.

In #11130 we still need to get into conclusion if we want to apply a margin (allowing proposal withdraw until voting end or voting_end - 10%voting_period - so applying a negative margin).

I see - the discussion and the decision about burning the deposit are related to the proposal withdrawal, not min proposer deposit.

Then, #12771 should match the requirements. Thanks @robert-zaremba

[robert-zaremba]

Yes, thanks @p0mvn