Ethereum and Cosmos, two prominent blockchain protocols, have long pursued integration through solutions like EVM compatible chains built on Cosmos SDK (e.g. evmos/Ethermint), followed by the emerging consensus-layer (CL) swaps (e.g. Tendermint replacement for Ethereum PoS) in EVM compatible chains. This series unpacks their technical approaches and associated security trade-offs, providing an in-depth exploration of the convergence of these ecosystems.

Overview

Ethereum and Cosmos are among the most popular public blockchains, each having made significant impacts on the community over the past few years. The idea of merging these two platforms has persisted since their mainnets first launched. Over time, various approaches have been proposed to achieve integration, such as using EVMOS or Ethermint to build EVM-compatible applications on the Cosmos stack, or leveraging EVM precompiles to enhance interoperability with Cosmos.

Additionally, following Ethereum’s Merge, discussions have emerged about replacing Ethereum’s consensus layer (CL) with Tendermint/CometBFT—an approach that aligns with the visions of projects like Berachain and Story IP blockchains.

In this article series, we will explore the fundamentals of these interoperability solutions, as well as examine their underlying vulnerabilities one by one. Our goal is to provide a thorough and comprehensive understanding of these two prominent public blockchain protocols.

EVMOS

The Cosmos SDK is well known for its flexibility and extensibility, allowing developers to create custom modules (X modules) including auth, bank, staking for specific applications atop the Cosmos SDK and Tendermint consensus engine.

evmos (previously known as Ethermint) was designed to integrate EVM-compatible applications into the Cosmos by implementing the EVM as a Cosmos SDK module.

However, the evmos application processes two types of transactions:

• EVM transactions (Ethereum-compatible)
• Legacy Cosmos transactions (native Cosmos-SDK)

So, how does evmos differentiate and process these two types of transactions? The design is quite sophisticated, as evmos distinguishes between EVM and Cosmos transactions based on their message type URLs, specifically routing each through its respective processing path. Below is an overview of the EVM transaction flow:

• A MsgEthereumTx with msg type of ethermint.evm.v1.ExtensionOptionsEthereumTx is first routed to its dedicated MonoEVMAnteHandler;
• The AnteHandler processes the transaction through its custom decorators chain in order;
• After validation, runMsgs executes the transaction in the Ethereum VM environment, i.e. EVM which is identical to the go-ethereum runtime environment.

With both EVM and Cosmos stacks coexisting, transactions are routed based on their message type URL (extension). This routing occurs in the AnteHandler during CheckTx, directing each transaction to the appropriate stack (EVM or Cosmos) for processing.

However, a key distinction arises in the fee market mechanics between the two chains due to fundamental differences in state execution:

• EVM: Implements a gas refund mechanism, where unused gas from operations like storage clearing is partially refunded.
• Cosmos: Lacks gas refunds, meaning users pay the full gas cost upfront regardless of execution state changes.

This structural difference impacts transaction cost efficiency and developer considerations when deploying cross-stack applications, leading to potential issues with this discrepancy. For instance, the community has raised concerns about gas theft through the extension of ETH-typed transactions.

Security Issues Arising from Dual-Stack Architecture Discrepancies

Since 2022, multiple critical vulnerabilities have been disclosed in EVMOS-style chains (EVM modules within Cosmos SDK chains), all involving transaction fee manipulation:

• Cronos Theft of Transactions Fees: The Cronos chain experienced a transaction fee theft vulnerability (Cronos Theft of Transactions Fees Bugfix Review), exposing a fundamental flaw in fee-handling logic.
• Stealing Gas via Bypassing Ethermint Ante Handlers: Jump Crypto's security team documented a nearly identical attack vector (Stealing Gas: Bypassing Ethermint Ante Handlers), demonstrating the persistent nature of this class of vulnerability in hybrid EVM/Cosmos architectures.

These repeated incidents highlight systemic challenges in securely implementing EVM-compatible fee markets within Cosmos SDK chains.

In-depth Code Analysis for Potential Vulnerabilities

Let’s delve into the code to examine the vulnerabilities and the potential attack vectors associated with them.

Direct Bypass of EthAnteHandler

In the context of evmos, the EthAnteHandler initially manages fee deduction for EVM-specific transactions, particularly through the EthGasConsumeDecorator, which oversees both fee deductions and gas refunds, as the below code snippet shows:

The EthGasConsumeDecorator enforces that all messages in the transaction are of type MsgEthereumTx. The chain of ante handlers validation has been confirmed and meets all requirements in EthAnteHandler. However, this process can be bypassed. One possible attack involves submitting a Cosmos transaction that includes MsgEthereumTx messages without the /ethermint.evm.v1.ExtensionOptionsEthereumTx extension option. In this case, the legacy Cosmos ante handlers are activated, resulting in no deductions for EVM gas fees. Furthermore, it’s possible to specify an arbitrary gas limit and then get refunded gas that wasn’t deducted in the first place.

The fix to this vulnerability added a RejectMessagesDecorator to the Cosmos anteHandler chain that blocks transactions with MsgEthereumTx messages, removing this attack vector, as the following code snippet shows:

If the ExtensionOptions are not specified, the MsgEthereumTx will pass through the default Cosmos AnteHandler and will ultimately be rejected by the RejectMessagesDecorator. The aforementioned fix addresses the attack pattern that prevents the MsgEthereumTx message from being included in Cosmos transactions. However, this solution alone is insufficient to completely eliminate all potential attack vectors.

Indirect Bypass via Nested Authz Message

The Cosmos SDK features the MsgExec message type within the Authz module, enabling support for nested messages. When MsgEthereumTx is nested within MsgExec, it can circumvent the default Cosmos AnteHandlers, including the RejectMessagesDecorator. The absence of message type checks in the AuthzLimiterDecorator within the anteHandlers may leave malicious vectors open, as shown in DOS and transaction fee expropiation through Authz exploit, and the fix could be found in the below code snippet:

This situation presented an opportunity for malicious users to exploit it by specifying an excessively high gas * gasPrice value for the nested message within an EVM transaction (MsgEthereumTx). Such actions could result in the unauthorized collection of gas fees from the fee collector, as any excess gas is returned to the sender per the gas refund mechanism in the EVM. While the outer Cosmos Tx incurs a gas fee for execution, this vulnerability could still lead to a potential gas fee theft attack targeting the fee collector within a block.

Conclusion on evmos

Extreme caution is advised regarding this particular issue, as effectively addressing it necessitates a high level of expertise. Additionally, maintaining two separate stacks can be burdensome for many projects, and the coupling between them is excessively tight.

The evmos Foundation had announced plan evmos Signals Ethereum Alignment by Fully Deprecating Cosmos Transactions to decouple these two stacks, ceasing support for Cosmos transactions in order to focus exclusively on EVM transactions, which was expected to be completed by the end of the year of 2024.

Summary

This article focuses on EVMOS/Ethermint’s approach to integrating the Ethereum Virtual Machine (EVM) as a native Cosmos SDK module, similar to any other X component. However, fundamental discrepancies persist, particularly in gas market mechanics, due to differences between EVM and Cosmos execution models.

Notably, EVMOS has announced plans to phase out native Cosmos transaction support in favor of full EVM alignment. This shift introduces a new paradigm for interacting with the Cosmos stack, primarily through EVM transactions and specialized precompiled contracts, designed to bridge functionality gaps.

A detailed exploration of these precompiles and their implementation will be covered in Part 2 of this series. Stay tuned for the upcoming release!