L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our discord to suggest improvements!

Rainbow Bridge logoRainbow Bridge

  • Total value locked
    $572 M185.86%
  • Destination
    Near, Aurora
  • Validated by
    Destination Chain
  • Type
    Token Bridge

  • ...


    Choose token

    Bridged Tokens (Top 15)

    Aurora (AURORA)
    USD Coin (USDC)
    Tether USD (USDT)
    Ether (ETH)
    Dai Stablecoin (DAI)
    Wrapped BTC (WBTC)
    Wootrade Network (WOO)
    Frax (FRAX)


    Rainbow bridge is a light client based bridge between NEAR/AURORA and Ethereum that allows for asset and data movement between these chains. For better gas efficiency from NEAR to Ethereum, it leverages optimistic validation, which adds some trust assumption and latency.

    If you find something wrong on this page you can submit an issue or edit the information.

    Risk summary

    Note: This project's overview requires more research and might not present accurate information. If you want to contribute you can edit the information on Github. Alternatively you contact the project team on Twitter and encourage them to contribute a PR.


    Principle of operation

    Rainbow is a Token Bridge that allows transferring assets and passing arbitrary messages between Ethereum, NEAR, and Aurora chains. During token transfers, Rainbow Bridge locks tokens in the escrow contracts on Ethereum and mints tokens on the Aurora or NEAR networks. When bridging back to Ethereum, tokens are burned on Aurora / NEAR and then released from the escrow on Ethereum.

    Both inbound and outbound transfers are verified by the light client

    Note: This section requires more research and might not present accurate information.

    Near Rainbow bridge implements a light client for both inbound and outbound transfers. For inbound transfers, checkpoints of NEAR state are submitted every 4 hours. These are optimistically assumed to be signed by 2/3 of Near Validators. The signatures are not immediately verified by Ethereum due to a different signature scheme used on NEAR and - as a result - very high gas cost on Ethereum. If signatures are found to be invalid, checkpoints can be permissionlessly challenged. Users can withdraw funds by submitting a Merkle proof of a burn event against the checkpoint. For outbound transfers, Ethereum light client is implemented on NEAR and a Merkle proof of a lock event must be presented.

    • Funds can be stolen if incorrect checkpoint is submitted and nobody challenges it.

    • Funds can be stolen if bridge administrator removes funds from the bridge escrow (CRITICAL).

    Destination tokens are not verified

    Note: This section requires more research and might not present accurate information.

    Tokens transferred end up as ERC20 tokens on AURORA or NEAR and they do not appear to be verified.

    • Funds can be stolen if destination token contract is maliciously upgraded (CRITICAL).


    The system uses the following set of permissioned addresses:

    Aurora MultiSig 0x2468…CDE1

    Can pause and reconfigure the bridge with no delay, can remove all tokens from Escrow via adminTransfer() method.

    Participants of the 3/6 Aurora MultiSig.

    Smart contracts

    The system consists of the following smart contracts:

    ERC20Locker 0x23Dd…127f

    Escrow contract for ERC20 tokens. This contract stores the following tokens: DAI, USDC, AURORA, USDT, WBTC, WOO, FRAX.

    EthCustodian 0x6BFa…FA52

    Escrow contract for ETH tokens. This contract stores the following tokens: ETH.

    NearProver 0x051A…46c4

    Contract verifying merkle proofs, used for withdrawals.

    NearBridge (new) 0x3FEF…a873

    Contract storing Near state checkpoints.

    NearBridge (old) 0x3be7…7038

    Contract storing Near state checkpoints.

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).