Agree on spam tx testing on 0.34 testnet.
Adding our evaluation to this proposal and the way forward here. We voted YES and are in favor of a dual proposal system, but we do see the need for a clear specification of the two-phase upgrade process in the future to avoid mixing governance decisions and changes to the governance process as done in this proposal.
I have some concern about the expedited gov rule. If the proposal 3 passes, I’m afraid the expedited gov rule will be a precedent reference to many other situation. In the future, in what circumstances should we apply this gov rule?
I think it’s better we experiment with expedited proposals now than later, especially with something as simple as token transfers
You are assuming we already have expedited proposal.
Thanks for this thoughtful, complete and well written proposal @FrancescoSVC 
I voted yes, now have a couple questions that didn’t impact my decision -
A buffer period of 24 hours is also put in place from the time of full deposit payment to the possible start of the continuous 24-hours required. Note that this mechanism currently requires custom querying to determine.
Please carlify the buffer period. Does it start after enough stake is deposited to initiate the proposal? Is that the idea?
We want to preserve the blockchain and app state data for cosmoshub-1. In the future we may include these in the blockchain header perhaps as consensus parameters (which get loaded from the genesis file).
Several entities have volunteered to store the data for cosmoshub-1, including Simply VC, the Interchain Foundation, and Tendermint Inc. All validators are encouraged to retain this data and provide it at cost to anyone who requires it to serve the chain. A later governance proposal will determine what to do with this data.
What is the best way to preserve this data, i.e. which files on a validator should be preserved?
The expedited rule proposed is only limited to this particular proposal.
If in the future some proposal would recommend to use a similar expedited rule, then the community can vote on it within the scope of that proposal.
Hello everyone!
As per our blog post, Figment Networks has voted ‘yes’ to Cosmos Governance Proposal 3, which can be verified on Hubble here. We’re satisfied with Cosmos SDK v0.34, but we were ambivalent about expediting the governance process.
Thus, we have drafted three proposals for software changes:
- A formalized process for issuing non-emergency Cosmos SDK software upgrades.
- A formalized process for issuing emergency Cosmos SDK software updates.
- A formalized process for issuing critical Cosmos SDK software updates.
Please comment in Google Docs, on the Cosmos forum posts, or on Twitter. We’re using these guidelines to draft our proposals–join us to help establish community standards for best practices in Cosmos governance 