Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Issues with existing bridge protocols and why Ferrum Network launched an initiative to build a secure multi-chain bridge protocol.
Architecture issue
Business impact
Priority
Notes
Lock and Mint and Burn and Mint mechanisms violate the principle of single responsibility introducing increased risk to each mapped token.
The impact areas include the significant value of assets locked in bridge pools along with the exploit of the protocol itself with it’s ability to mint a limitless amount of tokens.
high
Secure bridging and swapping architecture should include the following technical and business process security measures.
Bridge scope should be limited to transfer and keeping track of the state of assets across networks. It should not have any interactive or operative control over the token contract
Bridge pool asset lock up should be decentralized and diverted to multi-sig safes owned by each project rather than the multi-chain protocol
UX - Using a multi-chain or cross-chain product is still a foreign concept to most community members. Current UX doesn’t prioritize guidance through the process. A step by step walk through shall guide the user through the bridging or swapping process.
Many new users are weary of using cross-chain products and resort to centralized exchanges or are stuck with tokens on one network. This hinders the ability of new layer 1 / 2 networks to drive TVL towards their chain.
medium
The UX of the interoperability protocol must be geared towards novice users with step by step guidance. The UX should enable novice users to bridge and swap assets across networks without having to read a help article or watch a help video. However, it should not frustrate advanced users. Finding the balance in this UX implementation is key.
Unauthorized Wrapped Assets - Many projects have shared concerns over segregated and unauthorized liquidity along with faux markets being created for their token on networks where the project is not providing official support. This also introduces an increased risk of scams and unauthorized raises increasing the chance of rugs.
Many users take part in faux markets created by bad actors launching wrapped tokens on unvetted interoperability protocols and then creating a faux market on DEXs.
HIGH
Bridge deployment instructions and guidance must provide steps to inform the community of the official project tokens on origin and destination networks. Guidance should be shared with the community to avoid and limit the potential of scams.
Currently, porting liquidity to new networks is difficult. Users have to use: 1st dApp - Liquidate an asset using a DEX on the origin network into a bridgeable asset 2nd dApp - bridge the asset to the desired network. 3rd dApp - liquidate the bridgeable asset using another DEX into the desired asset on the destination network.
This cumbersome routine makes it difficult for networks to attract new users and ultimately TVL. The barriers to entry are simply too high to facilitate any sort of meaningful adoption of young networks.
HIGH
Nobody ever says "I'm going to bridge my USDC from BNB to Polygon just to hold my USDC on a different network." Let's face it, the only reason anyone ever wants to bridge an asset to another network is to liquidate it into something else. Why not remove all those layers of friction and allow the user to do so using a single interface instead of multiple dApps.
The general application stack is MERN. The front-end utilizes cloud-front and AWS S3 deployments to host the application interface whereas the back-end is deployed on EC2 instances through VPC and ELBs. Our dev, qa, uat, staging and prod environments are segregated.
Learn about Ferrum Networks MultiSwap and Two-Way Liquidity Pool Bridge product overview and background.
Ferrum takes a problem-driven approach to product development. We have utilized this approach in developing and deploying our Staking products and Incubator. Learning from those experiences, when it came time to allocate resources to the development of a next-generation multi-chain aggregator, we adopted the same due diligence process to assess the viability and need for another interoperability protocol in the market. We start with a series of “why” questions when evaluating product development.
Why is a multi-chain aggregator needed?
Why aren’t other multi-chain aggregators filling the demand and or issues outlined?
Why would users care about another multi-chain aggregator?
Why should we be the ones to build this multi-chain aggregator?
Answers to these questions are typically formed through a review of the technical architecture along with product deployment strategies of existing bridge providers. Our research found that indeed there is an unfulfilled need for a secure cross-chain swapping and secure bridging platform in the market. A multi-chain solution that conforms to the highest standards of security through technical architecture and business process security. We’ve committed ourselves to building the infrastructure needed to support such an interoperability protocol.
From a smart contract, module, and blockchain interaction standpoint there are a few core components that enable multi-chain bridging and swapping of assets through the MultiSwap protocol.
FIBER - Ferrum Inter Blockchain Express Routing Engine
API
Router
FORGE - Ferrum Optimal Routing Gas Estimation Engine
Bridge Pool
Fee Distributor - TODO
Node Infrastructure
Let's dive into these core components to understand how MultiSwap facilitates multi-chain swapping and bridging of assets.
Assets that have single asset liquidity added to the bridgePool are categorized as Foundry Assets. This liquidity can be added by Ferrum or the Token Administrators of listed tokens.
A major benefit of Foundry Assets is that swaps involving Foundry Assets typically skip interaction with an aggregator (1inch) or DEX (UniSwap). Instead, will prepare a path for Foundry assets to interact directly with the bridgePool. Saving liquidity provider fees for the part of the cross-chain swap that involves the Foundry Asset.
It's important to note that Foundry Assets are the only assets that are bridgeable across chains as their liquidity is managed by the bridgePool. All other assets must be converted to Foundry Assets to facilitate bridging across chains. This is further described in the and Sections.
MultiSwap's routing engine, FIBER, categorizes assets into three distinct types depending on their liquidity setup.
There are three main categories of assets currently:
Foundry Assets
Refinery Assets
Ionic Assets
Assets that have pair liquidity added with USDC to an ecosystem DEX are categorized as Refinery Assets. This liquidity can be added by Ferrum or the Token Administrators of listed tokens.
A major benefit of Refinery Assets is that swaps involving Refinery Assets typically require less swaps to facilitate the cross-chain swap. Saving liquidity provider fees for the part of the cross-chain swap that involves the Refinery Asset.
Ionic Assets typically have to go through multiple swaps to get to the bridgable USDC asset. This means the cross-chain swap for Ionic Assets incurs higher liquidity provider fees as a result of the required additional swaps.
Assets that don't fall into the or categories are categorized as Ionic Assets. This includes any asset with available liquidity on an ecosystem DEX.
FIBER Engine is the brains behind MultiSwap. It is the main source of contact for anyone looking to do a MultiChian swap utilizing MultiSwap.
FIBER Engine receives a request, then starts conducting a set of checks on the source and destination networks, including , , and checks.
Once FIBER Engine has conducted the necessary checks and determined the most optimal route for the MultiChain Swap request, it sends the request to the to process the request.
FIBER also interacts with the nodes and waits for verification from the MultiSwap node infra before authorizing withdrawAndDeposit or withdrawSwapAndDeposit requests on the destination networks through the .
The scenarios include
100 USDC on Ethereum to 3,164.5569620253 FRM on BSC
100 USDC on Ethereum to 0.345793423 BNB on BSC
Foundry Asset to Ionic Asset Swap
100 USDC on Ethereum to 20.5912 XVS on BSC
Refinery Asset to Foundry Asset Swap
0.345793423 BNB on BSC to 100 USDC on Ethereum
Refinery Asset to Refinery Asset Swap
0.06422277597 ETH on Ethereum to 0.345793423 BNB on BSC
Refinery Asset to Ionic Asset Swap
0.06422277597 ETH on Ethereum to 20.5912 XVS on BSC
Ionic Asset to Foundry Asset Swap
20.5912 XVS on BSC to 100 USDC on Ethereum
Ionic Asset to Refinery Asset Swap
20.5912 XVS on BSC to 0.345793423 BNB on BSC
Ionic Asset to Ionic Asset Swap
896.059 ALPHA on Ethereum to 20.5912 XVS on BSC
Example: 100 USDC on Ethereum to be swapped for FRM on BSC
First, let's go over how these were categorized.
Example: 100 USDC on Ethereum to 0.345793423 BNB on BSC
Let's go over how these were categorized.
FIBER Router is the single point of contact with the MultiSwap and is responsible for the movement of assets from user wallets to Dex Routers and/or to the Fund Manager and vice versa.
Thanks to the FIBER Router, no wallet or smart contract directly interacts with the providing additional layers of separation for any attack vectors targeting the liquidity stored in the .
The FIBER Router receives requests from the and processes them according to the requirements of each given request. These can include swaps for , or , or even liquidity-related events.
When the FIBER Router receives a swap request from the on the source network, it takes the requested tokens out of the user's wallet and deposits them in the while sending the Fees to the if this is a fee-enabled transaction.
On the destination network, when the FIBER Router receives a withdrawAndDeposit request from the , it takes the requested tokens from the and deposits them in the destination wallet provided in the request.
When the FIBER Router receives a or swap request from the on the source network, it takes the requested or tokens out of the user's wallet, moves them to the FIBER Router, then initiates the relevant DEX or Aggregator swap of this or to a . Once the swap is completed, the DEX or Aggregator router deposits the into the FIBER Router. The router then deposits these tokens into the while sending the Fees to the if this is a fee-enabled transaction.
On the destination network, when the FIBER Router receives a or withdrawSwapAndDeposit request from the , it takes the requested tokens from the , deposits them in the FIBER Router, then initiates the relevant DEX or Aggregator swap of this to the requested or . Once the swap is completed, the DEX or Aggregator router deposits the or into the FIBER Router. The router then deposits these tokens into the provided destination wallet.
Any MultiChain swap begins with a call to the . After receiving the multiChainSwap request, the FIBER Engine conducts a series of checks to categorize the source and destination assets involved in the swap. The section covers these checks in detail.
After the assets on the source and destination network are properly categorized, and the optimal route for the swap has been determined by the , it sends the request to the FIBER Router to execute the necessary transfers. We will cover those transfer scenarios in detail now.
F - In Progress
The source and destination assets have been categorized as by the , as demonstrated in the flow above. The FIBER Engine will now send a command to the to transfer the funds in accordance with the following optimal path.
The source asset has been categorized as a , and the destination asset has been categorized as a by the , as demonstrated in the flow above. The FIBER Engine will now send a command to the to transfer the funds in accordance with the following optimal path.
Fund Manager is the smart contract responsible for liquidity management, the configuration of Foundry Assets, and bridging settlement. Thanks to the , the Fund Manager does not need to interact with any external wallet or DEX router contract directly, adding additional layers of security to the MultiSwap architecture.
At a high level, FIBER is responsible for finding the optimal path to conduct swaps across chains, as well as bridging and settlement; depending on the asset type. If the asset has liquidity in the bridgePool these assets are classified as Foundry Assets. All foundry assets benefit from reduced fees during a swap across chains as one less swap needs to be conducted on the source or destination chain. FIBER conducts its work through FIBER Engine which interacts with the FIBER Router, Fund Manager, and external entities.
A typical FIBER call includes the following parameters:
sourceCABN
sourceFerrumNetworkIdentifier
destinationCABN
destinationFerrumNetworkIdentifier
amountSourceCABN or amountDestinationCABN
One of these values must be provided
destinationAddress
slippage: default max 2% per chain
platformFeeCABN
isFeeEnabled
After reviewing the parameters of a FIBER request, the FIBER engine determines the categorization of the assets involved into one of the following categories.
The categorization of assets defines the available paths to swap and bridge assets across chains. Foundry Assets will typically skip interaction with an aggregator (1inch) or DEX (UniSwap). Instead, FIBER will prepare a path for Foundry assets to interact directly with the bridgePool. Saving liquidity provider fees for the part of the cross-chain swap that involves the Foundry asset.
In each case, FIBER not only determines the optimal path between bridgePool vs DEX swaps, but also queries multiple ecosystem aggregators, and DEXs to determine the best possible rate for the swap and bridging of assets across chains.
It is possible for the sourceCABN to be a different category than the destinationCABN. FIBER's flexibility allows different asset categories to be swapped across chains in the most efficient manner possible.
sourceCABN: BUSD
sourceFerrumNetworkIdentifier: BSC
destinationCABN: USDT
destinationFerrumNetworkIdentifier: Polygon
amountSourceCABN: 100000000000000000000 (wei value)
destinationAddress: 0xdestination
slippage: 2% per chain (4% total)
platformFeeCABN: BNB
isFeeEnabled: true
When FIBER receives this call, it starts the process of categorizing the sourceCABN and destinationCABN. In order to categorize the FIBER engine conducts the following checks:
aggregatedBestQuoteCheck a check for the best price on source and destination networks. Checks quotes from aggregators such as 1inch and compares those quotes against DEX quotes from DEX Router contracts. Suggest all options available rated from best to worst.
See for more detail on CABN and ferrumNetworkIdentifier
Let's take and add some example parameters to understand the flow of events.
Conducts abridgePool liquidity check on destination network to determine if the asset has sufficient liquidity available in the bridgePool to be categorized as a for this swap.
Conducts if there is pair liquidity available with the bridgeable asset. i.e. Is it possible to convert user's asset to bridgeable asset in a single hop or swap. If the user's asset can be swapped for the bridgeable asset in a single hop, then the asset will be categorized as a . Otherwise the asset will be categorized as an .
All other asset types must be converted to a Foundry Assets in order to facilitate bridging of these assets across chains.
are considered bridgeable assets. This means there is sufficient liquidity available for this asset on the destination network to facilitate bridging for the amount requested by the users.
The flow of swap and bridging of assets across chains follows four steps known as MultiChain Settlement Flow (MCSF)
Swap from User Asset to Bridgeable/Settlement Asset
Bridging of Asset
Swap from Bridgeable/Settlement Asset to User Desired Asset
Deposit of Desired Asset Into User's Wallet
MultiSwap enables any asset on network 1 to be swapped for any asset on network 2. To facilitate these multi-chain swaps, FIBER uses .
Once an asset is converted to a the bridging process is initiated. Foundry Assets are deposited into the bridgePool on the source chain. After the verification of the deposit is completed, a signed withdrawal item and a Release and Deposit Request (RDR) is initiated on the destination network.
The GAS estimation is transparently shown to the user in the MultiSwap interface. If the GAS gathered according to the forecasted estimation is greater than the actual GAS cost, FORGE stores the excess gas in reserve associated with the user's address that initiated the swap.
FORGE calculates GAS cost for the swap and bridging transactions on the source chain, as well as any necessary or swaps and transactions on the destination chain.
There is a small fee associated with each MultiSwap transaction. This fee can be paid by users in a FORGE token of their choice.
Fee Tokens
FRM
cFRM
Network Fee Currency (ETH, BNB, Matic etc)
USDC
The fee is currently set to $1 per transaction. FORGE gets updated price quotes every 30 seconds to represent the value of non-stable tokens equivalent to $1. Fees paid in FRM and FRMx are discounted by 25%. Whereas fees paid in cFRM and cFRMx are discounted by 50%.
Our previous bridge node architecture and related infrastructure were in their infancy stage. For example, the signing of withdrawals was centralized to favor speed and security. In general, a simplified architecture was favored for v1.0.0. With the support of major backers such as Algorand, Casper and others, Ferrum Network started updating the Node Signing Architecture and related Infrastructure (v2.0.0) to enable decentralized Node signing. This major update was geared to provide additional security and reliability layers while allowing stakeholders like Algorand, Casper, and other networks in the ecosystem to run Generator and Validator nodes for withdrawals. The ability for more stakeholders to run Generator and Validator nodes brings state-of-the-art decentralization to the multi-chain protocol. This major upgrade will be pivotal in improving MultiSwap's architectural security without compromising speed and maintaining reliability.
The new node infrastructure is a culmination of three distinct node roles working together. Each adds an additional layer of security and authentication in order to reduce and discourage attack vectors on the system. The following nodes make up the bridging node infrastructure:
Generator Nodes
Validator Nodes
Master Node
Let's go over the roles of each node next.
View the full diagram by clicking the link below:
The Generator Node is one of the first components in Ferrum Network's Node Infrastructure that looks for, validates and generates withdrawal request items on destination networks for deposited tokens on origin networks.
The deposits are monitored through on-chain activity by these Generator Nodes. Once the nodes identify new deposits on-chain they submit those requests to the DB. At this point, the validator nodes come into play.
In this scenario, the asset is settled in a Foundry Asset, typically USDC.
Settlement events take place when the or swap on the destination chain falls outside of the desired slippage tolerance parameters provided as part of the FIBER request.
We're excited to share that we are building a shareable and embeddable widget for MultiSwap. This widget can be added to any website for any token in the Ferrum Ecosystem.
We are open sourcing our work with MultiSwap, FIBER, FORGE and our MultiChain Liquidity Pool Bridge. We are also exposing APIs publicly to help developers utilize the foundational tools we have already built.
The Master Node looks for requests that have met the verification threshold. The verification threshold is the number of authenticated validator node signatures required before a request is considered verified and authenticated. These parameters are configured by master node administrators through a quorum.
Once the Master Node has received the threshold signatures from authenticated validator nodes, it signs the withdrawal requests. The master node signature generates a valid one-time use withdrawal item.
The validator node verifies the newly received requests from the Generator Node against on-chain data. Once the verification is complete that this is indeed an authenticated on-chain request and not a spoofed request, the Validator Node adds it's signature as a verifier of the request.
NOTE: Only authenticated validator node signatures are honored. If a validator node is not authenticated the master node will ignore these signatures.
We secure our systems by ensuring all access follows the protocols. A good example of this is the segregation of accounts where the dev, QA, and UAT environments are set up vs staging and prod environments. Each account is only accessible by individuals who need to access them for their core job functionality and access to staging and prod accounts is further restricted to lead engineers. The management of user access is done in an entirely separate account, further restricting access control and adding another layer of protection against external phishing and related attacks.
General questions and their answers are described here related to MultiSwap.
MultiSwap is a smart routing multichain DEX aggregator that enables cross-chain swaps.
Seamlessly swap any asset on any network for any asset on any network with MultiSwap!
Select any EVM Network as FROM and To, and then select a token for swap. You will see the quotation after selecting tokens, and then you will be able to click on the Swap button.
Users can also swap to any wallet address by entering the address in the Send To field. Please refer to the following screencast
You can swap by selecting EVM/Non-EVM as a From and selecting EVM/NON EVM as a To address. The user needs to provide an address in the Send To field to conduct a swap.
Following EVM networks are supported in MultiSwap BSC Arbitrum Fantom Polygon
The following NON EVM network is supported in MultiSwap:
The following wallets are supported in MultiSwap Metamask for EVM chains and Kepler wallet for non-evm chains i.e. Cudos
You can report bugs through the "Report a Bug" button shown on the MultiSwap dApp as shown in the picture below:
Once you report a bug, grab the bug ID then follow the instructions below to submit a support ticket to notify a member of our team through our ticketing system. We have launched a ticketing system to ensure we can get you the best support from relevant team members.
Our support system is in Discord.
If you are already in our Discord Server
Go to the #mod-support channel
Click create a ticket and submit your bug ID along with a description of the issue
If you have not joined our Discord Server yet
Accept the rules, and grab the community-member role if you haven't already done so
Go to the #mod-support channel
Click create a ticket and submit your bug ID along with a description of the issue
A team member will respond to your query as soon as they review the ticket request.
The minimum amount for any swap is set as 0.01
You can check the status of your previous swaps by going to the My Trades section from the left menu under MultiSwap. You can see the statuses of your previous swaps, which will be marked as Completed.
If you are connected with a different network, and you selected a different network as From network then it will show you Switch Network. After clicking the Switch Network button you will be shifted to the required network in MetaMask.
You can search for available tokens by typing in the token name or pasting the token contract address in the search token field.
MetaMask and Kepler wallet extensions are required for making swaps between EVM to NON-EVM; however, only MetaMask is sufficient if you swap between EVM to EVM chains.
Currently there are no platform fees for using MultiSwap, you just pay for the gas charged by the network. Otherwise, MultiSwap is fee free for the time being.
Multichain swaps work through various processes based on the Asset's category, described as Foundry, Ionic, and Refinery assets. Please refer to the following link for more details.
Join our Discord by clicking this link:
Currently there are no platform fees for using MultiSwap, you just pay for the gas charged by the network. Otherwise, MultiSwap is fee free for the time being.
You can report bugs through the "Report a Bug" button shown on the MultiSwap dApp as shown in the picture below:
Once you report a bug, grab the bug ID then follow the instructions below to submit a support ticket to notify a member of our team through our ticketing system. We have launched a ticketing system to ensure we can get you the best support from relevant team members.
Our support system is in Discord.
If you are already in our Discord Server
Go to the #mod-support channel
Click create a ticket and submit your bug ID along with a description of the issue
If you have not joined our Discord Server yet
Accept the rules, and grab the community-member role if you haven't already done so
Go to the #mod-support channel
Click create a ticket and submit your bug ID along with a description of the issue
A team member will respond to your query as soon as they review the ticket request.
Join our Discord by clicking this link:
Following EVM networks are supported in MultiSwap BSC Arbitrum Fantom Polygon
The following NON EVM network is supported in MultiSwap:
The following wallets are supported in MultiSwap Metamask for EVM chains and Kepler wallet for non-evm chains i.e. Cudos
