Implement proposals dropping/overriding

[RiccardoM]

Summary

Allow the discarding and/or overriding of a currently open proposal in favor of a new one.

Problem Definition

Since the launch of the main net we've seen some proposals being created and later being overridden from other proposals. The last example of this happening is the proposal 15 overriding proposal 14 due to a small error inside the calculation of the launch time of the new chain version.

I think this approach of having a new proposal being drafted very quickly after a new one can lead to the following problems:

1. Simple delegators who do not follow the discussion behind those proposals might get confused when looking at the list from their explorer of choice.

Reading many proposals which have for the the most part the same content can lead them to confusion and can represent a knowledge barrier for new users to understand how we got to the current situation.

2. Loosing of deposited ATOMs when proposals are not accepted.

From the whitepaper we can read the following

If more than half of the voters choose to take the deposit (e.g. because the proposal was spam), the deposit goes to the reserve pool, except any atoms which are burned.

While this is obviously the correct thing to do, I think that this could lead to unwanted ATOMs being sent to the community pool after that a proposal overridden from another is (correctly) rejected.

3. Different acceptance meaning based on following proposals.

Let's consider the current situation with proposal 14 being overridden by proposal 15.
Now, let's suppose that proposal 14 is going to be accepted. What does that mean? Does it mean that the community wants to do what it's written inside it? Or does it mean they are voting "YES" only because they don't want to loose the deposited ATOMs (see point 2)?
I think that this can lead to confusion on early voters that later get to know their vote (and ATOMs they've spent performing the transaction) is not worth anymore or has completely changed meaning.

Proposal

I think that all of the problems above could be implemented in two different ways.

1. Implement a simple DropProposal transaction type

This transaction type should only contain:

1. The id of the proposal to be dropped
2. A textual motivation of the dropping

It will just:

1. Refund all the ATOMs deposited inside the specified proposal.
2. Set the state of the proposal to Dropped blocking any further deposit or vote.

2. Implementing an OverrideProposal transaction type

This transaction type is a more complete type based on the DropProposal one and should contain the following data:

1. The id of the proposal to be overridden.
2. A textual motivation (capped in max chars) that allows to describe why the previous proposal should be dropped.
3. The id of the new proposal that will override the old one.

By performing this kind of transaction, the same user that has made the original proposal will trigger a series of events such as:

1. Refund all the ATOMs that have been deposited inside the old proposal.
2. Set the state of the old proposal to Dropped so that no more ATOMs can be deposited and no more votes can be spent.
3. Link the new proposal inside the old one so that explorer can re-direct users properly.

Thoughts

I'm also thinking if the original proposal poster should somehow pay some fee in order to refund all the voters of the dropped proposal or not.

---

For Admin Use

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

[alexanderbez]

Hey @RiccardoM, thanks for opening up an issue on this!

Of all the issues you've pointed out I can only see (1) being valid. (2) is no longer applicable as all tokens are returned regardless of vote outcome unless the proposal ends in a veto or doesn't enter the voting period (next major upgrade). I also don't quite understand (3) as any superseding proposal should clearly state something analogous the verbiage: "This proposal supersedes proposal N...". e.g. For proposal 15, voters should only vote YES if they agree with the proposal and with the fact that is supersedes proposal 14.

On to the proposals, how is (2) any different than just creating a new proposal like you can now with the correct superseding verbiage -- depositors will be refunded anyway. I do see more merit to (1) however. It's simple and addresses the main valid issue you raised about causing confusion.

Curious to see what @sunnya97, @rigelrozanski, @zmanian and others think here?

[RiccardoM]

Hey @alexanderbez, thanks for your thoughts.

I didn't know that the next major upgrade will bring tokens returning even if a proposal fails to pass. This means that (2) can be taken not into consideration anymore.

About (3), I clearly understand what a YES should mean, but what I was trying to say is that new users might find this hard to comprehend without properly reading the whole proposal text. Also, a user creating a superseding proposal might not explain it very well. I think that having a new status might make this clearer and easier to understand.

About your thoughts on proposals, I think that (2) might make it more clear for users to easily and immediately understand which proposal supersedes the old one. The superseding proposal number field could be made optional to use, so that one could be allowed to drop a proposal without a superseding one.

Other things I was thinking about are:

1. Should we implement a "fine" for users who drop a proposal in favor of a new one? This could be used as a spam prevention mechanism.
2. Should we limit the period of time between which a user can drop his proposal? Otherwise, this mechanism could be used to drop proposals that are going to be vetoed just to get the deposited tokens back.

[alexanderbez]

About (3), I clearly understand what a YES should mean, but what I was trying to say is that new users might find this hard to comprehend without properly reading the whole proposal text.

Fair, but voting is a serious matter. All users, regardless of technical understanding, should read and understand proposals in full before casting their vote.

Also, a user creating a superseding proposal might not explain it very well.

Also true, but in such a case, users should then not bother voting on such a poor formulated proposal -- it should never make it past the deposit period. You'll see people create draft proposals in forums to gather feedback before actually creating the proposals. So this should rarely be an issue anyway.

I think that having a new status might make this clearer and easier to understand.

I agree. I think there is some ground we can uncover in regards to improving the UX. Namely, being able to drop/supersede an existing proposal. We just need to be careful about the mechanics and be cognizant of the corner cases.

[zmanian]

I am in favor a cancel proposal transaction.

[rigelrozanski]

@RiccardoM @alexanderbez

RE: DropProposal This seems like a decent first step, obviously needed based on how proposals have currently been getting used.

Should we implement a "fine" for users who drop a proposal in favor of a new one? This could be used as a spam prevention mechanism.

... maybe a relatively minor fine? but also maybe not - like I'd rather see the correct proposal rather than the person just leaving up there because they don't want to pay the fine and then have an antiquated proposal to confuse everyone even more. There is already the extra transaction fees required

Should we limit the period of time between which a user can drop his proposal? Otherwise, this mechanism could be used to drop proposals that are going to be vetoed just to get the deposited tokens back.

agreed.

RE: OverrideProposal

I find this proposal type kind of confusing, and would only support this proposal type if this message type was restricted to use by the original proposal sender, and would automatically override/drop the original proposal. I think that there are better systems that we can implement to foster explicit on-chain feedback for proposals through the idea of "Counter-Proposals". This concept of counter proposals is used into some liquid democracy systems I've been researching, but basically, as an outside member, during some initialization period prior to the active voting period I am capable of submitting a counter proposal or "alternative" to the original, which would then be amended to the original proposal and once the voting period was initialized, ranked voting systems (CC https://forum.cosmos.network/t/governance-module-ranked-choice-voting/2653) could be used to vote between proposed alternatives.

<ballot>
rank     proposal 
[    ]      Bob's Original 
[    ]      Megan's Alternative
[    ]      John's Alternative
[    ]      Reject All

Within Cosmos, I would imagine this described "initialization period" would probably overlap the deposit period and then maybe exist as an extra week prior to the voting period but once the adequate deposit has been submitted. There could also potentially be special transactions which somehow extend the initialization period, or maybe some arbitrary ruleset is enforced such if there are less than 48 hours before the voting period begins and a new alternative is proposed, then the countdown is reset to 48 hours to allow for even more consideration. of course then DropProposal and OverrideProposal would apply to the alternatives that folks would be submitting. In this way also the original proposal should be thought of simply an "alternative" such that if it was dropped all the alternatives would still be capable of being voted on without the original proposal.

<ballot>
rank     proposal 
[    ]      Megan's Alternative
[    ]      John's Alternative
[    ]      Reject All

I think that that the drop proposal (and simple proposal-originator overrides?) should immediately be made into an ADR because I see this as easy to implement and non-contentious. With regards to the potential for Alternative and ranked votings, this is more complex and more contentious however I will also start writing out an ADR of this nature to discuss details of what we might like to see.

---

Further there is no reason why multiple alternatives can't be simultaneously submitted, both at the original creation time of the proposal as well as during the "initialization phase"

<ballot>
rank     proposal 
[    ]      Bob's Original 
[    ]      Bob's Original Alternative
[    ]      Megan's Alternative
[    ]      Megan's Second Alternative
[    ]      John's Alternative
[    ]      Reject All

[kwunyeung]

I think the DropProposal is useful but not OverrideProposal. There are proposals superseding previous proposals as they are not editable. If the proposals can be dropped, I would also suggest to have EditProposal transaction. The proposal can be edited by the proposer during the droppable/editable period. We have already seen that many discussions happen after the proposal is on-chain. This period should be another status before the deposit period. The droppable/editable period let validators and delegators to notice that a proposal is already on chain, discussions are welcome and there are time to fine tune the proposal or drop it before it can be deposited. If the droppable/editable period is going to be overlapped with the deposit period, those atom holders who have deposited may not agree with the later changes.

[alexanderbez]

I would also suggest to have EditProposal transaction.

How would this differ from the current process where proposer(s) first outline their ideas and aggregate feedback through mediums like forums and such? Are we sure the technical overhead for this would be worth it?

Overall, it seems like there is some general agreement that we should adopt/propose an ADR for some sort of DropProposal mechanism -- it's simple and effective.

[kwunyeung]

How would this differ from the current process where proposer(s) first outline their ideas and aggregate feedback through mediums like forums and such?

I always see discussions really happen after the proposal is proposed on-chain. There are always amendments to the proposals. For example, on network upgrade, commit hash and launching time are always arguable. Even if there are typos, abandoning the proposal and start a new one is not fair to those agree on the idea and have deposited.

[alexanderbez]

I always see discussions really happen after the proposal is proposed on-chain.

That seems like a fault in the social process and not the protocol.

There are always amendments to the proposals. For example, on network upgrade, commit hash and launching time are always arguable. Even if there are typos, abandoning the proposal and start a new one is not fair to those agree on the idea and have deposited.

I'm confused. Are you for or against canceling/dropping a proposal?

In any case, it seems there is a general agreement to support something like a canceling/dropping feature. Amendments are harder to reason about.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.