Bridges on Aurora

What is Aurora?

Website: https://aurora.dev/
Aurora is an Ethereum Virtual Machine (EVM) on the NEAR Protocol blockchain. It delivers a turn-key solution for developers to operate their apps on an Ethereum-compatible, high-throughput, scalable, and future-safe platform with low transaction costs for their users.

How to connect MetaMask wallet?

Step-by-step guide you’ll find here: https://doc.aurora.dev/develop/start/metamask

💡 A little tip! If you open Allbridge.io and choose the Aurora network, you can automatically add the Aurora network to your MetaMask wallet. Just follow our guide: https://www.youtube.com/watch?v=QtMU-xjV2aA

Aurora Bridges

There are three bridges you can use to transfer tokens to/from Aurora.

📍 Allbridge.io
📍 Rainbow bridge
📍 Multichain

Bridges features

Types of token transfer

Allbridge

How does it work?

The transfer steps are the following

1. Connect wallet on Blockchain A.
2. Complete Send transaction.
3. Connect wallet on Blockchain B.
4. Complete Receive transaction.

There are several types of token transfer possible with Allbridge

1. Send Native tokens and receive Native tokens.
2. Send Native tokens and receive Wrapped (or minted) tokens.
3. Send Wrapped (or minted) tokens and receive Native tokens.
4. Send Wrapped (or minted) tokens and Receive Wrapped (or minted) tokens.

4 entities in the cross-chain token transfer process

1. User — EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
2. Blockchain A smart contract — a smart contract on the Source blockchain which receives transfer requests from the User.
3. Blockchain B smart contract — a smart contract on the Destination blockchain, which accepts the input from the User.
4. Validator — a server that is responsible for verifying Lock, Unlock, Mint, and Burn transactions on the bridge smart contracts.

Example. Send Native tokens from Blockchain A and receive Wrapped (or minted) tokens on Blockchain B

The user needs to Complete 2 transactions: Send transaction on the Source blockchain and Receive transaction on the Destination blockchain.

1. With the Send transaction, the User sends a request to the Blockchain A smart contract, where specifies the address of the wallet on the Blockchain B and the X tokens that must be sent to Blockchain B.
2. Blockchain A smart contract locks the received tokens from the User and creates a request log.
3. With the Receive transaction, the User asks Validator to check the request log.
4. Validator checks if funds were actually locked in the Blockchain A smart contract.
5. If they were, the Validator sends its signature to the User.
6. If they were not, the Validator replies with the message “Transaction is not found”.
7. User sends the signature to the Blockchain B smart contract.
8. Blockchain B smart contract mints the requested amount of wX tokens and sends them to the User right away.

Read about 3 more transfer types here.

How to bridge to Aurora with Allbridge?

📌 Following our step-by-step guide from this link.

Rainbow Bridge

How does it work?

Lite Client
This is like a blockchain node, except that it only stores block headers, dramatically reducing the storage space needed. The LiteNode is implemented as a smart-contract, and we have two of them — one deployed on the Ethereum network, which stores NEAR block headers, and one deployed on NEAR which stores Ethereum block headers.

Relayers
Since LiteNodes are smart contracts, they can’t run and update themselves. Relayers are scripts running on traditional servers, that periodically read blocks from one blockchain, and communicate them to the LiteNode running on the other. So the relayers keep the LiteNodes up-to-date.

Since there is a transaction cost — i.e. gas fees — each time a relayer updates a LiteNode, the one on NEAR (containing the Ethereum blocks) is updated on each Ethereum block (since NEAR gas fees are cheap), while the update frequency on Ethereum (containing the NEAR blocks) is configurable and determined by an economic budget (currently about 12 to 16 hours).

Connectors
Connectors are smart contracts responsible for all of the logic associated with the cross-chain management of a given asset type. Like LiteNodes, they exist in pairs — one running on Ethereum, and one running on NEAR.

How to bridge to Aurora with Rainbow bridge?

📌 You can use the step-by-step guide from this link.

Multichain

How does it work?

The Cross-Chain Bridges
Each Bridge is a link between two block chains. On the asset origin chain, the asset to be bridged is sent to a special SMPC wallet address and held securely there. This is the Decentralized Management Account. On the destination chain, a smart contract mints tokens 1:1 with those held in the Decentralized Management Account and sends them to the user’s wallet. The opposite also happens when tokens are sent to the smart contract; they are burned and then the SMPC nodes release them on the origin chain.

The Multichain allows assets to be transferred between two or more blockchains. There are three categories of Routing transfer that we can consider:

Native assets

When a token already exists on a chain, we refer to it as a native asset. An example is USDC. In this instance, Multichain cannot mint the asset, so instead we use liquidity pools. A number of tokens are added by Multichain, a project team, or individuals to the pool on each chain. These tokens are then available for a user when they move cross chains. Ideally there are enough on each chain so that no matter how many tokens are transferred, there are enough in the pool for them.

Bridged Assets

When the Router uses assets which are created using AnyswapV5ERC20.sol, or a modified version of it, (Bridged assets), there is no need for a liquidity pool for the asset, since Multichain controls the supply of the asset on the chain where the contract resides. In this case the pool size is ‘Unlimited’. For a Routed asset whose cross-chain minting is entirely controlled by AnyswapV5ERC20, all that is required, is that a supply of that asset is added to the pool on the chain where the token was originally minted.

Hybrid Native/Bridged Assets

Sometimes it is necessary to combine native assets on some chains with assets controlled by Multichain’s Bridges. This often happens when a project minted a supply of that token, or already had a third-party bridge for an asset on another chain, but after joining the Router, wished to add tokens on extra chains. In this instance, the pre-existing tokens are ‘native’, but the tokens on new chains are ‘Bridged’. It is the responsibility of the project team to ensure that there is sufficient liquidity in the pool for assets which are native on a chain, but the liquidity on chains for which Bridges exist is ‘Unlimited’. Here is an example of a Router hybrid asset.

How to bridge to Aurora with Multichain?

📌 You can use the step-by-step guide from this link.

What bridge to choose?

When choosing a bridge consider the following:

• The chain you want to bridge from. Is it present on the bridge?
• The asset that you will receive after bridging: native or wrapped. If wrapped, where can you swap it to a native one?
• The fee, that you will pay for the transfer. Is it rational for the amount that you send?
• The time that transfer can take. Is it fast enough to take the opportunity that you were going to take before the bridging?
• The transfer limit. Is it enough to bridge the number of assets you need to?