[PROPOSAL #49][ACCEPTED] Signaling Proposal - Deployment of Gravity Bridge on the Cosmos Hub

:globe_with_meridians: Read on GitHub
:fountain_pen: Author: @jkilpatr | CTO and lead engineer at Althea


This proposal is a Request For Comment to the ATOM community regarding the activation of the Gravity Bridge module onto the Cosmos Hub.

By voting YES to this proposal, you will signal that you approve of having the Gravity Ethereum <> Cosmos bridge deployed onto the Cosmos Hub.


Gravity as an Ethereum-Cosmos bridge is designed for the Cosmos Hub, to pull as much value as possible into the orbits of Cosmos via a direct and decentralized bridge. Gravity will be able to bring ERC20 assets from Ethereum into Cosmos, as well as Cosmos assets to Ethereum ERC20 representations. ATOM, and any other asset in the Cosmos ecosystem, will be able to trade on Uniswap and other Ethereum AMMs, and interact with Ethereum DeFi like any ERC20 token. This will bring a tremendous amount of liquidity and utility to these assets.

Cosmos, Ethereum, and Gravity

Gravity is a secure and highly efficient bridge between EVM and Cosmos SDK-based blockchains. At a high level, Gravity enables token transfers from Ethereum to the Cosmos Hub and back again, by locking up tokens on the Ethereum side and minting equivalent tokens on the Cosmos side.

Gravity is completely non-custodial. Control of the bridge mirrors the active validator set on the Cosmos SDK-based chain, and validator stake on Cosmos can be slashed for misbehavior involving the Gravity bridge.

The Gravity Ethereum contract is highly optimized, utilizing batches to dramatically reduce the cost of Cosmos → Ethereum transfers. Sending funds from Cosmos back to Ethereum can be up to 50% less costly than a normal ERC20 send.

How do validators support the Gravity Bridge?

Cosmos Hub validators will run three key software components of the Gravity bridge:

  • The Gravity bridge module, integrated into gaiad (the main Cosmos binary)
  • The Gravity bridge Orchestrator
  • A Geth light client or any Ethereum full node implementing the JSON-rpc standard

Cosmos to Ethereum:

To send transactions from Cosmos to Ethereum, the Gravity Bridge module first packages the transaction data, and makes it available on an endpoint. The Orchestrator then signs this data with the validator’s Ethereum key, and submits it as a message. These signatures will then be assembled and submitted to the Ethereum chain by relayers.

Validators may be slashed if they fail to submit Ethereum signatures within 6000 blocks (about eight hours) of their creation.

Validators may also be slashed if they sign a message with their Ethereum key that was not created by the Gravity bridge module.

Gravity bridge has no other slashing conditions.

Ethereum to Cosmos:

The Orchestrator also monitors the Ethereum chain, submitting events that occur on Ethereum to Cosmos as messages. When more than 66% of the active voting power has sent a message observing the same Ethereum event, the Gravity module will take action.

This oracle action will not be incentivized, nor will it be enforced with slashing. If validators making up more than 33% of the staked tokens do not participate in the oracle, new deposits and withdrawals will not be processed until those validators resume their oracle obligations.

The oracle was designed without slashing conditions to ensure that a consensus failure on Ethereum does not affect operation of the Cosmos chain.

Slashing Conditions Spec

How does it work?

Gravity consists of 4 parts:

  • An Ethereum contract called Gravity.sol
  • The Gravity Cosmos module
  • The orchestrator program which is run by Cosmos validators alongside the Gravity module
  • A market of relayers, who compete to submit transactions to Ethereum


The Gravity Ethereum contract is a highly compact and efficient representation of weighted powers voting on Ethereum. It contains an Etheruem key from each Cosmos validator, as well as their voting power. This signer set is continuously updated as validation power changes on Cosmos, ensuring that it matches the current Cosmos validator set.

Sending tokens, or updating the validator set, contained in Gravity.sol requires more than 66% of the total voting power to approve the action. In this way Gravity.sol mirrors Tendermint consensus on the Cosmos chain as closely as possible on Ethereum.

Gravity Cosmos Module

The Gravity module governs and coordinates the bridge. Generating messages for the validators to sign with their Ethereum keys and providing these signatures to relayers who assemble and submit them to the Ethereum chain.


The Gravity bridge orchestrator performs all the external tasks the Gravity bridge requires for validators. The submission of signatures and the submission of Ethereum events.

While the Gravity module concerns itself with the correctness and consensus state of the bridge the Orchestrator locates or creates the correct inputs.

Market of Relayers

Relayers are an unpermissioned role that observes the Cosmos chain for messages ready to be submitted to Ethereum.

The relayer then packages the validators signatures into an Ethereum transaction and submits that transaction to the Ethereum blockchain. All rewards in the Gravity bridge design are paid to msg.sender on Ethereum. This means that relayers do not require any balance on the Cosmos side and can immediately liquidate their earnings into ETH to relay future messages.

Security assumptions

The Gravity bridge is designed with the assumption that the total amount of funds in Gravity.sol is less than the value of the validator set’s total staked tokens.

If this assumption does not hold true, it would be more profitable for validators to steal the funds in the bridge and simply lose their stake to slashing.

There is no automated enforcement of this assumption. It is up to the $ATOM holders to take action if the amount deposited in the bridge exceeds the total value of all stake on the hub.

It should be noted that this condition is not unique to the Gravity bridge. The same dynamic exists for any IBC connection, and even exists in scenarios other than cross-chain communication. For example, in a hypothetical blockchain keeping domain name records, this same vulnerability would exist if the potential profit from exploiting the domain name system was greater than the value of the validator set’s total staked tokens.

Ongoing work

The Gravity Bridge has been continuously tested throughout Q1/Q2 2021 by multiple ongoing test nets with a diverse group of validators.


The Althea team is committed to playing a long-term role in upgrading, documenting, and supporting Gravity over the coming years. The Gravity bridge is currently live and running in a testnet, which validators can join by following the instructions here


The Gravity bridge module is currently undergoing an audit with Informal Systems estimated to be completed by the end of July, 2021.

Phase one of the audit has been completed, which resulted in the addition of evidence based slashing and several other minor design fixes.

The phase two design audit will be completed by the end of June. To be followed by phrase three, an implementation audit to be completed by the end of July.


With this proposal, the Althea team, together with Cosmos ecosystem partners, will expedite the development of the Gravity Bridge with an incentivized testnet and launch in Q3 2021. Althea will be closely shepherding the Gravity Bridge throughout all phases related to the testing, audit, and implementation process on the Cosmos Hub.


The Althea Gravity bridge team.

Deborah Simpiler, Justin Kilpatrick and, Jehan Tremback

We’d like to share praise and thank you for contributions from the following teams!

Interchain Foundation

All in Bits/Tendermint

Sommelier, Informal, Injective, Confio

Gravity Readiness Committee:

Justin Kilpatrick and Jehan Tremback, Althea

Zarko Milosevic, Informal Systems

Zaki Manian, Sommelier/Iqlusion

Governance Votes

The following items summarize the voting options and what it means for this proposal.

  • YES : You agree that Gravity Bridge should be deployed to the Cosmos Hub.
  • NO : You disapprove of deploying Gravity bridge on the Cosmos Hub in its current form (please indicate in the Cosmos Forum why this is the case).
  • NO WITH VETO : You are strongly opposed to the deployment of Gravity bridge on the Cosmos Hub and will exit the network if this occurred.
  • ABSTAIN : You are impartial to the outcome of the proposal.



Is running the Gravity Module difficult for Cosmos Validators?

Soliciting feedback from dozens of Cosmos hub validators and over 100 test net participants, we found that running the Gravity module is not a difficult task or undue burden on Cosmos validators.

Is the Gravity bridge secure?

The Gravity bridge is undergoing an audit by Informal Systems. It will then be up to ATOM holders to interpret the results of the code audit and weigh implementation risks in another governance proposal before deployment. Fundamentally, the design of the Gravity Bridge means that its security is directly represented by the security of the validator set on Cosmos Hub.

Are slashing conditions a problem for validators?

Gravity Bridge slashing conditions closely mirror the slashing conditions which validators are already subject to.

  • Uptime: Validators on Cosmos currently must keep their validator software running at all times, or risk slashing. Gravity adds an additional binary which must be run, which is low in difficulty.
  • Equivocation: Validators on Cosmos are subject to slashing if they sign two blocks at the same height. It is possible for this to happen through accidental misconfiguration. Gravity adds an additional item which must not be signed, which are the fraudulent bridge transactions that never existed on Cosmos. It is not possible for this to happen by accident, so this slashing condition is much less of a risk than the Hub’s existing slashing conditions.

How is Gravity Bridge different from Peggy?

The original vision for Peggy outlined in the Cosmos whitepaper is a ‘peg-zone’, meaning a Cosmos blockchain that exists for the sole purpose of running the bridge to Ethereum. All tokens would then be moved to other more general purpose Cosmos chains via IBC.

This design is heavily reliant on IBC, not only for moving Ethereum tokens to where they will be used, but also to handle the stake for bridge operations. The validator set operating the bridge must have at least as much at stake as the value in the bridge. In the Peggy concept this would require some shared security system built on top of IBC.

Gravity is a simplified design for a bridge that relies directly on the stake of the Cosmos chain running the bridge. Bridges like IBC and Gravity are complex on their own, so by taking this strategy IBC and Gravity remain as distinct bridges operating on the same chain, rather than being tightly connected systems.

This is easier to both design and debug, and is ideal for high-value chains like the Hub.


So i guess that any counter proposal to put the bridge on a dedicated zone instead of the cosmos hub is quite bad on the security side because the new network would be way less secure.

If our intention is to bring a massive amount of value (in the billions) from the Ethereum chain, then it has to happen on the hub.


I support this proposal! Glad to see it’s going up. I think this will be a great addition to the cosmos ecosystem and help kickstart defi on cosmos.

I see this is only erc20s is there any plan to add support for nfts later or is that not possible due to the bridge design?


I will support this proposal,
The only thing that I concerned is security.

im in support of this proposal.

I’m generally in favor of this approach.

1 - I would like to better understand why the bridge should be deployed by hub validators. We started to discuss this during the Chainflow Althea/Gravity AMA yesterday, so I know @jkilpatr has done some deep thinking on this question.

2 - I don’t think it’s unreasonable to require validators to do more work to earn their Atoms as @zaki_iqlusion Tweeted. In this case that means running a Geth light node and the Gravity binary. From running on the current Althea/Gravity testnet, I would like to see -

  • The Gravity source code released, so it can be built from source. I don’t think this was available during the early testnet stages.

  • A reliable and accurate way to monitor individual Gravity binary functionality and performance. There’s not a good way to do that right now, as I understand it. This is critical to have before it can be implemented in a reliable way and to reduce slashing risk.

3 - I don’t know if I’d say running a Geth light node and Gravity binary are “easy” or “hard”. I’d frame it in terms of risk. Validators are being asked to go from running 1 process reliability to 3 processes. While I don’t feel this is unreasonable, I wouldn’t say it’s trivial, either. For example, Geth has come a long way over the years, yet can still be a bit finicky at times.

The mandate of the Cosmos Hub is to be a hub for interchain communication. This means making and maintaining as many IBC connections as possible (which can have an non-trivial governance burden as IBC scales) and accepting as many bridges as is reasonable. It’s up to the Atom holders to decide if the burden of Gravity bridge is reasonable, but I think it’s hard to argue that a hub for cross chain bridges shouldn’t have a bridge to Ethereum as soon as possible.

Up to date source code for the Gravity bridge can be found here.

The current testnet is integrated into the Althea chain

During early testnets changes where being made so quickly it was hard to tell what version was ‘current’ in any real sense. With Gravity testnet2 I scheduled a chain upgrade before going public with the expectation that more fixes would have to be integrated.

Turns out that wasn’t the case. This is the git commit we’ve been using for testnet2 without issues


As discussed in the proposal there are no slashing conditions for Ethereum oracle message submission. Meaning if a Geth client fails the validator faces no consequences. This does risk the bridge halting (new deposits and withdraws not processing) if validators don’t maintain their Eth nodes, but it means that the uptime of the chain or a validator is never related to the reliability of a Geth or Ethereum node. Which is essential for maintaining sovereignty.

Once the validators fix their Ethereum nodes the bridge would catch up and process all the waiting deposits and withdraws.

Support for this being on the Cosmos Hub and thanks for clarifying @jkilpatr. Looking forward to using the bridge and get defi on cosmos going!

We will support this proposal and will follow with the execution and upgrade work. We believe this should be benefit to the Cosmos Hub!

Looking forward to it.

1 Like

Thank you for the thoughtful responses. The only point holding Chainflow back from voting “Yes” is the pending availability of a reliable way to monitor bridge status.

While we’re relieved to hear that Geth downtime doesn’t cause the bridge to go down, which could lead to slashing, we believe it’s critical to have some way to reliably monitor the bridge itself, to minimize downtime, maximize availability and avoid slashing.

1 Like

Thanks Chris,

The goal of this proposal is to get community approval for a bridge with these design properties and requirements. We’re hard at work testing and improving monitoring and other factors right now.

Just this weekend on our testnet Gorli had a very rare chain-reorg I’ll be working on monitoring for that case this week as it was difficult to determine what state the bridge was in. We’re doing our very best to test this software rigorously and build the monitoring and tooling in a way that’s driven by actual use and requirements.

Would be happy to schedule a meeting on what sort of monitoring architecture would fit the needs of validators best.