Therefore this overview explains the basics of gas calculation, how to provide fees for transactions and how the Ethereum-type fee calculation uses a fee market (EIP-1559) for prioritizing transactions.

​
Prerequisite Readings​

​
Basics​

​
Why do Transactions Need Fees?​

If anyone can submit transactions to a network at no cost, the network can be overrun by a handful of actors sending large numbers of fraudulent transactions to clog up the network and stop it from working. The solution to this is a concept called “gas,” which is a resource consumed throughout transaction execution. In practice, a small amount of gas is spent on each step of code execution, thus effectively charging for use of a validator’s resources and preventing malicious actors from halting a network at will.

​
What is Gas?​

In general, gas is a unit that measures the computational intensity of a particular transaction — in other words, how much work would be required to evaluate and perform the job. Complex, multi-step transactions, such as a Cosmos transaction that delegates to a dozen validators, require more gas than simple, single-step transactions, such as a Cosmos transaction to send tokens to another address. When referring to a transaction, “gas” refers to the total quantity of gas required for the transaction. For example, a transaction may require 300,000 units of gas to be executed. Gas can be thought of as electricity (kWh) within a house or factory, or fuel for automobiles. The idea is that it costs something to get somewhere. More on Gas:

​
How is Gas Calculated?​

In general, there’s no way to know exactly how much gas a transaction will cost without simply running it. Using the Cosmos SDK, this can be done by simulating the Tx. Otherwise, there are ways to estimate the amount of gas a transaction will require, based on the details of the transaction fields, and data. In the case of the EVM, for example, each bytecode operation has a corresponding amount of gas. More on Gas Calculations:

​
How does Gas Relate to Fees?​

While gas refers to the computational work required for execution, fees refer to the amount of the tokens you actually spend to execute the transaction. They are derived using the following formula: 
Total Fees = Gas * Gas Price (the price per unit of gas)
If “gas” was measured in kWh, the “gas price” would be the rate (in dollars per kWh) determined by your energy provider, and the “fees” would be your bill. Just as with electricity, gas price is liable to fluctuate over a given day, depending on network traffic. More on Gas vs. Fees:

​
How are Fees Handled on Cosmos?​

Gas fees on Cosmos are relatively straightforward. As a user, you specify two fields:
  1. A GasLimit corresponding to an upper bound on execution gas, defined as GasWanted
  2. One of Fees or GasPrice, which will be used to specify or calculate the transaction fees
The node will entirely consume the fees provided, then begin to execute the transaction. If the GasLimit is found to be insufficient during execution, the transaction will fail and roll back any changes made, without refunding the fees provided. Validators for Cosmos SDK-based chains can specify their min-gas-prices that they will enforce when selecting transactions to include in blocks. Thus, transactions with insufficient fees will encounter delays or fail outright. At the beginning of each block, fees from the previous block are allocated to validators and delegators, after which they can be withdrawn and spent.

​
How are Fees Handled on Ethereum?​

Fees on Ethereum include multiple implementations that were introduced over time. Originally, a user would specify a GasPrice and GasLimit within a transaction—much like a Cosmos SDK transaction. A block proposer would receive the entire gas fee from each transaction in the block, and they would select transactions to include accordingly. With proposal EIP-1559 and the London Hard fork, gas calculation changed. The GasPrice from above has now been split into two separate components: a BaseFee and PriorityFee. The BaseFee is calculated automatically based on the block size and is burned once the block is mined. The PriorityFee goes to the proposer and represents a tip, or an incentive for a proposer to include the transaction in a block. 
Gas Price = Base Fee + Priority Fee
Within a transaction, users can specify a max_fee_per_gas corresponding to the total GasPrice and a max_priority_fee_per_gas corresponding to a maximum PriorityFee, in addition to specifying the gas_limit as before. All surplus gas that was not required for execution is refunded to the user. More on Ethereum Fees:

​
Implementation​

​
How are Gas and Fees Handled in the Cosmos EVM?​

Fundamentally, a Cosmos EVM chain is a Cosmos SDK chain that enables EVM compatibility as part of a Cosmos SDK module. As a result of this architecture, all EVM transactions are ultimately encoded as Cosmos SDK transactions and update a Cosmos SDK-managed state. Since all transactions are represented as Cosmos SDK transactions, transaction fees can be treated identically across execution layers. In practice, dealing with fees includes standard Cosmos SDK logic, some Ethereum logic, and custom Cosmos EVM logic. For the most part, fees are collected by the fee_collector module, then paid out to validators and delegators. A few key distinctions are as follows:
  1. Fee Market Module In order to support EIP-1559 gas and fee calculation on the EVM layer, Cosmos EVM tracks the gas supplied for each block and uses that to calculate a base fee for future EVM transactions, thus enabling EVM dynamic fees and transaction prioritization as specified by EIP-1559. For EVM transactions, each node bypasses their local min-gas-prices configuration, and instead applies EIP-1559 fee logic—the gas price simply must be greater than both the global min-gas-price and the block’s BaseFee, and the surplus is considered a priority tip. This allows validators to compute Ethereum fees without applying Cosmos SDK fee logic. Unlike on Ethereum, the BaseFee on a Cosmos EVM chain is not burned, and instead is distributed to validators and delegators by default, although this can be adjusted. Furthermore, the BaseFee is lower-bounded by the global min-gas-price (currently, the global min-gas-price parameter is set to zero, although it can be updated via Governance).
  2. EVM Gas Refunds Cosmos EVM refunds a fraction (at least 50% by default) of the unused gas for EVM transactions to approximate the current behavior on Ethereum. This too can be adjusted.

​
Detailed Timeline​

  1. Nodes execute the previous block and run the EndBlock hook
    • As part of this hook, the FeeMarket (EIP-1559) module tracks the total TransientGasWanted from the transactions on this block. This will be used for the next block’s BaseFee.
  2. Nodes receive transactions for a subsequent block and gossip these transactions to peers
    • These can be sorted and prioritized by the included fee price (using EIP-1559 fee priority mechanics for EVM transactions - code snippet), to be included in the next block
  3. Nodes run BeginBlock for the subsequent block
    • The FeeMarket module calculates the BaseFee (code snippet) to be applied for this block using the total GasWanted from the previous block.
    • The Distribution module distributes the previous block’s fee rewards to validators and delegators
  4. For each valid transaction that will be included in this block, nodes perform the following:
    • They run an AnteHandler corresponding to the transaction type. This process:
      1. Performs basic transaction validation
      2. Verifies the fees provided are greater than the global and local minimum validator values and greater than the BaseFee calculated
      3. (For Ethereum transactions) Preemptively consumes gas for the EVM transaction
      4. Deducts the transaction fees from the user and transfers them to the fee_collector module
      5. Increments the TransientGasWanted in the current block, to be used to calculate the next block’s BaseFee
    • Then, for standard Cosmos Transactions, nodes:
      1. Execute the transaction and update the state
      2. Consume gas for the transaction
    • For Ethereum Transactions, nodes:
      1. Execute the transaction and update the state
      2. Calculate the gas used and compare it to the gas supplied, then refund a designated portion of the surplus
  5. Nodes run EndBlock for this block and store the block’s GasWanted

​
Detailed Mechanics​

​
Cosmos Gas​

In the Cosmos SDK, gas is tracked in the main GasMeter and the BlockGasMeter:
  • GasMeter: keeps track of the gas consumed during executions that lead to state transitions. It is reset on every transaction execution.
  • BlockGasMeter: keeps track of the gas consumed in a block and enforces that the gas does not go over a predefined limit. This limit is defined in the CometBFT consensus parameters and can be changed via governance parameter change proposals.
Since gas is priced per-byte, the same interaction is more gas-intensive with larger parameter values than smaller (unlike Ethereum’s uint256 values, Cosmos SDK numericals are represented using Big.Int types, which are dynamically sized). More information regarding gas as part of the Cosmos SDK can be found here.

​
Matching EVM Gas consumption​

Cosmos EVM supports Ethereum Web3 tooling. For this reason, gas consumption must be equatable with other EVMs, most importantly Ethereum. The main difference between EVM and Cosmos state transitions, is that the EVM uses a gas table for each OPCODE, whereas Cosmos uses a GasConfig that charges gas for each CRUD operation by setting a flat and per-byte cost for accessing the database. +++ https://github.com/cosmos/cosmos-sdk/blob/3fd376bd5659f076a4dc79b644573299fd1ec1bf/store/types/gas.go#L187-L196 In order to match the gas consumed by the EVM, the gas consumption logic from the SDK is ignored, and instead the gas consumed is calculated by subtracting the state transition leftover gas plus refund from the gas limit defined on the message. To ignore the SDK gas consumption, we reset the transaction GasMeter count to 0 and manually set it to the gasUsed value computed by the EVM module at the end of the execution. +++ https://github.com/cosmos/evm/blob/098da6d0cc0e0c4cefbddf632df1057383973e4a/x/evm/keeper/state_transition.go

​
AnteHandler​

The Cosmos SDK AnteHandler performs basic checks prior to transaction execution. These checks are usually signature verification, transaction field validation, transaction fees, etc. Regarding gas consumption and fees, the AnteHandler checks that the user has enough balance to cover for the tx cost (amount plus fees) as well as checking that the gas limit defined in the message is greater or equal than the computed intrinsic gas for the message.

​
Gas Refunds​

In the EVM, gas can be specified prior to execution. The totality of the gas specified is consumed at the beginning of the execution (during the AnteHandler step) and the remaining gas is refunded back to the user if any gas is left over after the execution. Additionally the EVM can also define gas to be refunded back to the user but those will be capped to a fraction of the used gas depending on the fork/version being used.

​
Zero-Fee Transactions​

In Cosmos, a minimum gas price is not enforced by the AnteHandler as the min-gas-prices is checked against the local node/validator. In other words, the minimum fees accepted are determined by the validators of the network, and each validator can specify a different minimum value for their fees. This potentially allows end users to submit 0 fee transactions if there is at least one single validator that is willing to include transactions with 0 gas price in their blocks proposed. For this same reason, in the Cosmos EVM it is possible to send transactions with 0 fees for transaction types other than the ones defined by the evm module. EVM module transactions cannot have 0 fees as gas is required inherently by the EVM. This check is done by the EVM transactions stateless validation (i.e ValidateBasic) function as well as on the custom AnteHandler defined by Cosmos EVM.

​
Gas Estimation​

Ethereum provides a JSON-RPC endpoint eth_estimateGas to help users set up a correct gas limit in their transactions. For that reason, a specific query API EstimateGas is implemented in the Cosmos EVM. It will apply the transaction against the current block/state and perform a binary search in order to find the optimal gas value to return to the user (the same transaction will be applied over and over until we find the minimum gas needed before it fails). The reason we need to use a binary search is that the gas required for the transaction might be higher than the value returned by the EVM after applying the transaction, so we need to try until we find the optimal value. A cache context will be used during the whole execution to avoid changes be persisted in the state. +++ https://github.com/cosmos/evm/blob/098da6d0cc0e0c4cefbddf632df1057383973e4a/x/evm/keeper/grpc_query.go For Cosmos Tx’s, developers can use Cosmos SDK’s transaction simulation to create an accurate estimate.

​
Cross-Chain Gas and Fees​

Let’s say a user transfers tokens from Chain A to a Cosmos EVM chain via IBC-transfer and wants to execute an EVM transaction—however, they don’t have any tokens to cover fees on the EVM chain. The Cosmos SDK introduced Tips as a solution to this issue; a user can cover fees using a different token—in this case, tokens from Chain A. To cover transaction fees using a tip, this user can sign a transaction with a tip and no fees, then send the transaction to a fee relayer. The fee relayer will then cover the fee in the native currency, and receive the tip in payment, behaving as an intermediary exchange.

​
Dealing with gas and fees with the Cosmos EVM CLI​

When broadcasting a transaction using the Cosmos EVM CLI client, users should keep into consideration the options available. There are three flags to consider when sending a transaction to the network:
  • --fees: fees to pay along with transaction. Defaults to the required fees.
  • --gas: the gas limit to set per-transaction; the default value is 200000.
  • --gas-prices: gas prices to determine the transaction fee.
However, not all of them need to be defined on each transaction. The correct combinations are:
  • --fees=auto: estimates fees and gas automatically (same behavior as --gas=auto). Throws an error if using any other fees-related flag (e.i, --gas-prices , --fees)
  • --gas=auto: same behavior as --fees=auto. Throws an error if using any other fees-related flag (e.i, --gas-prices , --fees)
  • --gas={int}: uses the specified gas amount and the required fees for the transaction
  • --fees={int}{denom}: uses the specified fees for the tx. Uses gas default value (200000) for the tx.
  • --fees={int}{denom} --gas={int}: uses specified gas and fees. Calculates gas-prices with the provided params
  • --gas-prices={int}{denom}: uses the provided gas price and the default gas amount (200000)
  • --gas-prices={int}{denom} --gas={int}: uses the gas specified on for the tx and calculates the fee with the corresponding parameters.
The reader should note that the former two options provide a frendlier user experience for new users, and the latter are for more advanced users, who desire more control over these parameters. The team introduced the auto flag option that calculates automatically the gas and fees required to execute a transaction. In this way, new users or developers can perform transactions without the hustle of defining specific gas and fees values. Using the auto flag sometimes may fail on estimating the right gas and fees based on network traffic. To overcome this, you can use a higher value for the --gas-adjustment flag. By default, this is set to 1.2. When the estimated values are insufficient, retry with a higher gas adjustment, for example, --gas-adjustment 1.3. It is not possible to use the --gas-prices and --fees flags combined. If so, the user will get an error stating that cannot provide both fees and gas prices. Keep in mind that the above combinations may fail if the provided fees or gas amount is insufficient. If that is the case, the CLI will return an error message with the specific reason. For example: 
raw_log: 'out of gas in location: submit proposal; gasWanted: 200000, gasUsed: 263940.  Please retry with a gas (--gas flag) amount higher than gasUsed: out of gas'