Most people who think about blockchain liquidity think about it the wrong way. They imagine money sitting in a pool, waiting like water in a tank. Move it from one tank to another, and both tanks notice. The problem is obvious: tanks don’t talk to each other in real time. You drain one before the other fills. That gap however small is where things break.
Fogo was designed with this gap in mind. Not the gap between chains, but the gap between execution environments on the same chain. That distinction sounds subtle, but it’s the entire point.
What the Mechanism Is
Fogo runs on the Solana Virtual Machine, but it doesn’t stop there. The architecture is built to host multiple execution runtimes SVM, EVM, and potentially others operating simultaneously on the same underlying ledger. Each runtime processes transactions in its own language, with its own rules. But here’s the unusual part: they all share a single state layer beneath them.
This shared state is where liquidity lives. Not inside any one runtime. Not assigned to any one virtual machine. The tokens, the balances, the positions they exist at a level that sits below the runtimes, accessible to all of them.
Cross-VM liquidity routing is the mechanism that allows a liquidity pool to serve a trade initiated in EVM and a trade initiated in SVM simultaneously, from the same pool without either side knowing the other exists.
How It Works in Real Conditions
Imagine a trader using a Solana-native DEX built on Fogo’s SVM environment. They want to swap Token A for Token B. Separately, a developer’s EVM smart contract is also trying to route through the same Token B liquidity. Both requests hit the network at roughly the same time.
In a traditional multi-chain setup, these two requests would go to separate liquidity pools one on each chain and you’d end up with fragmented depth, worse prices, and more slippage for both traders. In a cross-chain bridge setup, one side would have to wait while the other settled, introducing latency and bridge risk.
On Fogo, both requests are routed to the same underlying liquidity position. The state is coherent meaning the system has one unified picture of what’s available and the router resolves both claims against that single source of truth. The settlement happens at the base layer. Neither runtime “wins” over the other. They both draw from the same pool, and the pool’s state updates once, atomically, after both are accounted for.
This is what “state-coherent” means here. It’s not just about sharing tokens it’s about sharing knowledge of current state across runtimes in a way that prevents double-counting, race conditions, or stale reads.
When It Activates
The routing mechanism is always active in the background, but it becomes meaningful and visible when liquidity demand comes from more than one runtime simultaneously. A purely SVM-native environment with no EVM activity wouldn’t stress-test this system at all. The mechanism earns its design when the network becomes genuinely multi-runtime: when DeFi protocols built in Solidity and programs built in Rust are both competing for the same pool depth at the same block.
At 40-millisecond block times, this isn’t theoretical. Two requests arriving within a single block from different runtimes is a realistic, frequent condition. The system has to resolve them correctly every time not most of the time.
Why It Was Designed This Way
The conventional answer to cross-environment liquidity is bridging. Build a bridge between environments, and liquidity can theoretically flow between them. But bridges introduce a fundamental problem: they create two representations of the same asset. One on each side. Which one is real? Which one is current? When both sides update, something has to reconcile them, and that reconciliation takes time.
Fogo’s designers former practitioners from institutional finance, where settlement coherence is not optional likely recognized that bridges introduce additional reconciliation layers — and that the problem wasn’t speed or security alone, but the existence of dual-state representation itself. The answer wasn’t a better bridge. It was eliminating the need for one entirely by making the state layer singular from the start.
If every runtime writes to and reads from the same state, there’s nothing to reconcile. There’s only one ledger. The runtimes are interfaces, not separate systems. This is a fundamentally different architectural choice, and it’s one that has downstream consequences across the entire protocol.
