Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Implement proposals dropping/overriding #4978
Allow the discarding and/or overriding of a currently open proposal in favor of a new one.
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
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.
I think that all of the problems above could be implemented in two different ways.
1. Implement a simple
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.
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:
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 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 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.
... 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
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.
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
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"
I think the
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