Gitcoin Grants 20!Donate here

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

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.
  • Total value locked
    $308.30 M2.15%
  • Destination
    Near, Aurora
  • Validated by
    Destination Chain
  • Type
    Token Bridge
  • ...

    Risk summary
    Technology

    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. Checkpoints relayers are required to lock 5.0 ETH in order to submit block headers. If signatures are found to be invalid, checkpoints can be permissionlessly challenged and the relayers’ bond is slashed. Challengers can specify an address to receive half of the slashed bond. 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).

    Permissions

    The system uses the following set of permissioned addresses:

    BridgeAdminMultisig 0x2468…CDE1

    Admin can pause/unpause contracts, modify contracts storage and delegate call to any contract. This allows for any arbitrary action including removal of all tokens from escrows. This is a Gnosis Safe with 3 / 5 threshold.

    Those are the participants of the BridgeAdminMultisig.

    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    The system consists of the following smart contracts:

    NearBridge 0x3FEF…a873

    Contract storing Near state checkpoints.

    NearProver 0x051A…46c4

    Contract verifying merkle proofs, used for withdrawals.

    ERC20Locker 0x23Dd…127f

    Escrow contract for ERC20 tokens. This contract can store any token.

    EthCustodian 0x6BFa…FA52

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

    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).