Stay vigilant against phishing attacks. Chorus One sends emails exclusively to contacts who have subscribed. If you are in doubt, please don’t hesitate to reach out through our official communication channels.

Blog

Proposal #3: Atom Transfer Enablement v2 Evaluation

Felix Lutsch
Felix Lutsch
April 4, 2019
5 min read
April 4, 2019
5 min read

Quick Facts

  • The Cosmos Hub launched without transferability of Atoms enabled
  • The transfer feature will be enabled with a software upgrade through a on-chain governance vote carried out by the community of Atom holders
  • The first transfer enablement proposal was declined as the software upgrade path wasn’t clearly specified
  • Criteria for the proposal to pass and for transfer feature to be enabled:

Stable Cosmos Hub mainnet without transfers

Clearly specified and decentralized upgrade process

New release for testnet with transfer feature enabled and other parameters such as the block size updated

Stable testnet with new release software

  • The second transfer enablement proposal just entered the voting and specifies a two-phase (two proposals) decentralized software upgrade process

Phase I: a vote on a proposal specifying a plan and the criteria that need to be achieved for transfers to be enabled

Phase II: an expedited vote on the exact git hash for the updated software and block height for when the upgrade will take place

  • The software release for the upgrade (v 0.34.0) is about to be released, after which a testnet (gaia-14k) will be set up to test it
  • If everything goes according to plan and both proposals pass, the earliest date at which Atom transfers may be enabled is the 19th of April, 2019
A timeline of the path to transfer enablement.

Chorus One is in favor of enabling transfers as quick as possible, as this is an essential feature of any blockchain network and because we want to encourage a wider distribution of Atom holders that isn’t limited to fundraiser participants. We believe the state of the mainnet proves the readiness of the network to enable transfers.

At the same time, we are aware that a new software release that will change parameters like the block size needs to be tested before migrating to mainnet. Additionally, we support a clearly defined process that allows for a decentralized upgrade to happen. Finally, we believe the integrity of the chain and the decision-making needs to be independently verifiable in the future, which is why a formalized governance process should be followed and the state of the old chain (cosmoshub-1) needs to be preserved adequately.

These requirements call for a two-step upgrade process where the first proposal is there to decide on what is planned and the second one is targeting a specific release that should match what was described in the first proposal.

The proposal at hand describes such a two-step process and it also plans to modify the parameters needed for the second proposal to pass. We support the current proposal including the 24-hour expedited governance rule for the second stage.

Some validators have suggested that there should be separate proposals: One on the general governance process and another one on the specific issue. We view the governance process of this proposal as an experiment and limited for this particular proposal. After this, we will have data to see whether this process is sound or a different governance process should be adopted. At that time, it will make sense to have a separate governance vote to decide on a general governance process. But to hold off enabling transfers at this point would be misguided, in our view.

The expedited governance rule states that a proposal may be deemed to have passed if ⅔ +1 of the bonded stake has voted in favor of the proposal for a continuous duration of 24 hours (after a buffer period of 24 hours passed). We think this is a reasonably secure way of ensuring that the plans from the first phase of an upgrade have been met in the second phase of the upgrade and that the proposal is actually supported by a majority of both validators and Atom holders delegating their stake.

We think the data from an abandoned chain should persist in an independently verifiable way in the genesis file of the new chain. The current proposed solution relies on trusting external identities to provide this data, which we believe is not sustainable. Chorus One will store cosmoshub-1 state data and encourages other validators to do the same to have as many entities as possible verifying the data that will be included in the genesis file of a future upgrade.

Our Vote

Chorus One is voting “Yes” on this proposal to enable transfers on the Cosmos Hub. We do view it as a desirable guideline that most proposals should cover only a single issue in the future.

Should the testnet with the new software release be unstable, or other problems emerge, we may vote no for the second proposal. We will follow the development of the testnet closely and will provide updates on our social channels.

If you want to vote yourself because you disagree with the voting choice of your validator(s), you can use the governance tool available on our website which allows you to cast your own vote that will overwrite all your validators’ decisions. Join our Telegram to discuss this issue further and make sure to subscribe to our social channels to be informed about future proposals and our evaluation of them.

Resources

An Overview of Cosmos Hub Governance
Transfer Enablement Proposal #1 & #2
Tendermint Recommendation to Decline Proposal #1
Forum Discussion on Proposal #2

Originally published at blog.chorus.one on April 4, 2019.