Architecture

The following diagrams display how Fusion's Multi-Ledger Rollup and Network of Networks sections interact. At a high level, the interaction between the different layers can be shown via the following diagram:

Note that the referenced blockchains and distributed ledger technology (DLT) networks in the diagram are shown as examples, and not as a commitment to be supported from the initial public launch - but Fusion's design enables any to be supported either by Quant directly, or via Fusion's "bring your own connector" feature for users

Why is Fusion referred to as a Layer 2.5? Well as you can see from the previous diagram, both the Multi-Ledger Rollup and Network of Networks sections are designed to sit above public layer 1 blockchains, public layer 2s (blockchains or otherwise) and also permissioned DLT networks. Hence the newly created Layer 2.5.

In order to look into the architecture in more detail, we firstly introduce some background information on Fusion's Network of Networks:

• DLT Agnostic APIs: These APIs present the same request and responses to the user regardless of what specific distributed ledger technology and network is being interacted with. Users of Overledger will be familiar with this concept, as Overledger has always provided this type of APIs.
• User Configuration APIs: Fusion also offers a variety of APIs regarding user configuration. For example, APIs to: (a) connect user nodes to Fusion; (b) connect new blockchains to Fusion; (c) set access control permissions for their API keys, blockchain accounts, nodes, or connectors; (c) deposit QNT, stake QNT or withdraw QNT rewards; and so on
• Access Controls: All requests to the DLT agnostic APIs must pass the access controls set by the request sending user, along with other relevant users (e.g. if you are requesting to use a blockchain connected to Fusion by Alice, then Alice needs to have set her permissions in order to enable this)
• Node and Connector Layer: handles the routing of the request to the relevant node(s), and is responsible for returning one result to the requesting user, which can in certain circumstances be some type of combination of responses from the queried node (e.g. asking 5 nodes what is the optimal current gas price might return 5 different valid answers, which can be averaged out before returned)

Secondly, we introduce some background information on Fusion's Multi-Ledger Rollup:

• Sequencer: See the Multi-Ledger Rollup architecture page for more detail about the internals of the sequencer.
• Consensus node: Leverages the Fusion connected nodes and connected networks. The more networks connected, the more the Multi-Ledger Rollup can expand.
• Virtual machine node: Responsible for tracking the Multi-Ledger Rollup state, including all the smart contracts deployed and the transactions that have been performed. It is accessible to Fusion users via direct ETH JSON RPC calls (via the sequencer) and via requests to Fusion's DLT agnostic APIs.

Some additional diagram explanations:

Quant supports some distributed ledger / blockchain technologies via connectors that they themselves run. Each technology (e.g. Ethereum Virtual Machine) can be implemented in multiple networks (e.g. Ethereum mainnet, Polygon mainnet, Avalanche c-chain,...). Therefore there are also a variety of distributed ledger / blockchain networks that Quant support.

If Quant supports a particular network, then Fusion users can utilise Quant's nodes for this network, as well as connect their own nodes for this network in order to provide additional resilience (node distribution) to the Fusion system.

If Quant supports a particular technology but not a particular network, then a Fusion user Bob can connect their node(s) for this network automatically after Bob provides some particular information about this network (e.g. network name). By default, a new network will be private to Bob, but this network can be promoted to permissioned access (users whitelisted by Bob can access the network) automatically, and can be promoted to public (any Fusion user can access the network) after review by the Quant team.

Finally, if Quant does not support a particular technology themselves, any user can still integrate this technology to Fusion via utilising Fusion's "bring your own connector" feature. Once the connector is integrated, the users nodes for this network can also be integrated.