MultiSwap and MultiChain Liquidity Pool Bridge
Search
⌃K
Links
🚩

Architecture issues

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.
  1. 1.
    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
  2. 2.
    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.

​