L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
Rainbow Bridge
About
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.
About
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.
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
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.
Destination tokens are not verified
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.
The system uses the following set of permissioned addresses:
A Gnosis Safe with 3 / 5 threshold. 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.
Those are the participants of the BridgeAdminMultisig.
The system consists of the following smart contracts on the host chain (Ethereum):
Contract storing Near state checkpoints.
Contract verifying merkle proofs, used for withdrawals.
Escrow contract for ERC20 tokens. This contract can store any token.
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).