APPLICATION INTRODUCTION
Purpose of the System
With this grant, Ferrum will look to launch MultiSwap on Conflux. MultiSwap is a revolutionary piece of multichain technology that is driving Ferrum’s mission of paving the way toward Interoperability 2.0. MultiSwap is a smart routing multichain aggregator that enables crosschain swaps by tapping into existing DEX liquidity to support the volume being transacted on the protocol. By reinventing the way that assets are moved across networks, MultiSwap is positioned to port an immense amount of liquidity to Conflux. By tapping into DEX LPs to support the volume that is being transacted across the protocol, MultiSwap will encourage TVL on DeFi protocols across the Conflux ecosystem such as Swappi and others while making assets on the network more composable.
The architectural & OpSec advantages behind MultiSwap make it the most secure and compliant solution for moving assets between networks on the market. Additionally, Ferrum smart contracts are audited via multiple highly reputable security firms & battle tested via 3rd party white hat hackers. This approach boasts a lifetime TVL of over half billion dollars with the first iteration of MultiSwap, Ferrum’s Cross-Chain Token Bridge, being responsible for nearly $200 million in transacted volume.
Engagement
So far, we are compatible with Ethereum, Polygon, BSC, Moonriver, Harmony and Avalanche. At the time of writing, testing is being done on Algorand and Pocket Network. We have received grants from EVM compatible networks such as Polygon, Harmony, Moonbeam, and Astar, as well as non EVM compatible chains like Algorand and Casper to integrate their networks with MultiSwap.
Unique Addresses using Ferrum’s Cross-Chain Token Bridge:
Scope of the System
MultiSwap is a smart routing multichain aggregator that enables cross chain swaps by tapping into existing DEX liquidity to support the volume being transacted on the protocol.
At the time of release MultiSwap will be compatible with and allow swaps to Conflux from the following networks:
- Ethereum
- BNB Chain
- Polygon
- Avalanche
- Fantom
- Moonriver
- Harmony
- And hopefully Conflux!
Upon completion of the product, MultiSwap will be integrated with Swappi. Swappi’s liquidity will support the volume for any transactions that occur to or from the Conflux network.
CFX as Fee Token
For every transaction that occurs originating on the Conflux network, a fee will be charged to the user to offset the gas costs that Ferrum incurs. Users will have the ability to pay this fee in CFX.
TEAM
Naiem Yeganeh, PHD - Founder, CEO and Lead Developer
Having worked as a software engineer at the likes of Microsoft and Amazon to leading a core machine learning team at Bloomberg, Naiem is the mastermind behind the products at Ferrum. His technical prowess has laid the foundation for Ferrum’s success.
Naiem is the one who established the node infrastructure for MultiSwap and will be responsible for maintaining and managing the node infrastructure for the Conflux integration. Naiem will also be handling code reviews throughout the integration.
Email: [email protected]
Ian Friend, ESQ - Co-Founder and COO
Ian worked for many years as a lawyer before meeting Naeim in 2018 and deciding to embark on the Ferrum journey. Ian is one of the most beloved founders in the space and is the face of the company. The confidence that he has been able to instill not just in the community but also the multitude of projects that Ferrum has advised is invaluable to the success of Ferrum.
Ian is not only the co-founder but the face of Ferrum. He will be handling much of the day to day educational materials alongside members of our marketing team. Podcasts, YouTube interviews, and community engagement are all areas in which Ian will provide his expertise.
Email: [email protected]
Taha Abbasi - CSO
Taha has co-founded a multitude of companies including a wildly successful software development house called Web N App. Taha has worked as the CTO of multiple companies including National Geographic - Singapore and has led teams responsible for the Mars 2020 and Europa missions at NASA.
Taha serves as the CSO at Ferrum and oversees the development of Ferrum’s wide array of products. He is also the senior architect and will be designing and creating the architecture for the Conflux integration.
Email: [email protected]
Salman Haider - Lead Blockchain Architect
Salman has a rich-experience of 7 years working in corporate companies from being a Software Engineer to CTO. He had worked with Etisalat (Largest Telecom Network in Asia) & Avanza Innovations as a Senior Blockchain Engineer & Project Head of UAE Trade Connect (UTC - National Trade Finance Platform) and implemented the Blockchain Solutions in 13+ National Banks of UAE. (https://www.etisalatdigital.ae/en/uae-trade-connect.jsp). He has been working in Blockchain Space for the past 2 years with an in-depth and diverse experience in developing & Architecting Complex Blockchain Systems. He also teaches Blockchain Architecture at Althash University as an Associate Professor & Faculty Chair.
Salman Haider is our Senior Blockchain Architect at Ferrum Network with 7 years of hands-on experience of Architecting & Developing the secure Web 2.0 and Web 3.0 Complex Software Systems. Salman has expertise with Casper, Pocket & Algorand to name a few and has skillset in Solidity, RUST, COSMOS, PyTeal, and more. Salman will be our Senior Engineer working on this integration and will be leading our engineering team. Salman will also be the lead engineer in developing the smart contracts. His expertise will be very handy to get the delivery over the line within the delivery time period.
Email: [email protected]
Nichell Logue - EVP Operations
Nichell served as both a Project Manager and ultimately a Team Leader at CSC for over a decade before joining Ferrum. CSC is the world’s leading provider of business, legal, tax, and digital brand services to companies around the globe. At Ferrum, Nichell plays an integral role in ensuring the internal operations of the company are running smoothly. She’s a genius in terms of creating SoPs for the otherwise overwhelming amount of moving pieces at the company and also heads up our HR department.
Nichell is the EVP of Operations at Ferrum. She handles all of our HR related items as well. There’s a good chance that we will seek to source additional engineers in an attempt to speed up the timeline we provided. Nichell will play a vital role in sourcing that talent. Her and Nick Odio will oversee any logistical elements to the process as it pertains to the relationship between Ferrum and Conflux.
Email: [email protected]
Nick Odio - EVP Partnerships and Growth
Nick is a serial networker. From being heavily involved in the music industry, working with Grammy award winning artists, to leading field operations divisions for companies, Nick has extensive experience in areas related to strategic partnerships and relationship management, as well as strategic initiatives.
Nick Odio is our EVP of Partnerships and Growth at Ferrum. He is responsible for drafting the proposal. He is also one of the main spokespersons for Ferrum Network alongside Ian Friend and will be doing a lot of the PR related items as it pertains to MultiSwap alongside members of the marketing team. He will also play a vital role in the adoption of MultiSwap from a business development perspective as he will find and encourage partner projects to leverage MultiSwap within the Conflux ecosystem and beyond. He and Nichell Logue will oversee any logistical elements to the process as it pertains to the relationship between Ferrum and Conflux.
Abdul Ahad - Software Engineer
Abdul Ahad is a full stack resource with a lot of Web3 and React experience. He will be the lead frontend engineer for Conflux integration. Ahad will also be responsible for building the UI and integrating it with smart contracts.
Faizan Ali - Software Engineer
Faizan is also our full stack front end engineer who will be assisting Ahad with UI throughout the integration period.
Maiwand Sultan - Senior Project Manager
Maiwand will be the project manager for the integration and will be your primary POC. Maiwand will be making sure the milestones are delivered on time and everything is followed as per the initial approved plan.
Hasnat Malik - Director of Projects
Hasnat is the director of projects at Ferrum. Hasnat is responsible for making sure that the plan which is approved is also compatible with the other products at Ferrum. Any updates or upgrades happening for the products during the integration period are also implemented for Conflux integration to make sure all products are updated constantly.
[email protected]
Amir Hassan - Senior Quality Assurance Engineer
Amir will be the designated QA engineer for Conflux integration. He will be testing everything from end-to-end during the sprint cycles to make sure the quality is maintained.
Sheraz Riaz - Senior DevOps Engineer
Sheraz is the Dev-Ops engineer at Ferrum. He will be responsible for creating CI/CD pipelines for deployment.
The rest of the incredible team can be found here: https://ferrum.network/about-ferrum/
TOTAL BUDGET AND FUNDING TIER
Tier 3: $50,000
CURRENT FUNCTIONALITY
Problem #1 - The current model for interoperability is broken
Lock and Mint and Burn and Mint mechanisms violate the principle of single responsibility introducing increased risk to each mapped token. The areas of impact include significant value of assets locked in bridge pools creating honeypots for bad actors along with the exploit of the protocol itself in its ability to mint a limitless amount of tokens.
Solution
MultiSwap’s architecture includes the following technical and business process security measures.
Bridge scope is limited to transfer and keeping track of the state of assets across Conflux and other networks. It does not have any interactive or operative control over the token contract
Bridge pool asset lock up is decentralized and diverted to either DEX liquidity such as Swappi and others or multi-sig safes owned by projects building on Conflux rather than the multichain protocol itself.
Problem #2 - Poor UX is hindering adoption
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 walkthrough 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 networks such as Conflux to drive TVL towards the ecosystem.
Solution
The UX of MultiSwap is geared towards novice users with step by step guidance. MultiSwap’s UX enables novice users to bridge and swap assets across networks without having to read a help article or watch a help video. At the same time, MultiSwap does not frustrate advanced users. Striking the balance in this UX implementation was key.
Problem #3 - Unauthorized wrapped assets pose significant security risks.
Not only do wrapped assets strip the native token of any of its previously embedded functionality such as reflections mechanisms, dividend tokens, etc but 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 tokens 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 create a faux market on DEXs.
Solution
MultiSwap uses bridgeable assets called Foundry Assets to support multichain swaps. Therefore, wrapped versions of these assets don’t need to exist on multiple networks in order for them to be liquid on said networks.
Problem #4 - Porting liquidity to new networks is difficult
Users have to use multiple Dapps in order to move liquidity between networks:
- 1st dApp: Origin Network DEX - Liquidate an asset using a DEX on the origin network into a bridgeable asset
- 2nd dApp: Bridge - bridge the asset to the desired network.
- 3rd dApp: Destination Network DEX - 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.
Solution
Nobody ever says “I’m going to bridge my USDC from Polygon to Conflux just to hold my USDC on Conflux.” Let’s face it, the only reason anyone ever wants to bridge an asset to another network is to liquidate it into something else. MultiSwap removes all of these layers of friction and allows the user to move and liquidate assets across networks using a single interface instead of multiple dApps.
TECHNICAL PROPOSAL
Overview
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. When assessing product development, we start with a series of “why” questions.
Why is a multi-chain aggregator needed?
Why aren’t other mult-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 review found that indeed there is an unfulfilled need for a secure cross-chain swapping platform in the market, one that conforms to the highest standards of security both 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.
- Bridge Pool
- General Tax Distributor
- Node Infrastructure
Bridge Pool
There are 2 things to setup in the BridgePool SC allowtarget and setFee.
- Go to the BridePool smart contract on the relevant networks explorer. e.g Testnet BSC Scan, Rinkeby Etherscan etc.
- Go to Write Contract and connect the admin wallet. Make sure you are on the correct network otherwise the wallet will not connect.
- Setting allowTarget. This needs to be set up for each pair that should be mapped to the token. For example, suppose you are setting the FRM token on BSC Testnet to be mapped to the FRM token on Rinkeby and Mumbai (Polygon) testnet. In that case, you will need to add the token contract information of the current network (BSC Testnet) FRM token and each destination token in two separate transactions.
- Go to allowTarget and add the following details to add the token.
- token (address)
- This is the Token Contract Address for the token you are adding on the current network.
- chainId (uint256)
- This is the chainId for the destination network of the Token Contract Address you are adding the mapping for. For example, if you are setting up the FRM Token in the BridgePool SC on Rinkeby to the FRM token on BSC Testnet then you would add the BSC Testnet chainId 97 here. Make sure to enter the correct chain chainId for the corresponding destination Token Contract Address.
- targetToken (address)
- This is the Token Contract Address for the token on the destination network. For example, if you are setting up the FRM Token in the BridgePool SC on Rinkeby to the FRM token on BSC Testnet then you would add the FRM BEP20 (BSC Testnet) Token Contract Address here.
- token (address)
- Write the transaction and proceed through the MetaMask Prompts. You can check the transaction status by clicking the View Transaction button.
- Repeat this process for each network you are mapping this token to.
- Setting setFee. This one is a lot simpler
- Go to setFee and add the following details to set the withdrawalFee for the token on the current network.
- token (address)
- This is the Token Contract Address for the token you are adding on the current network.
- fee10000 (uint256)
- This will be the percentage integer followed by two zeros. For example, if the fee is 1% then enter 100, if it’s 2% then enter 200.
- token (address)
- Write the transaction and proceed through the MetaMask Prompts. You can check the transaction status by clicking the View Transaction button.
- Now go to the other networks and repeat this process to complete the mapping. For example, if you have just completed mapping in BSC Testnet and you are mapping this token on Rinkeby and Mumbai (Polygon) Testnet as well then you will need to go and repeat this process on Rinkeby and Mumbai (Polygon) Testnet now.
General Tax Distributor
There are 2 things to setup in the GeneralTaxDistributor SC setTokenInfo and setTokenTargetInfos.
- Go to the GeneralTaxDistributor smart contract on the relevant networks explorer. e.g Testnet BSC Scan, Rinkeby Etherscan etc.
- Go to Write Contract and connect the admin wallet. Make sure you are on the correct network otherwise the wallet will not connect.
- Setting setTokenInfo. This needs only needs to be set up for the token contract on the current network.
- Go to setTokenInfo and add the following details to add the token to the GeneralTaxDistributor.
- token (address)
- This is the Token Contract Address for the token you are adding on the current network.
- bufferSize (uint256)
- Set this to 1.
- tokenSpecificConfig (uint8)
- Set this to 0x1.
- token (address)
- Write the transaction and proceed through the MetaMask Prompts. You can check the transaction status by clicking the View Transaction button.
- Setting setTokenTargetInfos.
- Go to setTokenTargetInfos and add the following details to configure the feeDistributionSplit for withdrawals of the token on the current network.
- token (address)
- This is the Token Contract Address for the token you are adding on the current network.
- infos (tuple[])
- This is a tuple is a list of addresses that will receive the fee distribtuion for this token. Use this format to add the list of addresses
- [[“ferrumFeeShareDistributionAddress”,2], [“clientFeeShareDistributionAddress”,2]]
- This is a tuple is a list of addresses that will receive the fee distribtuion for this token. Use this format to add the list of addresses
- weights (uint216)
- This is the distribution split. i.e. 50/50, 60/40 etc. You need to enter a uint216 hex here. Use this value for 50/50 splits
- 0x0808
- This is the distribution split. i.e. 50/50, 60/40 etc. You need to enter a uint216 hex here. Use this value for 50/50 splits
- token (address)
- Write the transaction and proceed through the MetaMask Prompts. You can check the transaction status by clicking the View Transaction button.
- Now go to the other networks and repeat this process to complete the mapping. For example, if you have just completed mapping in BSC Testnet and you are mapping this token on Rinkeby and Mumbai (Polygon) Testnet as well then you will need to go and repeat this process on Rinkeby and Mumbai (Polygon) Testnet now.
Node Infrastructure
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 Pocket Network, Algorand, Casper and more, 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 Pocket Network, 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.
Node Signing Architecture and Infrastructure v1.0.0
New Node Infrastructure
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:
Cloudcraft – Draw AWS diagrams
Node Signing Architecture and Infrastructure v2.0.0
Generator Node
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 depositted 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.
Validator Node
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 requet and not a spoofed request, the Validator Node adds it’s signature as a verfier 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.
Master Node
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.
MultiSwap Architecture Doc
There are many more features and components to MultiSwap. Please make sure to review the MultiSwap architecture document in its entirety. This document is quite comprehensive and is the best way to understand the product from the most holistic perspective.
https://docs.ferrumnetwork.io/ferrum-ecosystem/v/infinityswap-and-bridge-architecture-overview/
SYSTEM MODEL
Please review an example of the UX/UI here:
DEVELOPMENT ROADMAP
Milestones
Milestone #1:
Milestone Title:
Scoping and Defining Resources for Conflux Aggregator Integration
Milestone summary / objective:
Deadline will be 3 weeks post execution of the proposal
-
Scope out the integration of Conflux with the aggregator, including details about Bridge Pool setup on Conflux.
-
Determine if Conflux integration can also support multi-chain DEX based liquidity option for bridge liquidity or if a 2 way liquidity pool bridge with on-bridge liquidity is the only feasible option.
-
Define resources and work required to integrate and start integration.
At the completion of this milestone, we will be requesting payment for upcoming milestones to cover resource allocation and development cost.
Deliverables:
- Scope document for aggregator
Both documents need to enlist the risks and potential mitigatory and contingency measures against those defined risks. This will help us with early identification of blockers and possible solutions.
Milestone #2:
Deadline will be 67 days post execution of milestone 1
Milestone Title:
Build, Deploy, and Internally QA Bridging Shell App
Milestone summary / objective:
- Build and deploy a shell app that will allow swaps among:
- Conflux <> Ethereum
- Conflux <> BSC
- Conflux <> Polygon
- Conflux <> Avalanche
- Conflux <> Moonriver
- Conflux <> Harmony
- Conflux <> Shiden
- Conflux <> Other networks if integrated prior to milestone commencement
-
Integrate aggregator with one of the Conflux’s compatible wallets
-
Share Bridging shell app with internal QA and incorporate QA feedback
Deliverables:
- UI deployment for aggregator interaction
- Smart Contract Deployment of aggregator
- Conflux compatible wallet integration
- Ability to run swaps among:
- Conflux <> Ethereum
- Conflux <> BSC
- Conflux <> Polygon
- Conflux <> Avalanche
- Conflux <> Moonriver
- Conflux <> Harmony
- Conflux <> Shiden
- Conflux <> Other networks if integrated prior to milestone commencement
- Internal QA feedback incorporation
Milestone #3:
Deadline will be 45 days post execution of milestone 2
Milestone Title:
Testing by Conflux
Milestone summary / objective:
- Share tech with Conflux for testing and incorporate their feedback.
Conflux team will test the aggregator and provide their feedback / report bugs (if any). The feedback provided by Conflux will be reviewed by Ferrum team. Ferrum team will implement the mutually agreed upon feedback and share the product with Conflux to approve and sign off the milestone.
Deliverables:
- Conflux provides feedback
- Ferrum incorporates the mutually agreed upon feedback provided by Conflux
- Conflux signs off on shell app post their feedback incorporation
Milestone #4:
Deadline will be 30 days post execution of milestone 3
Milestone Title:
Multi-Chain Aggregator Mainnet deployment, testing and incorporation of final feedback
Milestone summary / objective:
- Deploy on mainnet
- Incorporate feedback
- Conduct internal testing
- Share the product with Conflux and incorporate the final feedback
Deliverables:
-Ability to conduct swaps across below networks with Conflux:
- Conflux <> Ethereum
- Conflux <> BSC
- Conflux<> Polygon
- Conflux <> Avalanche
- Conflux <> Moonriver
- Conflux <> Harmony
- Conflux <> Shiden
- Conflux <> Other networks if integrated prior to milestone commencement
- Able to add/remove liquidity on all networks
- Conflux signs off on mainnet testing
Milestone #5:
Deadline will be 15 days post execution of milestone 4
Milestone Title:
Incorporate feedback and launch - MultiSwap
Milestone summary / objective:
- Launching the product on production mainnet
Deliverables:
- Launch on production mainnet
- Product is live and available to users to swap tokens
Budget Breakdown
Goals
We are targeting $150 million in cumulative transacted volume across all integrated networks in the first quarter of operation and over $350 million over the first 2 quarters. We’re confident that we can achieve these numbers. The first iteration of this product - the Ferrum Cross Chain Token Bridge - has done 200 million in volume in 9 months and the only token bridgeable was our own; $FRM on chain A for $FRM on chain B.
Marketing Activities and Community Activations
Articles
At Ferrum, we believe that content is king. That’s why we will prepare a set of highly informative and engaging articles outlining the problems MultiSwap is solving. These articles will be the base of all of the next marketing and lead gen activities and they will focus on educating and inspiring our users and clients.
PR and Influencer Campaigns
We will run PR campaigns with our external agency to send out press releases and publish educational and technical content about MultiSwap on different crypto news sites. We’re currently working with Twitter and YouTube Influencers that will promote MultiSwap to their audiences. These campaigns will build up momentum for MultiSwap within a broader crypto community.
YouTube & Podcast Series
Before and after the launch of the MultiSwap, we will record a selection of videos explaining the product and the way it works. We then turn the videos into standalone podcast episodes for our series “Crypto at the Ferrum Roundtable” - these episodes are available to listen to on Spotify, Apple Podcasts, Google Podcasts, and more. Our podcast series has proven to be one of the best ways to grow our community and userbase organically.
Social Media & Lead Generation
We will also be utilizing all of our social media and community platforms to generate interest and promote MultiSwap. These include our following on Twitter, Facebook, Linkedin, Telegram, and Discord. This will be key to building engagement and hype within our community. We will also automate the lead generation process by optimizing Linkedin Sales Navigator and tools such as MeetAlfred to reach out to the highest quality of prospects, directing them to our MultiSwap demo calls.
Email Automation
On our Hubspot CMS, we will set up automated workflows with emails that will be regularly sent out to our vast database of email addresses and previously generated leads before and after the launch of MultiSwap. These emails will consist of both written and video content that will educate and build interest amongst our users.
AMA Sessions
Ferrum will also dedicate an AMA session on our Discord Server to answer all MultiSwap questions the community might have - and we will also turn this into a YouTube video and an episode of our podcast.
Website Promo
We will develop an updated landing page for MultiSwap on our website with the main call to action on the homepage to go and participate in the launch of our new product. On this page, users will be able to find all relevant articles, videos, and information regarding MultiSwap.
We will turn each of these individual pieces of MultiSwap promotional content into announcements for Telegram and Discord.
Sales Team
We have a team of around 5 sales and product representatives whose core responsibility is ensuring the usage of our products. They focus on inbound and outbound lead generation, integration consulting, and general support for projects leveraging our technology.
RESOURCES AND RELATIONSHIPS
Ferrum boasts a robust network of partners, clients and incubated projects across a wide array of sectors within the blockchain industry. These various entities make up the Ferrum Ecosystem – also known as the Iron Alliance!
Here you’ll find testimonials and a long list of high caliber projects who have been by Ferrum’s side throughout our journey.
We’ve never seen so much widespread attention being paid by all the major L1s to a single product. This alone is extremely validating that we’re on the right track to achieve Interoperability 2.0. With relationships and support from the likes of Avalanche, Polygon, Algorand, Harmony, Pocket Network, Moonriver, Casper, Shiden, Velas, Fuse and others, MultiSwap is poised to become the most interoperable protocol on the market and will surely add value to any network who decides to integrate with it.
MAINTENANCE CONSIDERATIONS
Ferrum is responsible for maintenance of the product primarily. We have an integration team that is dedicated to the maintenance, and enhancement of MultiSwap across networks.
We will also be open sourcing a lot of our tooling and infrastructure so the open source community can also contribute to improvements over time. However, we will remain the maintainers of the project throughout its lifecycle.