Lithosphere News Releases

Native Cross-VM Contract Calls and the End of the Bridge Detour

The real test of a multi-VM chain is whether contracts on different VMs can just talk to each other Every claim a multi-VM chain makes eventually runs into the same question: can an application on one VM actually call an application on another, directly, without leaving the network? A lot of what sounds like multi-VM…

The real test of a multi-VM chain is whether contracts on different VMs can just talk to each other

Every claim a multi-VM chain makes eventually runs into the same question: can an application on one VM actually call an application on another, directly, without leaving the network? A lot of what sounds like multi-VM support turns out to answer that question with “technically, through a bridge.” Two VMs can coexist on the same chain and still be functionally isolated from each other if the only way for a contract on one to interact with a contract on the other is to route through a bridge — the same detour multi-chain systems already rely on, just relabeled as happening “on one network.”

That detour matters more than it sounds like it should. A bridge call isn’t just slower than a native one; it introduces a separate trust boundary, a separate failure mode, and a separate point where the two sides of a transaction can end up with different understandings of what happened. Every earlier problem with cross-chain settlement — mismatched confirmations, inconsistent state, an extra system in the middle that has to be trusted — shows up again the moment cross-VM calls have to leave the chain’s native execution environment to happen at all.

Native cross-VM contract calls remove that detour by making the call itself a first-class operation the network handles directly, rather than a workaround built on top of it. A contract deployed on the EVM can call a contract running on CosmWasm, or the SVM, or LithoVM, the same way it would call another contract in its own environment — no bridge, no separate confirmation step, no additional trust assumption layered on top of the one the network already provides.

This is what actually makes the multi-VM example concrete rather than aspirational: a Solidity DeFi protocol on the EVM, an order book on the SVM, an NFT marketplace on CosmWasm, and AI agents running on LithoVM aren’t just four applications that happen to share a network — they can call each other directly, mid-transaction, as part of a single coherent workflow. An agent running on LithoVM can trigger a trade on the EVM-based DeFi protocol and settle it against the SVM order book without any of those steps requiring a bridge in between.

It’s worth being direct about why this is the hardest of the multi-VM properties to get right. Shared liquidity and a unified account model are largely about removing artificial separation between things that were always meant to be connected. Native cross-VM calls require the execution environments themselves — which were built independently, with different assumptions, different state models, and different security properties — to actually interoperate at the contract level, not just coexist under shared branding.

This is the property that separates a multi-VM chain from a chain that just hosts multiple VMs side by side. Everything else — shared liquidity, unified accounts, one gas token — makes the experience feel unified. Native cross-VM contract calls are what make it actually be unified, at the level where applications interact with each other rather than just the level where users interact with the network.

 

Source: https://lithosphere.network/native-cross-vm-contract-calls-and-the-end-of-the-bridge-detour/