Home RSS

Ferrum Network
Crosschain Decentralized Network and Exchange
lead image

Ferrum is a DAG network offering interoperability with other networks, and includes a DEX, mobile wallet, and fiat on-ramp.

  • Directed acyclic graph (DAG) forked from IOTA (the extent of changes is described in the Code section below)
  • Interoperable: Ferrum can create “Proxy Tokens”, wrapped versions of other digital assets that can be transacted on chain. Will support derivatives.
  • Ferrum DEX
  • FRM coin is used as gas on the network
  • Wallet and Mobile wallet

One Pager:
Press Releases:

Token metrics

(from one pager)

Token Ticket: FRM
Token Price: $0.0168
Hardcap: $6,000,000
For Sale: 40%
Post-ICO valuation: $15MM

Market opportunity/Competitive analysis

There are countless DLT projects that claim to be performant and support tokens/other asset classes. However, they are all struggling to get adoption and usage. While Ferrum is newer and has less exposure to the market, most existing competitors are not far ahead.



  • Executive team:
    • Naiem Yeganeh (CEO) (github link)
      • Core Machine Learning Engineer at Bloomberg, (2017 - present)
      • Software Engineer at Amazon, (3 years)
      • Software Engineer at Microsoft 343 Industries with Halo Team, (7 months)
      • Senior Developer at Schneider Electric (2011 - 2013)
      • PhD, Computer Science (Distributed Database Systems and Data Quality Management) at The University of Queensland, (2007 - 2013)
      • MS, Computer Software Engineering at IAU Quazvin, (2004 - 2006)
    • Ian Friend (COO)
      • Associate and Co-Founder of Wilson Elser Blockchain and Digital Assets Practice Team, (2017 - 2018)
      • Associate Attorney at several legal firms
      • JD Business Law, Graduated Cum Laude at New York Law School, (2009 - 2012)
    • Pokey Rule (Software Engineer) (github link)
      • Software Engineer at OptumSoft, (2007 - 2011)
      • MS in CS at Stanford University, (2009-2014)
      • BS Mathematics and CS at Stanford Unversity, (2005 - 2009)
    • Hadjar Homaei (Product Engineer) (github link)
      • Director of Area 51 at Microsoft, (2018 - Present)
      • CEO/Co-Founder of Teela technology startup, (2016 - 2018)
      • Product Development Lead at Cody Inc, (2014 - 2016)
      • Software Development Engineer at Amazon with Similarities Team, (2011 - 2014)
      • PhD ‘11, Computer Science and Cognitive Science, All but dissertation, at University of Colorado Boulder (2006 - 2011)
    • Afshin Abadi (Quantitative Researcher)
      • Lead Data Scientist at Dropoffmap LLC, (2017 - 2018)
      • Data Scientist & Algorithms at PathSence Inc., (2016 - 2017)
      • PhD ‘14, Electrical Engineering/Machine Learning at University of Southern Carolina
    • Erik Powers (Financial Strategist)
      • Associate at The Blackstone Group
      • Analyst and Associate at The Blackstone Group
      • Associate and Officer at State Street, (2011 - 2014)
      • BA, Economics at Boston University, (2005 - 2009)
    • Benjamin Blatt (Investor)
      • Head of Capital Markets at Pagaya Investments, (2017 - Present)
      • Capital Markets Manager at, (2017 - 2017)
      • Principal Credit Analyst at Capital One, (2016 - 2017)
      • Director of Structured Credit at Aviation Finance Corporation, (2012 - 2016)
    • Huy Kieu (Lead Comunity Manager and Marketing Strategist)
      • Business Development Associate at Token Research Group, (2018- Present)
      • Lead Community Manager at Ankr Network, (2018 - Present)


Anton Uvarov: Senior Strategic Advisor
Etiënne VantKruys: Senior Advisor
Emeka Enu: Marketing and Business Development
Germaine Ifudu: Senior Blockchain Advisor
Hamed Ahmadi: Senior Engineer and Product Lead


Kudi Exchange: fiat to digital asset exchange for West Africa. Owned and operated by TLG Ventures, a strategic investor in Ferrum. More details here.

Strategic Investors

Kosmos Capital: Well connected in the Australian market
Token Research Group
TLG Ventures: Well connected in African market

Competitive Advantage

Most other projects depend on external exchanges for listing, and do not have direct fiat onramps. Ferrum has 4 planned methods:

  • XRP as intermediary
  • direct integration in various locales
  • in-house fiat gateway
  • Kudi Exchange


Every Ferrum transaction needs to present a proof of work.

[Users can] add weight to their transactions by spending FRM instead of, or in addition to, proof of work.

When FRM is used to execute a transaction, the token is burned.

– whitepaper

The tokenomics seem pretty simple - a twist on the standard PoW. However, I’m not sure how a proof of work can be bundled with a transaction.



From the README,

This repo contains gateways that are used by the Ferrum Node to talk to outside world. This is to help unifying the APIs both for wallet and node use.

Currently, only a Ripple gateway has been developed. Written in Typescript, the code liberally uses the newer features of Javascript such as classes and async/await.


Filename Description
model/RestApiTypes.ts Type definitions
App.ts Starts expressjs application with handlers for a generic command API: create new address, get transaction by id, and get incoming transaction. The actual functions are implemented in RippleApi.ts.
RippleApi.ts Connects to a Ripple server and does some data normalization to something more universal (for future support of additional networks).
index.ts Starts nodejs server on a specified port. Bootstraps App.ts

The main concern I have with this design is that it provides a single point of failure, in the following code (within RippleApi.ts):


This is Naiem’s response:


More explanations at the end of the review.


Ferrum-node has 30 commits since forking IOTA v1.4.2.2 from Feb 24, 2018.


As you can see, there have been 2 stages of development - no-ternary, and prior. To give some background, IOTA was designed with a balanced ternary system rather than binary. While theoretically, a balanced ternary system might be more energy efficient, in reality, the specialized hardware it takes makes it a much more fragile ecosystem. It looks like Ferrum has decided against IOTA’s decision to use a balanced ternary system, and gone back to traditional binary. In the no-ternary branch, the hashing function, encryption algorithm, and serialization / deserialization model are changed, making it compatible to Ethereum.

Here are the stats of the no-ternary branch:


As a result of the first command, you can see the number of file changes, and the number of lines added and deleted.

As a result of the second command, you can see the distribution of the changes. Since src/main/java/com/iota/iri/model/ and src/main/java/com/iota/iri/hash/ have the most changes, let’s see which files actually changed:


In the results, the first column is additions, and the second column is deletions. Looks reasonable – a quick double check of the files shows that most of the hashing functions have been replaced by very commonly used Keccak Sponge functions.

Here are the stats of the ferrum branch (the changes between forking from IOTA and the no-ternary branch above)


The biggest changes are adding the Ferrum specific files as highlighted in the picture above, and modifying the other files to be compatible. You may notice that src/main/java/com/iota/iri/service/ also seems to have many changes, but checking the actual difference in the code, it looks like mostly whitespace changes rather than functionality changes. is an architecture doc and todo list.

The files that end with look good to me. I’m not very familiar with IOTA bundles, but taking a look at the Bundles documentation, they look like reasonable implementations.

The and might have some issues. Take a look at the hardcoded BASE_URL below:


It could be a potential source of vulnerability due to the complexity of the oracle problem.

Edit, based on team response:

These two were the original design. They are being moved to the gateway nodes such as Ripple

More explanations are at the end of the review.

Another file that is a work in progress is, where it’s still a hardcoded list.



Javascript/Typescript API for Ferrum. There is a no-ternary branch to complement the no-ternary branch of Ferrum-node. The files below contain handlers for all the endpoints.


This repo does not include tests yet, but as just an interface to the Ferrum network, it’s not super critical at this stage.


Web wallet for Ferrum. Made with React. Contains functionality for the following features:



React native Ferrum wallet for Android / iOS. Contains functionality for the following features:



Uses docker-compose to set up ferrum, dex, dex bot, and gateway-ripple. Seems outdated due to the mismatching repo names to what is available, but it’s just a config file that can be updated in 5 minutes so not a big deal.


A proof of concept of sub-0 client. React native app.


Ferrum is competing in a tough space technologically, but differentiates itself by demonstrating good business development progress and onboarding advisors that can actually help in terms of adoption in geographically diverse locales.

The code is architected in such a way that demonstrates Naiem’s engineering experience. While it should be cleaned up and made developer friendly at some point, the team has made it clear that it’s pre-release. The git commit messages are clear and concise, which is a good sign that there was some time spent on making the codebaseo maintainable long term.

It is interesting to note that all the git commits are by Naiem, the CEO (this may be due to git rebasing, so not much insight here).

Other Info

Naiem Yeganeh | Ferrum Network, [Dec 4, 2018 at 5:31:13 AM]:

…The external data is not pushed to Ferum by oracles. Every single node connects to random external nodes. This will be effectively as every Ferrum node is also a node from all external nodes. E.g. Once you run a Ferrum node, you run an Ethereum, Ripple, Bitcoin, etc node with it that Ferrum talks to.

Naiem Yeganeh | Ferrum Network, [Dec 4, 2018 at 5:40:00 AM]:

Obviously this would be too expensive and not everybody will do that, although is an option and can be done. To take the specific example of Bitcoin, assuming there is 1000 Ferrum Node, they would be connected to 1000 different Bitcoin nodes. For an adversary to present a fake transaction, it should hack a significant percent of the Bitcoin nodes that Ferrum nodes connect to. Another problem that adversay has is that it doesn’t know which Bitcoin nodes are used by Ferrum nodes so the adversary should hack majority of the Bitcoin network to be able to fool Ferrum nodes to get a fake transaction through.