13th August Update
Here is another update on Quant Fusion's public release progress, as of the 13th August 2025.
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.
13th August 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.
Fusion activities continue at pace.
We firstly cover our work regarding the "Open Source Connector" specification. This has been trialled very successfully. Within days of releasing the specification, connectors for EVM, Hedera and SUI had been built.
We have made the specification as simple as possible to ease the developer experience. We had a related decision point to make regarding this specification:
Decision Point: Should our "Open Source Connector" Specification be built for Quant's DLT agnostic data model, blockchain specific data models, or both?
Arguments for using Quant's DLT agnostic data model: A DLT agnostic data model allows for ease of interoperability between the different blockchains. It also allows apps to be redeployed from one chain to another in a very simple manner.
Argument for using each blockchain's specific data model: In this case it is easier to leverage third party tools built specifically for that blockchain.
Decision: Quant Fusion will support both, allowing all the benefits of each data model.
The next step for this work stream is to finalise the automated method to embed user created connectors into Fusion. The user flow for this will be the following:
- The user builds a new connector according to Quant's "Open Source Connector Specification"
- The user will login to Quant Connect, configure some parameters (e.g. the URL of the connector)
- Fusion runs some automated tests on this connector (e.g. to test the responsiveness)
- If the automated tests pass, then
- the connector will be immediately integrated to the Fusion ecosystem
- the connector will start at the "private" access level (available only for this user) but can be promoted to "permissioned" or "public" access afterwards
Given the above decision point - that Fusion will support also native blockchain data models - we considered which of the eth JSON RPC's will be made available for our Multi-Ledger Rollup (while enforcing the permissioning system described in previous updates). The current implementation allows for:
| Method | Access Type | Notes |
|---|---|---|
| eth_blockNumber | ✅ Accessible | Returns current block height. |
| eth_call | 🔐 Permissioned | The following must hold: if the from parameter is provided then it must be associated to an account this user owns; and if the providedto parameter is a contract address, then it must be restricted to contracts this user can access. |
| eth_chainId | ✅ Accessible | Used to identify the chain ID for tx signing. |
| eth_estimateGas | 🔐 Permissioned | The following must hold: if the from parameter is provided then it must be associated to an account this user owns; and if the providedto parameter is a contract address, then it must be restricted to contracts this user can access. |
| eth_feeHistory | ✅ Accessible | Allows transaction fee analysis |
| eth_gasPrice | ✅ Accessible | This RPC only returns the current gas price of the network |
| eth_getBalance | 🔐 Permissioned | The provided address parameter must be set to an account that this user owns or set to a smart contract this user can access. |
| eth_getBlockByHash | 🔐 Permissioned | The transactions array will show only transactions that satisfy either: the transaction'sto or from parameters are set to one of the user's accounts; or the transaction's to parameter is set to a smart contract that the user can access |
| eth_getBlockByNumber | 🔐 Permissioned | The transactions array will show only transactions that satisfy either: the transaction'sto or from parameters are set to one of the user's accounts; or the transaction's to parameter is set to a smart contract that the user can access |
| eth_getBlockReceipts | 🔐 Permissioned | The returned array will show only logs from transactions that satisfy either: the transaction's to or from parameters are set to one of the user's accounts; or the transaction's to parameter is set to a smart contract that the user can access |
| eth_getCode | 🔐 Permissioned | If theaddress parameter is set to a smart contract address, then it must be restricted to a smart contract that this user can access. |
| eth_getProof | 🔐 Permissioned | The address parameter provided must be either: set to an account that this user owns; or set to a smart contract that this user can access |
| eth_getStorageAt | 🔐 Permissioned | The address must be restricted to contracts this user can access. |
| eth_getTransactionByBlockHashAndIndex | 🔐 Permissioned | The transaction is returned only if either: the transaction'sto or from parameters are set to one of the user's accounts; or the to parameter is set to a smart contract that the user can access |
| eth_getTransactionByBlockNumberAndIndex | 🔐 Permissioned | The transaction is returned only if either: the transaction'sto or from parameters are set to one of the user's accounts; or the to parameter is set to a smart contract that the user can access |
| eth_getTransactionByHash | 🔐 Permissioned | The transaction is returned only if either: the transaction'sto or from parameters are set to one of the user's accounts; or the to parameter is set to a smart contract that the user can access |
| eth_getTransactionCount | 🔐 Permissioned | The address parameter must be set to an account that this user owns |
| eth_getTransactionReceipt | 🔐 Permissioned | The object is returned if the associated transaction object satisfies one of the following: the to or from parameters are set to one of the user's accounts; or the to parameter is set to a smart contract that the user can access |
| eth_maxPriorityFeePerGas | ✅ Accessible | helps with transaction fees |
| eth_protocolVersion | ✅ Accessible | Provides metadata only |
| eth_sendRawTransaction | 🔐 Permissioned | The raw transaction needs to be decoded firstly. Then the transaction object will be considered. Firstly the transaction'sfrom parameter is added to the user's list of owned accounts (if it hasn't been added already). Next, if the transaction'sto parameter is a contract address, then it must be restricted to contracts this user can access. If to is null (because this transaction is a contract deployment), then the transaction is allowed and the deployed smart contract is assigned initially to the private access state for this particular user. |
| eth_syncing | ✅ Accessible | Indicates node sync status. |
Next Steps
We continue Quant Fusion development and testing for both the Multi-Ledger Rollup and Network of Networks sections. Further updates will be provided when appropriate.
Updated 3 days ago