Sikka is planning on proposing the following governance proposal soon (preferably after the transfer enablement hard fork). Until then, we would like to solicit some feedback and comments before we officially propose the proposal on chain.
Make governance proposals only burn the deposit upon being vetoed.
The Cosmos Hub’s state machine handles spam prevention of governance proposals by means of a deposit system. A governance proposal is only considered eligible for voting by the whole validator set if a certain amount of staking token is deposited on the proposal. The intention is that the deposit will be burned if a proposal is spam and caused a negative externality to the Cosmos community by wasting stakeholders’ time having to review the proposal.
In the current implementation of the governance module used in the Cosmos Hub, the deposit is burned if a proposal does not pass, regardless of how close the final tally result may have been. For example, if 49% of stake votes in favor of a proposal while 51% votes against it, the deposit will still be burned. This seems to be an undesirable behavior as it disincentivizes anyone from creating or depositing on a proposal that might be slightly contentious but not spam, due to fear of losing the deposit minimum (currently 512 atoms). This will especially be the case as TextProposals will be used for signaling purposes, to gauge the sentiment of staked Atom Holders, and disincentivizing proposals for which the outcome is uncertain would undermine that effort.
We instead propose that the deposit be returned on failed votes, and that the deposit only be burned on vetoed votes. If a proposal seems to be spam, voters should vote NoWithVeto on the proposal. If >33% of the stake chooses to Veto a proposal, the deposits will then be burned. However, if a proposal gets rejected without being vetoed, the deposits should be returned to the depositors.
I think this is an excellent idea (not necessarily an official opinion yet, just my thoughts), for a few reasons:
Proposals which are voted down but not vetoed often may have sparked productive discussion and followup proposals addressing issues raised by stakeholders. We should encourage such proposals.
The option to veto will retain the threat of burning the deposit and thus prevent spam as at present. Removing burning from rejected but not vetoed proposals does not meaningfully decrease this threat and seems unlikely to lead to an increase in spam.
Furthermore, I think we should refund deposits from failed-but-not-vetoed proposals so far retroactively.
Another interesting option for “signaling votes” is to allow proposal creators to specify a list of (presumably mutually exclusive) options when creating a “signaling proposal”. Open-ended proposals such as this one seem like they might benefit from increased customizability.
Should such a proposal go through - what is the upgrade path for validators? I’d hope that it is not another network full-stop-and-start but rather a phased rollout where we can deploy an appropriate version to support the feature ahead of time?
I think we can probably do it in the same proposal; we’ll need to identify the accounts to refund and the amounts to add to their balances (just from proposal 4, I think, since proposal 2 was vetoed).
It’s not critical given the relatively small amounts involved so far, but it’s nice.
I’m in support of making a second proposal for refunding the No’d proposals thus far, perhaps from the community pool, if and only if this proposal passes. (I don’t mind pipelining this, so that acceptance of the second is conditional on acceptance of the former)
In general, I’m not a fan of omnibus proposals, and the decision criteria for these two things are fairly distinct.
My only concern is that using no-with-veto as a spam filter could dilute it’s utility as a signaling mechanism for “no, I would rather leave the chain, than see this upgrade happen”.
I think my concern can be assuaged by proper discussion on the forum, and people should have ample time to make the distinction between “no this is spam” and “no, I’d rather fork than upgrade”.
It’s also worth noting on the continuum of no, to hell no, there could be other categories that are useful to parse for the community to grow in governance capacity. Maybe worth considering some pre-vote polling and decision making upgrade to the forum that allow these distinctions to be made visible easily. Loomio is an excellent tool and is open source, so might be a good option to integrate into the forum.
I will vote yes on this because I think reducing the risk around losing deposits for valid but perhaps contentions attempt to upgrade the network is worthwhile. I do hope we can address some of the parsing and signaling concerns I raise.