✨ New!✨  C4 Cosmos leagueRead more »

Contest ran August 26September 8

14 day contest

Gravity Bridge contest

An open and decentralized Eth–Cosmos bridge.

$100,000 USDC + tokens

Total Awards

Althea Gravity Bridge Contest

Glossary
Gravity bridge a cross chain bridge between Cosmos-SDK and EVM based blockchains
Gravity Contract The Gravity Bridge Solidity contract that holds bridge funds on Ethereum
Gravity module The Cosmos-SDK module which makes up the SDK chain side of the bridge
Orchestrator A special process run only by the validators of the Cosmos-SDK chain. Performing Oracle functions and producing Ethereum signatures
Relayer A permissionless role that submits signatures from the validators to Ethereum as transactions

Contest Scope

Gravity Bridge is a cross chain bridge between Cosmos-SDK and EVM based chains.

The Gravity Bridge offers the ability to send funds from Ethereum to Cosmos and back, as well as the ability to deploy ERC20 representations of Cosmos based assets on Ethereum and transfer them bi-directionally as well.

Gravity is a complete system, made up of the Cosmos SDK 'module', a Solidity contract, and associated relaying/oracle code. This means the scope of this audit is quite large, covering the complete system across three programming languages.

Code

The commit hash 92d0e12cea813305e6472851beeb80bd2eaf858d of the repo github.com/althea-net/cosmos-gravity-bridge describes the exact code under audit.

This helpful link allows you to browse code specifically from this hash and you may find it useful when linking or otherwise referring to findings.

In addition to the code above, there is a smart contract for the Ethereum side of the bridge:

Gravity.sol (611 sloc)

The purpose of this contract is to store a representation of the Cosmos validator set and allow updates to that validator set, as well as deposits and withdraws to and from the contract. The events emitted by this contract are used by the oracle component of the bridge to perform actions on the Cosmos side of the bridge.

As part of a storage optimization the full validator set and voting power is not stored, only it's hash. The client submitting transactions must provide this data when it submits a transaction, this is a dramatic reduction in cost that makes updating validator sets with hundreds of thousands of frequently changing members cost feasible.

Docs

The Gravity Bridge developer guide covers:

All contributions are welcome! Gravity bridge is a complex system but you don't need to understand the entire flow and all three languages to contribute. Using the hotspots list as a guide anyone with Go and Rust know-how can get started.