Proposal: Adopt the Gravity Dex on to the Cosmos Hub

Below is a Draft of the upgrade proposal to adopt and activate the Gravity Dex on the Cosmos hub.

Feedback and questions accepted.

This on-chain upgrade governance proposal is to adopt the Gravity DEX on the Cosmos Hub. By voting YES to this proposal, you approve of adding the Gravity DEX protocol on the Cosmos Hub, immediately after the proposal passes after the voting period.


In July 2020, the Iqlusion team developed ATOM 2021 to drive the direction of the Cosmos Hub after the completion of the Cosmos whitepaper and IBC. It became clear that providing liquidity to new IBC connected zones was core the Hub’s mission.

Tendermint ( and B-Harvest ( joined forces to produce and develop a Liquidity Module ( In 2021 March, they submitted a signal governance proposal to ask the Atom delegator community about Gravity DEX (Liquidity Module) adoption on the Cosmos Hub. Prop38 was very well approved by the community (

This proposal completes the first leg of ATOM 2021 and achieves the goals of the signaling proposal by bringing an IBC compatible DEX to the Hub.

Ready for Production

With continuous quality improvement of the codebase, very wide test coverage, a codebase audit from Least Authority and Simply VC, and subsequent follow-up codebase strengthening, along with extensive simulation processes, we are now very confident to be ready for production utilization of the Gravity DEX (Liquidity Module) on the Cosmos Hub. The Gaia branch for the new release with Gravity DEX feature can be found here(we need the release link here, or we can announce the release later). Please also check out the github repository for the launch testing of Gaia with Gravity DEX.

On-Chain Upgrade Process

Immediately after this proposal passes, the state machine program of the Cosmos Hub will be halted. And then, all validators and node operators have to substitute the existing state machine binary to the new binary with the Gravity DEX feature. Because it is an onchain upgrade process, the blockchain will be continued with all the accumulated history with continuous block height.

Potential Risk Factors

Although Tendermint executed very extensive testing and simulation, and conducted in-depth audits, and followed up with the corresponding codebase improvement, there always still exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors from the new Gravity DEX feature. In the case of serious problems, validators should stop operating the network immediately, and use the fixed state machine program provided by Tendermint.


Looking forward to vote YES!


Let’s go! Looking forward to seeing the Gravity Dex live on the Hub.


please do it fast.
I feel dizzy.

1 Like

We are ready to click on yes, thank you for the work done :+1::wink:

You’ll definitely have my vote!

Feedback - Let’s do it!!! Make it official! Congrats Gravity and Tendermint teams!

Congrats on all the hard work getting here! Can’t wait to use the dex and open a new era for Cosmos!

Of course! Yes I am waiting for gravity dex

The gravity dex launch is a huge deal! I’m looking forward to seeing it live

Chainflow wants to see this happen. We feel it’s important to have the ability to monitor the bridge daemon itself, before this proposal passes, as bridge daemon uptime will be critical and also a slashing condition.

See more context here.

This is the Gravity Dex not the gravity bridge.

1 Like

Thanks for clarifying.

A few follow-up questions -

1 - Were the audit results published publicly?

2 - Is this testnet live?

3 - Rollback plan

Regarding this, will a rollback plan be published prior to the upgrade?

I am very excited to see this live on the hub!



  3. at halt height, the old binary will stop sync. And then it should be substituted to new binary for upgrade procedure. So, it is a natural decision to roll back to the “halt height”, if critical problem rises.

Rollback guidance will be provided in crisis communications from the Tendermint team.


Ok u have my vote here

Thank you. Has Issue A in the report been addressed? I see Issue B has.

You cannot mitigate issue A in Cosmos-SDK 0.42. it can be mitigated in 0.43 so I expect that we should mitigate it then. It’s not practically exploitable with the 0.42-> 0.43 time window.