Integration of Ferrum Network's White Label Product Suite

Hi fellow Astar/Shiden friends,

My name is Nick Odio. I’m the EVP of Strategic Partnerships and Growth at Ferrum Network. It’s great to be here and I look forward to any feedback regarding the following proposal.

For those of you who are unfamiliar with Ferrum Network, let me give a high level overview before you click the link and dive into the attached document.

Ferrum Network is a deflationary cross-chain Blockchain as a Service DeFi company that specializes in adding token utility and advisory services to projects across the crypto space. Ferrum builds white-label blockchain solutions that empower startups and established organizations, enabling them to get their core products to market faster.

Ferrum’s mission is to break down barriers to mass adoption and we believe that the Polkadot/Kusama ecosystem, and specifically the Astar/Shiden team, are well positioned to facilitate in the mass adoption of crypto. The following proposal offers an avenue in which Ferrum Network and Shiden can embark on a journey to do just this.

Ferrum is quite bullish on this ecosystem and we would love to be a part of its growth and success by integrating our suite of white label products with Shiden to encourage developers, dApps, and projects to build here.

On behalf of the rest of the Ferrum team, we look forward to hearing your feedback!

Looking forward,


Hello team, thanks for your proposal. Allow me to ask you some questions.

  1. The bridge codes are publicly available on github?
  2. Currently, we have 2 bridges, ChainSafe bridge, and Anyswap bridge. What are your unique implementations?
  3. White label means that Astar core team provides Ferrum bridges under Astar’s name? This is not ideal for the team since the core team can’t take responsibility when there is a problem.

Hey Sota! Thanks for the feedback. Let me see if I can answer these questions for you.

  1. The smart contract code is published and verified on each network and can be verified here:


I can only list two links per post. I’ll send the Polygon and BSC links in a separate message.

I can only list two links per post. I’ll send the Polygon and BSC links in a separate message.

The rest of the infrastructure has been audited by Zokyo and has passed with flying colors at ratings well above industry average. See below.

  1. Great question! There’s quite a few advantages to our bridge over those that you mentioned.

  2. Speed- Currently the Ferrum bridge is able to bridge assets between BSC, Ethereum, and Polygon in under 3 minutes… and from BSC directly to Polygon without using Ethereum as a middle layer.

  3. Intuitiveness- The user experience is outlined in a simple 5 step process. This makes for an extremely simple UX and the UI is quite aesthetically appealing as well.

  4. Architectural Advantages- Because of the fact that Ferrum uses a 2-way bridge liquidity pool as opposed to the standard “burn/lock and mint” protocol bridges that we currently see on the market, we are able to allow projects the control over the token contract that gets deployed on the destination chains. Any token that is being withdrawn on the destination chain will be one that is authorized by the project who deployed the contract on the origin chain. Often times projects are finding generic replicas in the form of a standard Open Zepplin contracts on chains they had no idea they were live on. Not only does this create a mess when projects do decide to launch on other networks but it can be extremely costly to a projects token economy. Especially for those whose tokens aren’t standard contracts. For example they may have a reflection function built into the token contract that gets erases through “burn and mint” type bridges like AnySwap and ChainSafe.

  5. Security- Ferrum’s bridge is quite a bit more secure than others on the market currently for 2 main reasons:
    a. Architectural Security- Due to the fact that the Ferrum Cross-Chain Token Bridge runs on a two-way bridge liquidity system as opposed to a “Lock/Burn and Mint” protocol, the bridge contract never interacts directly with the token contract. Therefore, control over the token contract is never given to an outside smart contract, which is the case with many bridges on the market today. This is in fact the same vector that was used to exploit the AnySwap and PolyNetwork attacks… and it could get a lot worse. If bad actors can get control of these token contracts while the bridging contract is interacting with them, they could do more than just sell the tokens locked on the bridge. For tokens with upgradeable smart contracts they could, in theory, exploit mint functions of multiple tokens listed on these sorts of bridges and wreak havoc on the market. These are the types of threats that these sorts of bridging protocols are exposed to.
    b. Operational Security- From the OpSec point of view, the Ferrum bridge is quite a bit more secure as well. Projects are encouraged to keep only enough liquidity on the origin and destination chains to suffice for the volume that project anticipates to run through the bridge. With such a limited supply of liquidity, hackers are deterred from even attempting to exploit bridge liquidity pools as opposed to the AnySwaps and PolyNetworks on the market where millions of dollars in liquidity sit idle… basically begging to be exploited.

  6. Token Utility - Ferrum designs white label products that add utility to tokens from their early stages and beyond. More often than not, when a project launches, their product is not fully complete. Oftentimes, this causes investors to grow impatient and sell the token prematurely. Unique to the Ferrum Cross-Chain Token Bridge, we give projects the ability to become cross-chain compatible while creating additional token utility through our ‘bridge swap fee mechanism’. This is a feature that allows projects to choose a customizable fee that is charged in their native token for every transaction that occurs through the bridge. Projects can choose to burn these fees and become a deflationary asset, treat it as a revenue stream, consider them token buybacks, or use it as a reward mechanism for their community just to name a few.

  7. Adoption - One of the other major challenges that non EVM compatible L1 chains face in regards to adoption is the difficulty in which interoperability is achieved. EVM compatible bridging solutions are a dime a dozen. However, the architectural differences between Ferrum’s bridge the others on the market make bridging to non EVM compatible chains a reality. This will open up Shiden to a wide array of non EVM L1s.

Speaking of adoption, We have already received a 300k ALGO grant from Algorand, backing from the Moonbeam Foundation to integrate both Moonriver and Moonbeam, and an Early Build Grant from Polygon. We have many more networks in the pipeline but would love to prioritize Shiden!

Currently under audit is our v1.2 of the bridge. This will allow us to do a couple things that can be added to the list of advantages above:

  1. We will be able to tap into DEX liquidity. One of the projects that we are currently incubating through our pre-sale division (yet TBA), Avem, is building a DEX on Shiden. In v1.2, we would be able to tap into their DEX liquidity to source the bridge liquidity as opposed to the project having to manage bridge liquidity on both origin and destination chains.
  • This makes the bridge more decentralized since DEXs will be the suppliers of the liquidity.
  • In turn this also makes it more secure since there’s one less vector to exploit.
  • It minimizes the routing that will need to occur thus making cross chain bridging and swapping cheaper.
  1. Due to the architectural differences that were mentioned previously, in this next iteration of the bridge, cross chain swaps will also be possible. Since we will be able to tap into DEX liquidity on say AVEM and Uniswap, the bridge could be responsible for swapping any asset available on either DEX.

  2. It doesn’t have to be a white label bridge. Thats just a service we offer. To avoid that, we can simply list projects in your ecosystem on the Ferrum branded bridge. However, if the project did opt for a white label bridge, this wouldn’t need to be offered under Astar’s name. It could simply be used by a project who has built on your network. The same goes for the ones we’ve deployed for projects on Ethereum. If anything were to ever happen, that wouldn’t be Ethereum’s fault. They were just the infrastructure that the project decided to build on. Ferrum is the bridge they chose.

I hope this was able to provide some clarity on your questions Soto. Please don’t hesitate to keep them coming!


BSC and Polygon Smart Contract Codes: