Allow governance proposals to have native pipelining

[ValarDragon]

Summary

Often we pipeline governance proposals, that are only intended to execute conditioned upon another governance proposal passing. These have been commonly used throughout the cosmos hub's history, and a number of other chains, due to the latency of voting.

To my knowledge there hasn't been a pipeline fault yet, where the base proposal failed, and the propoals later in the pipeline that depended on its success had to have their votes switched to reflect this.

It should be possible to have governance proposals get "native pipelining", so that if the proposal whose success they are conditioned on fails, then the new proposal gets automatically rejected. This way voters no longer have to worry about this pipeline fault risk, and only vote after the conditioned upon proposal has been accepted.

Problem Definition

Its natural to want pipelined proposals so that governance can act in a more timely manner. However, the mechanics of pipelining requires voters to be online in the latter half, and less able to "vote and forget" in the earlier half.

Proposal

Allow all governance proposals to optionally specify a parameter for a proposal whose success they are conditioned upon. E.g. a parameter in the proposal file called depends_on_proposal. If its set, the new governance proposal can only get accepted / enacted on chain if what it depends on passes.

And then in the governance hooks, whenever a proposal gets decided, and an event is emitted, the governance module checks if there was any proposal conditioned upon it. If there was, and the conditioned upon proposal was rejected, it also rejects the proposal that has this pipeline condition, and immediately closes it.

---

For Admin Use

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

[alexanderbez]

Proposal makes sense to me and the implementation should be more or less pretty trivial. Might be a few corner cases to consider, but overall I think it should be pretty reasonable.

[aaronc]

Is there anything here that isn't covered by #9438 ? With #9438 you would simply have multiple actions in a single proposal. Are there scenarios where you actually need separate dependent proposals rather than a single proposal with multiple atomic actions?

[ValarDragon]

Sorry for the delay in response here.

Yes its not actually covered by that!

In Osmosis we often need these conditional proposals, where we only decide that the latter proposal was necessary well after the proposal being conditioned upon was created. (E.g. when pipelining incentive proposals, sometimes you want the incentive change to be determined based on on-chain data after some text proposal describing the change has been written. Or you want to make an adaptation to an incentive change prop, thats conditioned on the former proposal failing)

I believe this would have come in handy during some of the history of the cosmos hub as well. (ensuring that two conflicting proposals can't pass, where the latter was created while the former is still in voting period)

Namely cosmos hub upgrade 3 (props 13,14,15,16,19). I don't think this would have helped for the stargate upgrade props though.

[julienrbrt]

Is this still something needed @ValarDragon? I understand your use case: to be determined based on on-chain data after some text proposal describing the change has been written, but it seems like it is the only one. Submitting a proposal having multiple messages would work fine for all other use cases.