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


...


Tokens:

Description

Rainbow bridge is an 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.

Technology

Principle of operation

Rainbow is a Token Bridge that locks tokens in the escrow contracts on Ethereum and mints tokens on the Aurora or NEAR network. 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 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).

Permissioned Addresses

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.

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