Bridges to Fuse
What is Fuse?
Fuse is a decentralized blockchain-powered platform and technology stack whose goal is to enable genuine mass adoption of crypto payments and decentralized finance (DeFi).
How to connect Fuse wallet?
You can connect the MetaMask wallet to the Fuse network. Step-by-step guide you’ll find here: https://tutorials.fuse.io/tutorials/network-tutorials/adding-fuse-network-to-metamask
There are four bridges you can use to transfer tokens to/from Fuse.
Types of token transfers
How does it work?
The transfer steps are the following
- Connect wallet on Blockchain A.
- Complete Send transaction.
- Connect wallet on Blockchain B.
- Complete Receive transaction.
There are several types of token transfer possible with Allbridge
- Send Native tokens and receive Native tokens.
- Send Native tokens and receive Wrapped (or minted) tokens.
- Send Wrapped (or minted) tokens and receive Native tokens.
- Send Wrapped (or minted) tokens and Receive Wrapped (or minted) tokens.
4 entities in the cross-chain token transfer process
- User — EOA (Externally Owned Account) / Wallet from which the token X is transferred from one chain to another.
- Blockchain A smart contract — a smart contract on the Source blockchain which receives transfer requests from the User.
- Blockchain B smart contract — a smart contract on the Destination blockchain, which accepts the input from the User.
- 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.
- 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.
- Blockchain A smart contract locks the received tokens from the User and creates a request log.
- With the Receive transaction, the User asks Validator to check the request log.
- Validator checks if funds were actually locked in the Blockchain A smart contract.
- If they were, the Validator sends its signature to the User.
- If they were not, the Validator replies with the message “Transaction is not found”.
- User sends the signature to the Blockchain B smart contract.
- 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 Fuse with Allbridge?
📌 Following our step-by-step:
How does it work?
Elk Multi-Bridge works is that $ELK is actually sent across the mainnet (ElkNet). Let’s use sending from AVAX and MATIC as an example. $ELK is burnt on AVAX, decreasing the supply and slightly increasing the price of $ELK on that chain, and minting the $ELK on the other chain, slightly increasing the supply and decreasing the price of $ELK on that chain.
That’s why $ELK is close to the same value across chains, because users can manually arbitrage it for more $ELK using ElkNet and other methods to convert the currency, accumulating more $ELK. Eventually, the plan is to be able to simply be able to swap, say, ETH on its native chain for, let’s say, AVAX on its native chain, while in the background, behind the scenes the DEX trades ETH for $ELK at the best price on the ETH chain, ElkNet burns ELK on ETH, mints it on the AVAX chain, and swaps the ELK for AVAX at the best price. As we have more $ELK liquidity providers, this will lessen the price impact of even large trades. If there is an impact, people will see the difference in price, selling ELK on one chain, and moving the value to the other in order to buy more $ELK, which evens things out price-wise.
Elk finance is completely decentralized, as only Moose NFT holders can validate transfers across ElkNet (who will get a small amount of $ELK for each validation) only if they are holding a certain amount of $ELK.
How to bridge to Fuse with Elk finance?
📌 Following this step-by-step: https://docs.elk.finance/features/cross-chain-elknet-bridge
How does it work?
Instead of leaving all funds in a single storage, each bridge’s funds are stored in three distinct segregated storage mechanisms.
On-Chain Contract (5% of the Funds)
The Hot Bridge contract manages the funds held in the Chainport hot wallet. Only 5% of total bridge funds are held here. The Bridge contract manages the porting transactions initiated by users — making ChainPort the first trustless bridge operator in the space. It is the only hot wallet in the Chainport ecosystem that actually holds funds. It is also the only asset storage mechanism with the ability to transfer funds to addresses not previously defined in the smart contract.
Fireblocks MPC Multi-sig (45% of the funds)
Fireblocks MPC is the biggest multi-party computation company in the world and provides ChainPort with multiple layers of battle-tested security.
Cold Storage Multi-Sig Safe (50% of the funds)
Chain Port also uses multi-sig wallets such as Gnosis with multiple ledgers to keep part of the fund segregation plans in different locations/vaults.
How to bridge to Fuse with Chain Port?
📌 Following this step-by-step: https://docs.chainport.io/for-users/how-to-use-chainport
How does it work?
Transactions go through three phases:
- Auction: During this phase, you (the user) are paired with a router (liquidity provider) who will provide the exit liquidity for your transfer. For example, if you are transferring DAI from Optimism to Arbitrum the router would provide the DAI on Arbitrum in exchange for the DAI you supply on Optimism.
- Prepare: During this phase, both parties lock up funds for a transfer — the user on the sending chain and the router on the receiving chain. Routers wait for the subgraph (a piece of infrastructure to easily process complex chain data) to show the user transfer before locking up liquidity on the receiving chain.
- Fulfill: During this phase, both parties unlock the funds for a transfer. The user provides a signature that is used to unlock their funds on the receiving chain, and the router uses the same signature to unlock the funds on the sending chain.
Once prepared, the transfer may be canceled once it expires by either party if it is not fulfilled. Alternatively, the person who is owed funds can cancel the transfer prior to expiry rather than fulfilling it. This means as soon as the transaction has been prepared, the user can cancel the transfer on the receiving chain while the router can cancel the transfer on the sending chain.
How to bridge to Fuse with Xpollinate?
📌 Following this step-by-step: https://www.youtube.com/watch?v=p61b2QBPpDA
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?