Since permissionless CosmWasm is now live on the Cosmos Hub, a new question naturally emerges:
Should the Hub eventually support both CosmWasm and EVM?
If yes, should that happen directly on the Hub through a dual-VM architecture (similar to Injective), or would a dedicated EVM sidechain secured by the Hub be a better approach?
This isn’t a proposal, but rather an open discussion about the long-term evolution of the Hub.
Where we are today
The Hub already supports permissionless CosmWasm, allowing developers to deploy applications directly on the Hub.
That opens the door to native DeFi, infrastructure, automation, treasury management and many other applications.
The remaining question is whether adding EVM compatibility would significantly increase the Hub’s attractiveness.
Why this discussion matters now
This discussion also fits into the broader conversation around the Hub liquidity layer.
In the recent Hub Weekly update, the liquidity layer was described as an open design conversation. Two possible directions were mentioned: a Hub-native orderbook with third-party DEX plugins, and an intents-based settlement layer.
The orderbook design is especially relevant here because one of its tradeoffs is significant technical complexity and likely reliance on EVM. That means the question of EVM support is not abstract. It may become directly connected to the Hub’s ability to support deeper liquidity, institutional flow, professional market makers and more advanced trading infrastructure.
At the same time, the Hub’s stated direction seems to be moving toward direct value capture: fees benefiting the Hub, possible ATOM buybacks, revenue routed to the community pool, and liquidity that is bootstrapped professionally rather than simply subsidized with ATOM emissions.
From that perspective, the EVM question should probably be discussed in the same strategic frame:
If the Hub wants to become a real liquidity layer, does it need EVM compatibility? And if yes, should that compatibility live directly on the Hub, or outside of it?
Why even consider EVM?
Whether we like Solidity or not, today’s blockchain ecosystem is still largely EVM-centric.
Supporting EVM could potentially bring:
-
access to the largest smart contract developer ecosystem
-
compatibility with existing wallets like MetaMask
-
easier migration of existing applications
-
more DeFi protocols
-
deeper liquidity
-
more stablecoins
-
additional gas consumption
-
more value captured by ATOM
In other words, EVM isn’t necessarily about replacing CosmWasm.
It’s about expanding the addressable market.
Option 1 — Dual VM (CosmWasm + EVM on the Hub)
This is roughly the path taken by Injective.
The Hub would run both execution environments on the same chain.
Advantages
Everything shares the same liquidity
Instead of splitting liquidity across multiple chains, every application would interact with the same native ATOM balances.
Users wouldn’t need to bridge assets simply to switch between ecosystems.
One security model
Validators secure both environments, ensuring that both execution layers benefit from the same level of security. There is only one chain, which simplifies the overall architecture and avoids fragmentation. Governance is unified, allowing decisions to be made consistently across the entire system. Finally, there is a single economic model, which helps align incentives and maintain coherence across the network.
More value accrues to ATOM
If EVM applications run directly on the Hub:
-
gas is paid on the Hub
-
activity stays on the Hub
-
liquidity remains on the Hub
Instead of exporting value elsewhere.
Native interaction between both ecosystems
CosmWasm contracts and Solidity contracts could potentially interact much more naturally than if they lived on separate chains.
Challenges of Dual VM
Several important challenges would need to be solved.
Address format
Today, ATOM uses Cosmos addresses, while the EVM relies on Ethereum-style addresses. Injective was able to handle this difference because it was designed that way from the start. However, the Cosmos Hub already has millions of existing addresses, so migrating them would require careful planning.
Exchange coordination
Centralized exchanges would also need to adapt, and any migration would require strong coordination; otherwise, deposits and withdrawals could become problematic.
Validator costs
Running two execution environments generally means:
-
larger state
-
heavier nodes
-
higher hardware requirements
-
increased operational costs
That could impact decentralization if requirements become significantly higher.
Larger attack surface
More execution environments also means:
-
more complexity
-
more software to maintain
-
more potential attack vectors
Although permissionless CosmWasm already exists today, adding EVM naturally increases the system’s complexity.
Who would maintain the EVM?
Another important question that often gets overlooked is long-term ownership.
Adding an EVM isn’t just about integrating it once. It becomes a long-term commitment that requires continuous maintenance:
-
tracking Ethereum upgrades,
-
maintaining compatibility with the Solidity ecosystem (Foundry, Hardhat, MetaMask, etc.),
-
updating precompiles,
-
fixing security issues,
-
ensuring long-term support for developers.
So the real question isn’t simply “Can we add an EVM?”, but rather:
Who is willing to own and maintain it for the next 10 years?
Personally, I think this responsibility would naturally fall to Cosmos Labs.
Following the acquisition of the Mintscan team, Cosmos Labs appears to be taking ownership of the Cosmos Hub’s product and software roadmap. The recent Hub Weekly update also mentioned that Hub mainnet maintenance is moving in-house to Cosmos Labs, while Hypha focuses on the public testnet program.
Cosmos Labs has also been discussing the Hub as a liquidity layer where applications, order flow and capital could converge.
From that perspective, supporting EVM would align well with that vision. If the Hub aims to become the primary destination for liquidity and applications within the Cosmos ecosystem, lowering the barrier for Solidity developers seems like a logical step.
That said, long-term ownership should be made explicit. Regardless of whether the Hub adopts a native dual-VM architecture or an EVM sidechain, the community should know which team is committed to maintaining that stack over the coming years.
Option 2 — EVM Sidechain
Instead of modifying the Hub itself, an EVM chain could be launched alongside it.
The Hub would continue doing what it already does while the EVM chain handles Solidity applications.
Advantages
Much lower migration risk, as existing users keep everything exactly as it is. There is no need for address migration or exchange migration, making the transition simpler. It is also easier to deploy and, if necessary, easier to roll back.
Downsides
The biggest downside is value fragmentation, as liquidity would naturally spread across two chains and applications would live elsewhere. Bridging would become necessary, forcing users to move assets back and forth, which means the Hub would capture less direct activity. Perhaps most importantly, Cosmos already has many EVM chains today, so launching one more would not necessarily make the Hub more unique.
The migration question
If Dual VM were chosen, several migration strategies seem possible.
Full migration
Move toward one unified account model, which would provide the best long-term user experience but also comes with the highest migration risk.
Dual address model
Keep existing Cosmos addresses while adding EVM addresses, allowing both to access the same native balances through protocol-level abstractions. This approach reduces migration risk, but it also introduces permanent address confusion.
Opt-in migration
Users migrate only if they want EVM compatibility. This is the safest option, but it would likely result in slower adoption.
The Hub’s future role
If the Hub wants applications, liquidity and users to live directly on it, a native dual-VM architecture appears to maximize value capture for ATOM.
If minimizing migration risk is the absolute priority, an EVM sidechain is probably the safer route, but it also preserves much of today’s fragmentation.
I’d be interested to hear what the community thinks, and it would be especially valuable to have Cosmos Labs actively participate in this discussion given their growing role in shaping the Hub’s roadmap.
-
Is EVM on the Hub even desirable?
-
How should migration be handled?
-
Are there technical or governance challenges that haven’t been considered here?
-
If the Hub liquidity layer ends up requiring EVM, should that EVM live directly on the Hub or on a separate chain?
Given how central and time-sensitive this topic is becoming, it could also be worth dedicating time to it during an upcoming community call, to gather broader feedback and align on potential directions.