You’ve probably heard by now that Umee is a “cross chain DeFi Hub that interconnects between blockchains”. You might also wonder, how the heck does that work? Let’s dive into the basics of how Umee utilizes the Gravity Bridge to make this possible.

What is the best part of Umee’s Bridge?

For us, its best feature is security and decentralization.

When an asset is transferred across the bridge in either UMEE <-> ETHdirection, the original assets are under the custody of the permissionless, decentralized validator set of the Umee blockchain through a multi-sig function process. Absolutely no centralized 3rd party is able to take over custody of funds being transferred across the bridge, the security of funds is guaranteed by Umee’s Tendermint BFT consensus mechanism. There is no risk of compromise on a centralized wallet, or centrally held private keys. Umee’s Gravity Bridge Module has been developed to provide the best cross chain security on the market, and aims to feature complete compatibility with any EVM compatible networks using the Gravity Bridge, and eventually provide further compatibility with more blockchains.

What is the Gravity Bridge?

The Gravity Bridge is exactly what it sounds like, it’s a bridge! However, it’s not like that dilapidated bridge on the outskirts of town that you’re afraid to drive over. Umee’s Gravity Bridge is a “blockchain bridge” that runs through the security of the Umee blockchain, and ultimately allows Umee to enable the transaction flow between Umee and the Ethereum blockchain.

Umee uses the Gravity Bridge as a base module and has built upon it furtherto provide a customized implementation, with a relayer called Peggo. If that’s rocket science to you, that’s okay. You can think of Peggo (which is used by all Umee validators) as the “engine” that synchronizes, verifies, and relays the transfer of assets across Umee’s bridge. Umee’s bridge uses the Gravity smart contract, which allows two-way transaction relaying between UMEE <-> ETH, and plays an integral role in allowing users to mint their tokens across chains.

Two Way Bridge Transactions

There are two main pillars which ultimately power Umee’s Bridge:

1. The Gravity Bridge Smart Contract
2. The Umee Gravity Bridge Module

Ethereum → Umee Bridge Transactions

The Gravity smart contract ensures assets are successfully minted across chains, from Ethereum to Umee.

To get a grasp on how this works, let’s take a look at the following example:

Let’s say that Alice has 100 USDC tokens on Ethereum, and wants to transfer her assets over to Umee to make them IBC compatible. Alice would complete this transaction by using Umee’s Bridge through the simple UI, and confirm her 100 USDC transaction with the click of the “Bridge” button. After waiting a short period of time, her USDC arrives in her Keplr wallet and is now able to be used on all Cosmos chains.

Behind the scenes, as soon as Alice confirmed her transaction, the sendToCosmos function on the Gravity smart contract was executed. The sendToCosmos function locked Alice’s 100 USDC onto the Gravity smart contract, which created an “event”. When the event occurred, Validators operating on the Gravity smart contract (using Peggo) picked up Alice’s 100 USDC transaction.

A validator is a node that validates, and verifies network transactions.

In order to complete the transaction, validators must come to an agreement that the event occurred. Once >66% of the validators operating on the Gravity contract confirm that they see Alice’s funds are safely locked in the Gravity contract, the equivalent tokens were relayed, and successfully minted on the Umee blockchain to Alice’s Keplr address that she requested.

As far as Alice’s original USDC on the Ethereum blockchain, validators “locked up” those assets in the Gravity smart contract as a form of backing of her assets on Umee.

• For Ethereum originated denoms (common ERC20 tokens such as Alice’s case), assets are locked up in the Gravity smart contract to serve as a form of backing of funds that are now available on the Umee blockchain. The IBC compatible tokens are minted on Umee with a special denom consisting of gravity+{ERC20 address}.
• For Cosmos Originated denoms (Umee or an IBC token), Tokens locked in the Gravity smart contract as ERC20 tokens, are unlocked and minted to the destination address on Umee’s side as IBC tokens.

Umee → Ethereum Bridge Transactions

The Umee Gravity Bridge Module ensures assets are successfully minted across chains, from Umee to Ethereum.

Let’s take a look at another example to see how this works going the other direction:

Bob has 50 ATOM tokens on Umee, and wants to transfer his assets to Ethereum to participate in Ethereum DeFi. Bob would complete this transaction using the Umee Gravity Bridge Module, also through the UI within Umee’s DeFi Hub, and confirm his 50 ATOMs transaction with the click of the “Bridge” button. If a sufficient amount of gas fee is paid, after waiting a short period of time, Bob’s ATOMs arrive in his Metamask wallet and are now able to be used on all Ethereum chains as an ERC20 token.

Behind the scenes, as soon as Bob confirmed his transaction, it was sent through the Umee Gravity Bridge Module. Bob’s pending transaction will be added to a batch of pending transactions of the same asset, ordered by fee, as an economic approach so that a group of same type of transactions can split the expensive gas cost as one transaction on Ethereum. Once >66% of the validators (using Peggo) operating on the Umee Gravity Bridge Module sign off on a batch of transactions, the batch is relayed to Ethereum and a denom is linked to Bob’s tokens, successfully minting his tokens on the Ethereum blockchain to Bob’s Metamask address.

As far as Bob’s original ATOMs on the Umee blockchain, validators “locked up” those assets in the Umee Gravity Bridge Module as a form of backing of his assets on Ethereum.

• For Cosmos-originated assets (Umee or an IBC token in Bob’s case), An ERC20 representation of the token must exist. Tokens locked in the Umee Gravity Bridge Module as IBC tokens are unlocked, and minted to the destination address on Ethereum’s side as ERC20 tokens.
• For Ethereum-originated assets (common ERC20 tokens), Tokens that were previously locked in the Gravity smart contract to back the IBC tokens on the Umee blockchain are unlocked and sent to the destination address on Ethereum. The representation of the ERC20 tokens in the form of IBC tokens is burnt.

Key Differences in Bridge Transaction Flow

We’ve learned that Umee uses the Gravity Bridge to mint assets across chains in both directions from Umee <-> Ethereum, but what are the main differences?

Ethereum → Umee transactions

Transactions are processed individually across chains through the Gravity Bridge smart contract. A transaction would trigger an event which would be seen by validators that have orchestrators running on their nodes. Orchestrators are responsible for monitoring Ethereum events, and relaying events to the Umee chain. Once >66% of orchestrators see the event, the transaction is confirmed and (actually minted) on Umee’s blockchain.

Umee → Ethereum transactions

Transactions are processed in batches, which are ordered by fee, across chainsthrough the Umee Gravity Bridge Module, rather than individual transactions. This allows many transactions to be sent and processed to Ethereum at once by orchestrators. In this case, orchestrators are responsible for signing the batches of transactions from Umee and relaying them to Ethereum. These transactions are processed and minted on Ethereum through the Gravity Bridge smart contract once >66% of orchestrators sign the transaction.

Why is Peggo so important?

Peggo is a requirement to run as an Umee validator — if a validator is not running Peggo it will result in a jailing event for that validator (validator is unable to participate in block proposals). Peggo is used by validators to ultimately verify all transactions across Umee’s bridge. When an ETH → UMEEtransaction is sent to the Gravity Bridge smart contract, Peggo scans the events of the contract deployed on Ethereum (Gravity) and relays the events as messages to the Umee chain. Additionally, in the UMEE → ETH direction, validators running Peggo relay transactions in batches from Umee to Ethereum through utilizing the same Gravity smart contract.

Peggo is also used to maintain an up-to-date registry of the Umee validator set on Ethereum. This is done through the valset update function, which is created immediately upon a change in power in Umee’s validator set. When a change in power occurs, a new valset update is created and must be signed by Umee’s validators, to guarantee the event. The update can then be relayed through Peggo to Ethereum by any participant in the network, to ensure the security of the validator set.

Peggo is used by validators to:

1. Maintain an up to date registry of the Umee Chain Validator set on Ethereum
2. Transfer ERC-20 tokens from Ethereum to the Umee chain
3. Transfer the IBC representation of the ERC-20 tokens from Umee to Ethereum
4. Transfer UMEE and any IBC tokens present in the Umee chain to Ethereum

Final Thoughts

From a quick overview standpoint, hopefully, you learned a little bit more about how the Umee’s Bridge works with validators to verify transactions across chains. It’s not easy stuff to understand, and for all you tech junkies out there, we’ll provide some further information in our Umee Docs soon.

What you do need to know, however, is Umee’s implementation of the Gravity Bridge is sophisticated in design and security to the utmost extent and has undergone intense security auditing to make sure we provide the best service possible to the market. If you’re interested in learning more about the bridge, please check out the Gravity and Peggo FAQ, or always feel free to ask questions in Umee’s discord!