Skip to main content



The Omnibride can be used in
Please avoid using the legacy Omnibridge:

Key Information

Omnibridge is a native token bridge that mints the canonical representations of bridged assets on Gnosis. The Omnibridge is built on top of the Arbitrary Message Bridge (AMB) and thus relies on the same group of bridge validators and trust model as the AMB.

The Omnibridge currently connects Gnosis to Ethereum.

The Omnibridge mints bridged tokens using a variant of the ERC-677 token standard, with all bridged tokens tracked in the canonical Bridged Token Registries.


Frontend URL
Trust Model4-of-8 Validator Multisig
Governance8-of-16 Multisig
Governance ParametersValidator Set, Daily Limits, Fees
Bug Bountyup to $2m
Bug ReportingImmunefi

Key Contracts


ContractEthereum Address
AMB Proxy Contract (Foreign)0x4C36d2919e407f0Cc2Ee3c993ccF8ac26d9CE64e
Omnibridge Multi-Token Mediator Proxy0x88ad09518695c6c3712AC10a214bE5109a655671
Validator Management Contract0xed84a648b3c51432ad0fD1C2cD2C45677E9d4064

Fees & Daily Limits

TokenEthereum -> GnosisGnosis -> Ethereum
Default Bridge Fees0%0.1%
Fees and transaction limits of specific token

Single Transaction Limits


Bridging DAI token to Gnosis Chain DOES NOT mint native xDai token. If you want native xDai, use the xDai Bridge

TokenEthereum -> GnosisGnosis -> Ethereum
Dai***1,000,000,0001,000,000,000 WXDAI

Daily Limits

TokenEthereum -> GnosisGnosis -> Ethereum
Dai***1,000,000,000,000,000,0001,000,000,000,000,000,000 xDai

*** Bridging Dai Using Omnibridge


Daily Limit is reset according to the following logic: the smart contract stores total amount of processed tokens per current day and reverts on a new transfer if it exceeds the daily limit. Id of the day is calculated using the formula timestamp / (number of seconds in 1 day), where timestamp is the Unix timestamp.

Bridge Validators

Bridge Governance

How it works

Ethereum -> Gnosis

  1. User approve Omnibridge as token spender.
  2. User call relayTokens() on Mediator contract.
  3. Mediator calls requireToPassMessage() on the Bridge.
  4. UserRequestForAffirmation event is emitted for validators to validate the message.
  5. Message is relayed to the mediator contract when consensus is met by calling executeAffirmation().
  6. ABM calls mediator on Gnosis chain:
    • token does not exist: the mediator deploys a new token registry and mints the relayed amount.
    • token exists: the relayed amount is minted in the token address.

Gnosis -> Ethereum.

  1. User calls transferAndCall on ERC-677 token contract to send tokens to Omnibridge contract
  2. OnTokenTransfer is called
  3. Mediator contract burns tokens and calls bridge contract's requireToPassMessage() function.
  4. UseRequestForSignature event is emitted for validators to validate the message.
  5. Validators listen to the event: call submitSignature on Gnosis chain.
  6. CollectedSignatures event is emitted when consensus is met.
  7. User calls AMB (Ethereum side) executeSignatures()
  8. ABM calls handleBridgedTokens() on Mediator.
  9. Mediator contract unlocks the tokens

The Omnibridge is built on top of the Arbitrary Message Bridge.

Mediator Contracts

To handle the approval of token transfers, the Omnibridge makes use of what is called a mediator contract. No matter which side of the chain is originated, the following flows are valid.

  1. User calls token contract's approve() function to approve the balance to be transferred.
  2. relayTokens() is called on the Mediator contract
  3. Mediator calls transferFrom() on the token contract, transferring the approved balance
  4. If this is the first time that token is being bridged to the destination network, it will also query the token's name, symbol and decimals so a new contract can be deployed on the destination network
  5. Mediator contract then calls requireToPassMessage() on the bridge contract

Exceptions and Special Cases

While most tokens can be freely transferred between chains, there are several exceptions where token properties create bridge-related issues.

  • Bridge operations are disabled for Rebasing tokens.
  • Inflationary tokens can still be bridged, but any accrued inflation IS NOT returned to the user upon bridge exit.

Rebasing Tokens

Rebasing tokens include an elastic function where supply can be increased or decreased at regular intervals. If these tokens are bridged, supply impacts could result in inequities on either side of the bridge. In some cases this could result in a bridge balance reduction and the inability for users to exit. To prevent this, we have disabled bridging capability for rebasing type tokens. A partial token list is included below:

Click to View List
Base ProtocolBASE0x07150e919b4de5fd6a63de1f9384828396f25fdc
VELO TokenVLO0x98ad9b32dd10f8d8486927d846d4df8baf39abe2
Tokens of BabelTOB0x7777770f8a6632ff043c8833310e245eba9209e6
Rise ProtocolRISE0x3fa807b6f8d4c407e6e605368f4372d14658b38c
Soft LinkSLINK0x10bae51262490b4f4af41e12ed52a0e744c1137a
Ramifi ProtocolRAM0xac6fe9aa6b996d15f23e2e9a384fe64607bba7d5
GRPL FinanceGRPL0x15e4132dcd932e8990e794d1300011a472819cbd
Xdef FinanceXDEF20x5166d4ce79b9bf7df477da110c560ce3045aa889

Inflationary (Staking) Tokens

Inflationary tokens accrue additional value over time. While they are locked in the bridge contract this value will accrue, but will remain on the balance of the bridge upon exit. Inflation will not be returned to a user's balance. This maintains the 1 to 1 ratio of bridged tokens necessary for OmniBridge functionality. Users are free to bridge these tokens but need to be aware that any accrued inflation will not be added to their balances. Usage of the accumulated inflation will be determined at a later time by bridge governors. A partial token list of inflationary tokens is included below:

Click to View List
Lido Staked EtherstETH0xae7ab96520de3a18e5e111b5eaab095312d7fe84
StakeHound Staked EtherSTETH0xdfe66b14d37c77f4e9b180ceb433d1b164f0281d
Cream ETH 2CRETH20xcbc1065255cbc3ab41a6868c22d1f1c573ab89fd
Binance ETH stakingBETH0x250632378e573c6be1ac2f97fcdf00515d0aa91b

Additional References:

Canonical Token Registries

Multiple Representations

In a multi-chain world, some assets (e.g. USDC) can be bridged over from different chains. This is because the two bridges create different representation of the token on Gnosis, even if the underlying asset is the same.

For example, there are two different representations of USDC on Gnosis(created by Omnibridge, it follows ERC677 standard):

AssetToken Contract
USDC from Ethereum0xDDAfbb505ad214D7b80b1f830fcCc89B60fb7A83
USDC from BSC0xD10Cc63531a514BBa7789682E487Add1f15A51E2

Gnosis adopts a naming convention where the "chain of origin" is added as a suffix to the token name (e.g. USDC from Ethereum, USDC from BSC)

USDC.e: A USDC token on Gnosis Chain that complies with Circle standard


When using Bridge UI:
Bridging from Ethereum, users bridge USDC and get USDC.e.
Bridging from Gnosis Chain, users bridge USDC on xDAI and get USDC.
Use USDC swap to swap between USDC.e and USDC on xDAI

USDC.e is a token compliant with the Circle's Bridged USDC Standard. To ensure smooth bridging operations, when using Bridge UI to bridge USDC from Ethereum, user will get USDC.e by default.

  1. Bridging from ETH:
    a. Select Ethereum as source chain and USDC as token to bridge, you will get the equivalent amount of USDC.e on Gnosis Chain. (If you wish to get the USDC on xDAI (old USDC), you may use the USDC swap in the Bridge UI to swap your USDC.e to USDC(old), and vice versa)
  2. Bridging from GC:
    a. Select Gnosis Chain as source chain and USDC.e as token, is not allowed, user need to swap their USDC.e to USDC on xDAI(old USDC) on the USDC swap.
    b. Select Gnosis Chain as source chain and USDC on xDAI (old USDC) as token, and claim their USDC on Ethereum.

For more detail, check out this twitter post.