[PROPOSAL][ABANDONED] Cosmos Hub On-chain Governance Proposal Resolution Recommendation

Source: Cosmos Hub On-chain Governance Proposal #2—Resolution Recommendation | by Tendermint | Tendermint Blog | Medium

Attn : Atom holders

Re : Atom Transfers Proposal: Big Dipper | Block Explorer by Forbole


AiB (All in Bits) will work with SimplyVC to propose a slightly modified proposal, with some needed changes, namely, with a new chainID, block size parameters, and a two-phase process for software upgrades. AiB recommends that those who have already voted YES to change their votes to NO for proposal-2.

This proposal isn’t intended to delay enabling transfers but to tweak some properties and to get 2/3rds votes on a specific code hash before an upgrade happens.


  • The desired chain upgrade mechanism for enabling transfers will start the chain from height 0, so it is necessary to bump the chainID to prevent double signing by validators. This is why the chainID ends with a “-1” suffix. The upgrade must change the chainID to “cosmoshub-2”.
  • The max block size and gas parameters shouldn’t change drastically from the current hub, especially before state syncing is fully implemented. Tendermint state syncing is on our immediate roadmap, once we have completed implementation and testnet testing, we can bump the block size up. AiB will recommend a 33% increase, for max_bytes to 200K, and max_gas to 2M.
  • We strongly favor a two-phase software upgrade process — the first proposal to agree on the scope of changes and the proposed software provider, and a second proposal to agree on the exact software Git commit hash and block height for the export-import upgrade. The first proposal will state that the second proposal need not wait the full 2 week voting period, but instead will be considered to have passed once +⅔ of the bonded Atoms have voted in favor, and stayed in favor continuously for a period of 24 hours (while disregarding the quorum requirement of 40%, for safety and liveness reasons). For more information, please see Post-Launch Roadmap - Proposal: Atom Transfers - #2 by cwgoes


For now, we recommend that those who voted YES change their votes to NO, and for those who haven’t voted yet to not vote, so as to prevent the 40% quorum from reaching. Should the 40% quorum be reached, we recommend that everyone vote NO for this proposal #2. If you agree with this posting, please share it w/ other ATOM validators and delegators.

We will provide more details around Thursday noon PDT, and in the meantime also update this posting w/ a link to a forum for further discussions.

NOTE: In the future we should upgrade the governance mechanism to allow a further voting grace period once the quorum has been reached, so as to prevent a last-minute “attack” on governance where the quorum is reached to pass the vote. AIB will work with the community to draft that proposal some time after transfers have been enabled.


For now, we recommend that those who voted YES change their votes to NO, and for those who haven’t voted yet to also vote NO. If you agree with this posting, please share it w/ other ATOM validators and delegators. UPDATE: It looks like the 40% quorum will be reached anyways, so our recommendation is to vote NO immediately.


sounds good to me. thanks

1 Like

Why does this happen now and not while the proposal was being drafted & reviewed?

I think what comes short in this proposal and what most people still don’t realize is the fact that incrementing the chainID and starting with an exported state also means that old states & transactions will not be available on-chain anymore. If they don’t get archived, it will be impossible to verify the consistency of the chain at a later point of time. This will get even more important once the network matures and connects multiple other chains with each other.

While the process of a few, trusted validators verifying the state export on Github and storing a copy of the old chain was sufficient in testnet, I believe we need a much more conservative approach on mainnet. Are there any processes/practices proposed by AiB or the ICF to at least archive those old blockchain states in a trustless/distributed way so that they can be verified by external identities in the future? In my opinion, this needs to be included in a proposal. Maybe a solution using IPFS could be used temporarily, where the hash of the old chain gets included into the new chain?


Florian from Staking Facilities


I think this can be dealt with later by requiring in the proposal that the block hash for the last block on cosmoshub-1 be included in the tendermint header for cosmoshub-2, and we expect all the validators to retain the blockchain and app/state data. If needed (as voted on later in governance on cosmoshub-2), we have the option of running a second net, a static cosmoshub-1 chain which only serves for syncing and querying purposes, or, Tendermint might be improved to deal with this automatically.

Or governance may vote to throw it away if there isn’t much demand for these initial blocks.

I agree that we need to avoid doing this in the near future, and we want to preserve block heights across chain upgrades. OTOH projects that are newly getting started will want to employ this kind of strategy in the beginning when stakes are low (to innovate fast), and sometimes you want a major version upgrade of a chain where the logic changes entirely, and requires an export/import to upgrade. Existing web frameworks do this often, and I’ve had to do things like that in iOS apps. Also, Tendermint itself might upgrade in a breaking way in the (more) distant future, and we may want to support the old set of APIs in the same way, via a link to a static serving chain running the old chain logic. So I think it’s worthwhile for us to go ahead and exercise that upgrade path once (or maybe twice if needed), and start building the header convention asap.

Proposed new block header:
“ParentChain”: Snapshot{ChainID,Hash,Height,Version…}

To be configured via config.toml via Tendermint, and saved in the Tendermint consensus state.

I guess I’m not a huge fan of creating an upgrade process the depends on unimplemented Tendermint software changes b/c we want to get an upgrade out next week.

We could just put a blockhash from the last block in the chain-id of cosmoshub-2-<last cosmoshub-1-blockhash>


I’d rather keep the chain id simple and short.

It’ll be part of the UX somewhere and we’ll need to develop a convention… the dash before the version already is a constraint, I don’t think we should be adding more to the chain id without more discussion of that convention/schema for chain-ids.

We don’t need to put the hash for cosmoshub-1 in cosmoshub-2 as long as the expectations are clear about what to suggest the validator community to store (namely the whole chain data for cosmoshub-1), and another proposal can decide to make use of it in the future, including it in the block hash for cosmoshub-2+, probably by adding it to ConsensusParams from the genesis file.

1 Like

Here’s a draft:

  • Introduced “original” vs “expedited” governance rules.
  • Added a blip about saving the state for cosmoshub-1.
  • Added scope of what is acceptable for v0.34.0
  • Added explicit expectation about how to vote for the second proposal

Thanks a lot for the above. We agree on most of it and would like to share some comments. Everything is split by section to make referencing easier.



Point 1: “Agree on a plan to set up a testnet” - “Lay out a plan to set up a testnet”

Original and Expedited Governance Rules


Update the section to: In order not to unduly delay the release process, a two-step governance setup
is being proposed, in the next section, for the release of v0.34.0. Before proceeding, let us define:

  • Original Governance Rules, to be the governance rules as currently implemented, namely,
    proposals are deemed to have passed if a 50%+1 majority of cast votes, excluding Abstain
    votes, by the end of the governance period (i.e. two weeks after the deposit threshold has
    been reached) are in favour of a proposal, a quorum of 40% of bonded stake has cast their
    vote and there are less than 33.4% Veto votes.
  • 24 - Hours Expedited Governance Rule, to be a different acceptance mechanism via which a
    proposal is deemed to have passed if 2/3 + 1 of bonded stake has voted in favour of the pro-
    posal for a continuous duration of 24-hours. 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 re-
    quired. Note that this mechanism currently requires custom querying to determine.

The 24-Hours Expedited Governance Rule aim to strike a balance between timeliness and safety by
reducing the time required for proposal acceptance while increasing the necessary quorum to 2/3 of
bonded stake + 1.


We wanted to make a clarification on the Original Governance Rules. Furthermore, we think that this
proposal should not include the definition of governance rules that can be used in perpetuity, but
rather to simply update the acceptance process for the second proposal in question. So, if people
accept this proposal (within the normal governance period), they also accept to make use a different
governance rule specifically for the second proposal.

We think that no further explanation on process is necessary since it is all discussed in a later section.



Point 3: “run and test the new version…” should be “run and test the new release…” (for consistency)

Point 4 : Update to: Following the successful testing of the new release, i.e. as long as no critical issues
are encountered on testnet, a subsequent second proposal is to be voted on using the defined 24-
Hours Expedited Governance Rule. If this second proposal is accepted, the mainnet is upgraded to use
the new release and amended parameters.


Point 2.1: Should currently be specifically defined? Eg: features included in commit

Possible Blockers


“We see three main possible…” should be “We see the following possible…”

Point 4: Remove “(by Expedited Governance Rules)”.
(We think the new rule should be specific to the second proposal and that’s it for the time being.)


Point 4 seems a little ambiguous in general.

Proposed upgrade process


Point 2: Update the following:

  • ‘max_bytes’ set to 200000 (as per your blog post)
  • ‘max_gas’ set to 2000000 (as per your blog post)
  • ‘withdraw_addr_enabled’ set to true
  • ‘blocks_per_year’ set to 4,855,015 – should proposal 1 on the cosmoshub-1 chain be ac-
    cepted by the community

Point 3.2: Update to: The second proposal should only be voted in favour of by each validator/del-
egator if each validator/delegator determines that the testnet (as defined above) was a success,…

Point 3.3: “It is expected valudators…” should be “It is expected validators…”

The paragraph starting with “Any bug fixes, as defined by…” should be removed as it is mentioned in
point 2.2 of the Proposal section…


Point 3.3:

  • Why is there a need to specifically mention punishment for voting NO? Nobody should need
    to justify their governance vote.
  • We are not sure that the validators should be voting YES/NO based on their readiness, but
    rather based on the readiness of the proposed software update and associated instructions.

Final paragraph:

The pre-definition of a 3rd proposal is completely out of scope of this document. In the end, if a critical
issue is found between the successful voting on the second proposal and the deployment of v0.34.0,
the validators should have no incentive to go ahead with the deployment anyway.

Persisting data from cosmoshub- 1


Paragraph 2: “SimplyVC” should be “Simply VC”

1 Like

The 2 phase approach resonates with me. I like the idea of having a phase 2 in which we consciously decide whether the new s/w is ready for production, rather than having that decision made solely by the core development team.

Also, maybe lost in the shuffle, is that v0.34.0 implements a parameter change proposal. This means a parameter change proposal that passes automatically implements the parameter change w/o manual intervention.

After spending 7 months building DAO tools at Aragon, I suggest we don’t take this change lightly. It’s a powerful one.

1 Like

Okey, Put this new proposal on mainnet. when will we vote it?

Re chainID conventions, I wrote a proposal last summer for the ChainID to be the hash of a new “Chain Description”, where

ChainDescription = <NetworkName>/<BlockVersion>/<AppVersion>/<StateHash>/<ValHash>/<ConsensusParamsHash>

is a complete description of the initial state of the chain. Upgrades could then be defined like:

ChainDescription = <PreviousChainID>/x/<Height>/<ForkDescription>

Where ForkDescription is the ChainDescription for the new chain

I think we should consider something like this.

While I see your rational, I think adding it within this proposal is beyond the scope. There is already a lot going on and we would not like to add extra points of contention.