Skip to main content
To process every transaction, computation resources on the network are consumed. Thus, the concept of “gas” arises as a reference to the computation required to process the transaction by a validator. Users have to pay a fee for this computation, all transactions require an associated fee. This fee is calculated based on the gas required to execute the transaction and the gas price. Additionally, a transaction needs to be signed using the sender’s private key. This proves that the transaction could only have come from the sender and was not sent fraudulently. The transaction lifecycle in Cosmos EVM involves a dual-phase process through CometBFT consensus:

​
CheckTx Phase

  • Transaction routing: The ante handler identifies transaction type via extension options (ante/ante.go:18-71)
  • EVM validation: MonoDecorator consolidates validation using go-ethereum’s txpool.ValidateTransaction() (ante/evm/mono_decorator.go:99+)
  • Transaction filtering: Uses PendingFilter with configurable MinTip, base fee, and transaction type filters (mempool/mempool.go:455-461)
  • Nonce gap handling: Transactions with future nonces are queued locally via InsertInvalidNonce() (mempool/check_tx.go:21-23)
  • Mempool addition: Valid transactions added to CometBFT mempool for P2P broadcast

​
DeliverTx Phase

For detailed transaction flow and mempool behavior, see the Mempool documentation and Cosmos SDK lifecycle.
The transaction hash is a unique identifier and can be used to check transaction information, for example, the events emitted, if was successful or not. Transactions can fail for various reasons. For example, the provided gas or fees may be insufficient. Also, the transaction validation may fail. Each transaction has specific conditions that must fullfil to be considered valid. A widespread validation is that the sender is the transaction signer. In such a case, if you send a transaction where the sender address is different than the signer’s address, the transation will fail, even if the fees are sufficient. Nowadays, transactions can not only perform state transitions on the chain in which are submitted, but also can execute transactions on another blockchains. Interchain transactions are possible through the Inter-Blockchain Communication protocol (IBC). Find a more detailed explanation on the section below.

​
Transaction Types

Cosmos EVM supports two transaction types:
  1. Cosmos transactions
  2. Ethereum transactions
This is possible because the Cosmos EVM uses the Cosmos-SDK and implements the Ethereum Virtual Machine as a module. In this way, Cosmos EVM provides the features and functionalities of Ethereum and Cosmos chains combined, and more. Although most of the information included on both of these transaction types is similar, there are differences among them. An important difference, is that Cosmos transactions allow multiple messages on the same transaction. Conversely, Ethereum transactions don’t have this possibility. Cosmos EVM implements Ethereum transactions by wrapping them in MsgEthereumTx (x/vm/types/tx.pb.go:36-43), which contains:
  • From: Ethereum signer address bytes for signature verification
  • Raw: Complete Ethereum transaction data
This wrapper uniquely implements both sdk.Msg and sdk.Tx interfaces, bypassing standard SDK transaction bundling to use go-ethereum validation logic directly. Find more information about these two types on the following sections.

​
Cosmos Transactions

On Cosmos chains, transactions are comprised of metadata held in contexts and sdk.Msgs that trigger state changes within a module through the module’s Protobuf Msg service. When users want to interact with an application and make state changes (e.g. sending coins), they create transactions. Cosmos transactions can have multiple sdk.Msgs. Each of these must be signed using the private key associated with the appropriate account(s), before the transaction is broadcasted to the network. A Cosmos transaction includes the following information:
  • Msgs: an array of msgs (sdk.Msg)
  • GasLimit: option chosen by the users for how to calculate how much gas they will need to pay
  • FeeAmount: max amount user is willing to pay in fees
  • TimeoutHeight: block height until which the transaction is valid
  • Signatures: array of signatures from all signers of the tx
  • Memo: a note or comment to send with the transaction
To submit a Cosmos transaction, users must use one of the provided clients.

​
Ethereum Transactions

Ethereum transactions refer to actions initiated by EOAs (externally-owned accounts, managed by humans), rather than internal smart contract calls. Ethereum transactions transform the state of the EVM and therefore must be broadcasted to the entire network. Ethereum transactions also require a fee, known as gas. (EIP-1559) introduced the idea of a base fee, along with a priority fee which serves as an incentive for validators to include specific transactions in blocks. There are several categories of Ethereum transactions:
  • regular transactions: transactions from one account to another
  • contract deployment transactions: transactions without a to address, where the contract code is sent in the data field
  • execution of a contract: transactions that interact with a deployed smart contract, where the to address is the smart contract address
An Ethereum transaction includes the following information:
  • recipient: receiving address
  • signature: sender’s signature
  • nonce: counter of tx number from account
  • value: amount of ETH to transfer (in wei)
  • data: include arbitrary data. Used when deploying a smart contract or making a smart contract method call
  • gasLimit: max amount of gas to be consumed
  • maxPriorityFeePerGas: mas gas to be included as tip to validators
  • maxFeePerGas: max amount of gas to be paid for tx
For more information on Ethereum transactions and the transaction lifecycle, go here. Cosmos EVM supports Ethereum transaction types defined in AcceptedTxType (ante/evm/mono_decorator.go:23-27):
  • Legacy Transactions (EIP-155): With chain ID protection
  • Access List Transactions (EIP-2930): Pre-declared storage access
  • Dynamic Fee Transactions (EIP-1559): Base fee + priority fee model
  • Set Code Transactions (EIP-7702): Account code assignment with authorization list support (x/vm/types/tx.go:28)
Note: Unprotected legacy transactions are not supported by default.
Cosmos EVM is capable of processing Ethereum transactions by wrapping them on a sdk.Msg. It achieves this by using the MsgEthereumTx. This message encapsulates an Ethereum transaction as an SDK message and contains the necessary transaction data fields. The MsgEthereumTx implements both sdk.Msg and sdk.Tx interfaces to bypass standard Cosmos SDK transaction bundling. This design enables:

​
EVM Execution Integration

Cosmos EVM creates a sophisticated execution environment that bridges Ethereum and Cosmos SDK state management: Block Context Mapping (x/vm/keeper/state_transition.go:46-57):
  • CometBFT block proposer → EVM coinbase address
  • Block height → EVM block number
  • Block timestamp → EVM timestamp opcode
  • Historical block access via EIP-2935 contract (x/vm/keeper/state_transition.go:114-122)
Access Control Hooks (x/vm/keeper/state_transition.go:67-78):
  • Restrict contract creation and execution via EVM opcode interceptors
  • Policy-based permissions for CREATE, CREATE2, and CALL operations
Receipt Generation (x/vm/keeper/state_transition.go:125):

​
IBC Integration

Cosmos EVM enables cross-chain functionality through IBC integration accessible directly from EVM smart contracts: ICS20 Precompile: Provides direct interface for Ethereum contracts to initiate cross-chain token transfers, bridging EVM execution with the Cosmos ecosystem. Cosmos SDK Module Access: Smart contracts can interact with bank, staking, distribution, and governance modules through precompiled contracts, enabling DeFi applications that access staking rewards and cross-chain transfers from Solidity code.

​
Transaction Ordering and Prioritization

In Cosmos EVM, both Ethereum and Cosmos transactions compete fairly for block inclusion:
  • Fee Priority
  • Nonce Handling
Transactions are ordered by their effective tips:
  • Ethereum: gas_tip_cap or min(gas_tip_cap, gas_fee_cap - base_fee)
  • Cosmos: (fee_amount / gas_limit) - base_fee
  • Higher tips = higher priority, regardless of transaction type
For detailed mempool behavior and flow diagrams, see Mempool Architecture.

​
Transaction Receipts

Cosmos EVM generates Ethereum-compatible transaction receipts while integrating with Cosmos SDK event systems. Receipt processing (x/vm/keeper/state_transition.go:125-146) includes: Bloom Filter Computation: initializeBloomFromLogs() creates transaction and block-level bloom filters for efficient log filtering. Gas Reconciliation: calculateCumulativeGasFromEthResponse() reconciles EVM gas usage with SDK gas meter state. Dual Event Emission: Events contain both Ethereum transaction hash (for Ethereum tools) and CometBFT transaction hash (for Cosmos tools) (x/vm/keeper/msg_server.go:77-80). Receipt fields include:
  • transactionHash : hash of the transaction
  • transactionIndex: integer of the transactions index position in the block
  • blockHash: hash of the block where this transaction was in
  • blockNumber: block number where this transaction was in
  • from: address of the sender
  • to: address of the receiver. null when its a contract creation transaction
  • cumulativeGasUsed : The total amount of gas used when this transaction was executed in the block
  • effectiveGasPrice : The sum of the base fee and tip paid per unit of gas
  • gasUsed : The amount of gas used by this specific transaction alone
  • contractAddress : The contract address created, if the transaction was a contract creation, otherwise null
  • logs: Array of log objects, which this transaction generated
  • logsBloom: Bloom filter for light clients to quickly retrieve related logs
  • type: integer of the transaction type, 0x00 for legacy transactions, 0x01 for access list types, 0x02 for dynamic fees, 0x04 for set code transactions
  • root : transaction stateroot (pre Byzantium)
  • status: either 1 (success) or 0 (failure)

​
Implementation Reference

Transaction Processing Core: State Management Engine: Mempool Architecture: