By Andre Cronje

Consider the Ethereum code base. The Ethereum code base has been used to run a lot of different mainnets & testnets. For simplicity sake and as not to mention any other projects, let’s assume testnets are mainnets for this explanation.

The Ethereum code base is used to run the Ethereum Mainnet.

The Ethereum code base is also used to run the Ropsten Mainnet (testnet).

The Ethereum code base is also used to run the Rinkeby Mainnet (testnet).

Same code, but different Mainnets. What you do on Ropsten is not reflected on Rinkeby and vice versa. But all of them are fueled by ETH.

Next consider an ERC20 token. Token ABC’s smart contract is independent of Token XYZ’s smart contract. Token ABC does not need to know or interact with XYZ. Both contracts are fueled by ETH.

Next let’s look at traditional architecture. Uber runs on hardware and servers provided, commissioned, and managed by Uber. Facebook runs on hardware and servers provided, commissioned, and managed by Facebook. Consider if all software in the world ran on a single set of servers. What do you predict the performance would be?

Fantom has two components. Fantom consensus, characterized by Lachesis and Txflow, and the FTM token, which has economic value and in a Proof of Stake solution, economic security.

Dapps on Ethereum are usually smart contracts. An ERC20 token is a Dapp. Dapps in the Fantom network are their own mainnets, run on their own validators, with their own tokenomics.

A dapp developer designs their product, this product runs on Fantom architecture & consensus and is fueled by the FTM token.

For simplicity sake, let’s assume the first dapp is a game of chess. The dapp developer builds the game of chess and makes the software to run the game publicly available. The dapp developer would like validators to run the network and would like to secure the network against attacks via economic incentive (Proof of Stake). The dapp developers needs to acquire FTM tokens and fuel the network (SPV) with the tokens as reward. This is their opex cost to run the network (just like you would pay for servers / software licenses to host the application).

This is a network in it’s own, run by it’s own unique validators, run on Fantom consensus software. If another developer also wishes to develop a game of chess, they would do it on their own network with their own validators fueled by their own FTM supply.

This is what is meant by mainnets. Instead of each bespoke product running on the same hardware, instead each runs on their own implementation which is product specific. An economic incentive system might require 100+ nodes for security, while a simplistic game might only need 3 nodes for availability and recovery. This is up to the product developer / designer to decide for themselves.

The first mainnet is built by its own team, with their own product, with their own product vertical, on-top of Fantom consensus, given economic security by the FTM token.

The onus is on each mainnet to design their tokenomics in such a way that is value centric and economic to their ecosystem. A non profit system does not need absolute security and might only need to reward validators with a few FTM over a year because the validators themselves host the network for non profit reasons. A economic mainnet that can facilitate economic value or revenue would need a substantial amount of economic security to reward their validators.

This creates a fluid system where validators can join / leave a given network for higher yield / reward and where low yield networks will have economic death as they can no longer sustain. (This is where dynamic participation comes into play, being able to freely join and leave the network without causing large interruptions is essential for this to work.)

So unique mainnets, for unique products and projects, responsiveness and scalability provided via the Fantom consensus stack, and security provided via the FTM token.