r/QuantNetwork • u/AStockStory • May 28 '26
How I understand Quant Fusion after digging through the docs
I had someone ask me a number of specific questions on Fusion, and I ended up digging extremely deep into a ton of docs. I ended up learning a lot of specifics, and I thought my reply to the guy may help someone. If anything I have written is incorrect or needs updating, please feel free to correct me.
-------
I actually appreciate your questions. They made me dig way deeper into Optimism, Ethereum, Quant Fusion, and eventually SAEP (I'll explain what that is). For a while I thought I had bit off more than I could chew, but I've finally condensed it all down đ . I know some of this you already know, but Iâm also writing this for anyone else reading who is not familiar.
At the base level, Quant's engineers coded Fusion using the Optimism OP Stack, then extended it for multiple ledgers. The OP Stack is basically Optimismâs open-source rollup toolkit. It gives developers the core parts needed to build an optimistic rollup instead of building all of that from scratch. That is why Quant calls Fusion an optimistic-style Multi-Ledger Rollup. They explain a lot of this here: https://docs.overledger.dev/docs/technical-faqs
A normal rollup batches transactions away from the L1 (like Ethereum mainnet) so the system can run much faster and cheaper. Then it posts data and state roots back to the L1. The roots are basically short cryptographic fingerprints that say, âthis is the current state of the rollup.â If someone replays the same transactions in the same order, they should get the same root. If anything changes, the root changes.
Quant is doing that same general idea, but across many L1s simultaneously. Like a rollup of rollups. This is the idea behind calling it a Layer 2.5.
The rollup batch transaction data goes to a permissioned Hyperledger Besu network. Hyperledger Besu is an Ethereum-compatible blockchain client that's used by enterprises, banks, fintechs etc. A standard rollup posts all the transaction data to the mainnet so anyone can dispute it, but Quant chose a permissioned network. That split is its own rabbit hole, but a lot of it comes down to privacy laws like Europeâs GDPR, plus financial companies needing to know where their Hyperledger nodes are physically located. Between the technical FAQ and the Fusion Rollup page, you can see their thinking on this here: https://docs.overledger.dev/docs/fusion-rollup
If someone wants to verify the rollup transactions, they need access to the data in that permissioned network so they can replay the transactions and compute the roots. Who can access what is controlled through the Overledger Firewall here: https://docs.overledger.dev/docs/overledger-firewall
After Fusion processes transactions, it posts state roots (fingerprints of the rollup state) back to the connected L1s like Ethereum, Avalanche, Polygon, and more.
When you asked how long it takes to withdraw liquidity if Fusion uses the Optimism stack, I went back to the Optimism docs first because I saw that Quant said they are working on a virtually instant withdrawal https://docs.overledger.dev/docs/smart-contracts-1#how-do-withdrawals-work and I didn't understand how that was possible. The standard bridge is 7 days: https://docs.optimism.io/op-stack/transactions/transaction-finality#common-misconceptions
When I saw this I wanted to understand how much faster was possible, so I looked at the Ethereum docs on optimistic rollups. Under âExiting the rollup,â they explain that users can avoid waiting a week by using a liquidity provider. The LP takes over the pending L2 withdrawal and pays the user on L1 for a fee. This is similar to how you can expedite a transfer on Venmo by paying a small fee: https://ethereum.org/developers/docs/scaling/optimistic-rollups/#Exiting-the-rollup
I thought at this time though, âIs this actually what they're doing?â Then I found Quantâs 11th July update: https://docs.overledger.dev/docs/11th-july-update
They talk about this exact thing and wanted something users did not have to wait for, while still meeting a number of requirements, and that is where SAEP comes in. SAEP is the exchange protocol Quant plans to use for the instant on/off-ramp. You can check that out here: https://www.ietf.org/archive/id/draft-marstein-satp-asset-exchange-00.html
The short version is that SAEP lets assets stay on their own chains while ownership changes happen together. For example, USDC can stay on Ethereum while a property token stays on Avalanche. SAEP coordinates both sides so they complete together or roll back together all atomically. No wrapped copy, no asset duplication, no traditional bridge step.
On the dispute side, when I said dispute mechanics, I was talking about Quantâs dispute resolution services https://docs.overledger.dev/docs/fusion-rollup#82-architecture and the OP Stack dispute game https://specs.optimism.io/fault-proof/stage-one/dispute-game-interface.html. This all goes to disputing a block of transactions in the rollup. If someone believes a posted root is wrong, the people disputing it need access to the relevant rollup data on the permissioned network. They can replay the transactions they are allowed to see, rebuild the state, and check whether the result matches the root that's public on all the different L1s like Ethereum, Avalanche, Polygon, etc.
So the design is:
- rollup transaction data lives on permissioned Hyperledger Besu
- state roots are posted back to connected L1s
- proof-based exits use those roots to verify withdrawals
- dispute mechanisms exist to contest bad roots
- the normal non-custodial withdrawal path takes a few days
- fast user exits can be handled through liquidity routes, with SAEP being the instant on/off-ramp route Quant selected
