Withdraw governance proposal

[gsk967]

Currently, in the cosmos-SDK, there is no way to withdraw the governance proposal.

I want to add a new cli transaction to withdraw the governance proposal before the deposit period ends.

Proposal

service Msg {
    rpc WithdrawProposal(MsgWithdrawProposal)  returns (MsgWithdrawProposalResponse);
}


// MsgWithdrawProposal
message MsgWithdrawProposal{
    uint64     proposal_id = 1;
    string     owner       = 2 [(cosmos_proto.scalar) = "cosmos.AddressString"];
} 

// MsgWithdrawProposalResponse 
message MsgWithdrawProposalResponse{}

When a proposer does withdraw the proposal, all the deposits of the proposal will get back to their respective address.

[gsk967]

@anilcse @robert-zaremba @jackzampolin can you add your thoughts on this idea

[robert-zaremba]

I like the idea. What do you think about renaming to CancelProposal?

[robert-zaremba]

I think this Cancelling proposal can be only enabled in a certain circumstances. Options:

• voting didn't start
• voting didn't get quorum

[gsk967]

@zmanian @sunnya97 @alexanderbez @ValarDragon any thoughts on this idea.

[robert-zaremba]

I want to point out that setting min_proposer_stake to a low value will open for spam. In general, the recommended way should be to vote "no".

[gsk967]

I agree with the no voting option, but depositors need to wait deposit period + voting period

[anilcse]

I want to point out that setting min_proposer_stake to a low value will open for spam. In general, the recommended way should be to vote "no".

irrespective of this discussion's conclussion, I think having min-proposer-deposit would avoid potential spams.

[anilcse]

I agree with the no voting option, but depositors need to wait deposit period + voting period

Also software-upgrade proposals wont accept duplicate naming I belive.

[hxrts]

In this issue I proposed locking up the deposit for an additional bonding period. #12417 (comment)

[robert-zaremba]

Moving @hxrts idea to a new thread: #12417

Extend bond lock period to withdraw proposal

In these instances it would be beneficial if the proposer could withdraw the proposal with some small cost. The cost is to prevent griefing or scenarios where plausible proposals are intentionally withdrawn to run out the clock. I propose locking the deposit for one additional bonding period, which would mean the same deposit can't be recycled immediately, and the proposer incurs increased opportunity cost. The obvious alternative is burning the deposit, which also seems acceptable, though potentially overly punitive (sometimes proposals are simply superseded due to new information).

• Signalling, Param, Spend proposals should be withdraw-able up to the moment of passage, as well as generic message proposals.
• Upgrade proposals should be withdraw-able up to the specified upgrade height.

[alexanderbez]

lol this ^

[robert-zaremba]

we're only talking about the proposer being able to withdraw so you'd be be rugging yourself.

I know. I don't think it matters if it's a proposer or anyone else once the proposal passed.

[hxrts]

I understand where you're coming from but I guess I still think my solution is preferable. Again, think about the Hub Stargate proposal (Second time's a charm). In the 11th hour engineers were trying to verify a bug and patch before the upgrade height. It's not the kind of situation you want to be putting up a new cancellation proposal and whipping votes. imo the only viable in-protocol option is for the proposer to withdraw, otherwise you're in the same off-chain coordination mess.

[anilcse]

We have cancel-software-upgrade proposal if there's enough time. We also have an option to unsafe-skip-upgrades to skip any scheduled upgrades. That's implemented for avoiding last minute bugs with binaries (if any). We need to coordinate with validators for such cases definitely. If proposer just wants to withdraw without any information or ack from validators, that doesn't sound fair.

[hxrts]

ok let's just make withdraw by proposer valid until proposals pass. not willing to die on this hill.

[gsk967]

Proposer can cancel the proposal before the voting period end

Note :

1. We will add new field to proposer to Proposal
2. PROPOSAL_STATUS_FAILED status will be add to Proposal

Proposal

// proposal 
message Proposal {
    ...
    string proposer                       = 11 [(cosmos_proto.scalar) = "cosmos.AddressString"];
}

enum ProposalStatus {
  // proposal canceled 
   PROPOSAL_STATUS_CANCELED = 6;
}

//  msg service 
service Msg {
    rpc WithdrawProposal(MsgWithdrawProposal)  returns (MsgWithdrawProposalResponse);
}


// MsgWithdrawProposal
message MsgWithdrawProposal{
    uint64 proposal_id     = 1;
    string proposer       = 2 [(cosmos_proto.scalar) = "cosmos.AddressString"];
} 

// MsgWithdrawProposalResponse 
message MsgWithdrawProposalResponse{}

When a proposer does cancel the proposal, all the deposits of the proposal will get back to their respective depositors and min-proposer-deposit will be burned from proposer.

@alexanderbez @robert-zaremba @anilcse @aaronc

[robert-zaremba]

I think this is what @hxrts proposes, except, in what we discussed with Sam:

• Allowing cancellation only before the voting finishes
• Sending the deposit to the community fund instead of burning

[gsk967]

Okay @robert-zaremba , now min-proposer-deposit will be deposited into the community fund.

as per above discussions #11130 (reply in thread) , proposal only to be cancel before the voting period right ?

[robert-zaremba]

Personally i would prefer before the voting. Bit probably the consensus will be to allow it until the voting end. Maybe we can add some margin, eg: voting_end - 10%voting_period.

[gsk967]

I also prefer before the voting period only, because if proposal get 50% YES votes before voting period end , if proposer wants to cancel the proposal in this period what is the benefit here.

[alexanderbez]

The proposer should be able to cancel the proposal prior to the proposal's voting period expiring.

[robert-zaremba]

The Fellowship and Whitelist

https://polkadot.network/blog/gov2-polkadots-next-generation-of-decentralised-governance/

The Fellowship is a mostly self-governing expert body with a primary goal of representing the humans who embody and contain the technical knowledge base of the Polkadot network and protocol. Unlike the current Technical Collective it is designed to be far broader in membership (i.e. to work well with even tens of thousands of members) and with far lower in barriers to entry (both in terms of administrative process flow and expectations of expertise). Becoming a candidate member in the Fellowship is as easy as placing a small deposit.

As such, we adhere to three principles: firstly, the Fellowship must never have hard power over the network: it cannot change parameters, conduct rescues, or move assets. Concerning governance over the network, the only thing in its power is to reduce the effective timeline on which a referendum takes place.

Secondly, the rank system and weights must be designed so that we would not expect small groups of individuals to be able to capture and control overall decision-making capacity. While the Fellowship weights those with higher rank more in the aggregate opinion, the weight should not be so high as to make a small number of higher members’ opinions be insurmountable when compared to a coherent opinion coming from lower-ranked membership.

Thirdly, the Fellowship should be designed to grow and develop its membership and their aggregate levels of expertise and in doing ensure that its overall decision-making capacity gets stronger over time. For long-term success, the Fellowship must be an effective meritocracy where those with commitment, talent and expertise rise to greater levels of influence. To achieve this, we must give clarity and transparency to the process of entry and promotion through the ranks. To the highest degree possible, an individual’s identity should not form a consideration, only their ability.

[alexanderbez]

I don't see the point of such a body. They can only control the voting periods of proposals?