Supporting several execution environments doesn’t help much if each one ends up trading in its own isolated pool
Liquidity fragmentation is one of those problems that’s easy to describe and surprisingly hard to fix. Spread the same underlying assets across several separate pools — one per chain, one per VM, one per bridge route — and every individual pool ends up thinner than it would be if all that liquidity sat in one place. Thinner pools mean worse pricing, more slippage, and a market that’s technically active everywhere but genuinely deep nowhere.
A multi-VM chain has a specific version of this risk built into its own architecture. Supporting several virtual machines is supposed to give developers more choice about where to build. But if each VM effectively runs its own separate liquidity environment — a pool for EVM-based assets, a different pool for SVM-based ones, another for CosmWasm — the chain has recreated cross-chain fragmentation without anyone ever having to leave the network. Developers get their choice of execution environment, and users get the same thin, scattered liquidity problem multi-chain systems already have.
The alternative is treating liquidity as a property of the network, not of any individual VM running on it. If liquidity is shared across every VM Lithosphere supports, a pool isn’t tied to whichever execution environment happened to create it — it’s accessible regardless of whether the trade activating it originates from a Solidity contract on the EVM, an order book built on the SVM, or a CosmWasm application. The VM is where the logic runs; it isn’t where the liquidity lives.
This has a direct effect on the example that makes multi-VM architecture appealing in the first place: a Solidity DeFi protocol on the EVM, a high-speed order book on the SVM, and an NFT marketplace on CosmWasm, all coexisting on the same network. If those three applications each pulled from separate liquidity pools, they’d functionally behave like three separate chains that happen to share infrastructure. Shared liquidity is what actually lets them behave like parts of one market, where activity in one application can support pricing and depth for another.
It’s also, again, a detail that’s easy to overlook next to flashier claims like native cross-VM contract calls. But contract calls moving natively between VMs don’t mean much if the assets those contracts are working with are still siloed by VM underneath. Shared liquidity is the less visible half of what makes a multi-VM network actually behave like one coherent system instead of several coexisting ones — and it’s the half that determines whether users actually get better pricing and depth, or just more places to trade thinly.
