4th July Update

Here is an update on Quant Fusion's public release progress as of the 4th July 2025.

Introduction

Quant has a strong vision on what the public version of Quant Fusion will be, and we have a clear technical roadmap on how to get there - some of that information can be found in these developer documentation pages. That said, our implementation plan is agile and open to feedback. Hence we are happy to provide updates, which will allow for wider feedback to be gathered.

Where to provide feedback?

There are multiple places for you to provide feedback. For private feedback, including if you are looking to build on Fusion, contact us via https://quant.network/contact/

For public feedback on x.com, use the hashtag #QuantFusion and tag @OverledgerDev, then your feedback will be read when possible.

4th July Update

The following is not a complete list of Fusion activity completed so far. It instead should be viewed as a summary of the highlights.

It was a great start to the week, with Fusion's Multi-Ledger Rollup devnet launched. Our Implementation contracts were deployed on Monday to the 3 declared testnets (Ethereum Sepolia, Polygon Amoy, Avalanche Fuji).

Completion of this deployment led to our first key decision point:

Decision Point: Should we publicly publish our smart contract addresses and transactions immediately?

For: it will increase transparency.

Against: we will be publicly analysed in real time. Analysers will be guessing why each transaction is performed - potentially forcing us to respond, which would in turn divert our time and focus from implementation testing.

Decision: We will log all addresses and timestamp transactions. Retrospectively we will publish a summary of them with commentary. Why? Because this will minimise speculation and keep the developers and testers focused on the implementation testing goals. Therefore, transparency will be achieved by continually publishing documentation updates, devnet updates (like this one) and later by publishing the onchain transaction information with a summary.

On Wednesday we published our upgradeable proxy contracts to attach to the implementation contracts launched on Monday. From Monday onwards, transaction testing proceeded via stimulated transactions using the Foundry development toolkit, firstly with the implementation contracts only, and secondly with also the upgradeable proxy contracts. Why stimulated transactions? Because it allowed us to run a high amount of transaction tests without having to consider topping up and rebalancing addresses.

The testing of the implementation and upgradeable proxy contracts led to our second key decision point:

Decision Point: Should the devnet utilise the implementation contracts only or proceed with the upgradeable contract versions?

For (upgradeable contracts): Provides the ability to change the functionality later.

Against (upgradeable contracts): Introduces a potential centralisation point.

Decision: For the devnet only, where rapid testing is required (and potentially agile development in response to testing is also required), it makes sense to allow for upgradeability. I.e. in Devnet, the features are the key focus.

And of course there is a related decision point:

Decision Point: Should the testnet and mainnet utilise the implementation contracts only or proceed with the upgradeable contract versions?

For (upgradeable contracts): Provides the ability to change the functionality later.

Against (upgradeable contracts): Introduces a potential centralisation point.

Decision: Decision deferred. The mainnet needs to maintain maximum security. The testnet has more flexibility but should reflect the mainnet as much as possible. At least four possibilities warrant further careful deliberation and measured reasoning: (1) upgradeable contracts attached to the implementation contracts; (2) implementation contracts only - 1 version for each chain; (3) implementation contracts only - multiple possible versions for each chain; (4) upgradeable contracts attached to the implementation contracts - upgrades are managed through a governance token, potentially aligned to QNT staking.

Option notes:

(1) is the most centralised. It can be implementable via a threshold signature scheme.

(2) is as decentralised as possible. But will never allow feature upgrades to the layer 1 rollup deposit smart contracts.

(3) will allow upgrades. Each chain would start with one implementation contract. If an upgrade is required an implementation v2 contract will be published. Fusion users will be directed to the v2 contract but can choose to use the v1 contract if desired. Option (3) is only possible due to our multi-ledger rollup technology (i.e. having multiple implementation contracts on the same chain is technically very similar to having multiple implementation contracts on multiple connected chains). But a potential negative is continued support for the older version on each chain - at least until all the users have stopping using the previous version. We expect option (3) to be decentralised, assuming the logic of onboarding a new deposit contract is not manipulable - to be investigated.

(4) utilising a governance token can remove most of the centralisation concerns. And utilising QNT staking to do so would align with the in progress Fusion roadmap. But it potentially adds technical complexity to our staking roadmap - to be investigated.

Other highlights include:

• Progress on the Multi-Ledger Rollup sequencer APIs and the sequencer ETH JSON RPC. Both were tested for integration with Quant Connect clientIds. The testing has passed, paving the way for users to access the Multi-Ledger Rollup in an authorised manner.
• Our chosen Decentralised Exchange (DEX) was deployed. We are satisfied with our selection. But an official announcement will be made later on the specific DEX to be used.
• Progress on the Network of Network's open source specification. We are currently making sure that the specification will allow for a Fusion user to utilise one service to connect multiple networks of the same blockchain technology. This will increase technical scalability while also minimising maintenance costs (for whoever is running the connector, either Quant or a Fusion user).

Next Steps

• Continue stimulated and onchain transaction testing for our Multi-Ledger Rollup devnet, moving onto focusing on the deposit functionality.
• The user interface to sequencer testing begins.
• Sequencer permissioning and access control testing begins.
• Now that the DEX has been selected, we move onto considering other initial smart contracts to whitelist for public use on our Multi-Ledger Rollup.
• Reconsidering whether to deploy the Multi-Ledger Rollup testnet as a traditional testnet (where the network has no value) or as a "Canary Network" (where the network is pre-production with smaller value - think Kusama when compared to Polkadot). Why? Testnets are occasionally unstable and also sourcing testnet native coins (e.g. testnet versions of ETH, AVAX, POL,...) can be a bit of a pain as these tokens are effectively illiquid. We will most likely still aim for a traditional testnet but it is worth a reconsideration.
• Continue with preparing the Network of Networks "Bring Your Own Node (BYON)", "Bring Your Own Connector (BYOC)" and "Open Source Connector Specification" features for public release
• ...and so much more!

Where is your feedback?

We re-emphasize to any reader than we encourage your feedback. Quant Fusion is an ecosystem that will rapidly expand in accordance to its users. So help us steer this infrastructure to perfection!