Skip to main content

​
Summary

Monad, like Ethereum, charges for processing transactions based on the complexity of the transaction. Complexity is measured in units of gas. This page summarizes how gas is charged, i.e. the conversion between the gas of a transaction and the amount of MON that a user will have to pay. A separate page, Opcode Pricing, describes how much each opcode costs in units of gas.
These changes are covered formally in the Monad Initial Spec Proposal

​
How much does a transaction cost?

A typical 200,000-gas transaction on Monad costs about $0.0005 at the minimum base fee of 100 MON-gwei, and a simple MON transfer (21,000 gas) costs about $0.00005, a fraction of a cent. Fees are paid in MON, so these dollar amounts are approximate; the MON cost is exact. The cost of a transaction is the gas it is charged multiplied by the price paid per unit of gas. At the minimum base fee of 100 MON-gwei and no priority fee, a 200,000-gas transaction costs 0.02 MON, or about $0.0005: fee=gas limit×price per gas=200,000×(100×10−9 MON)=0.02 MON\text{fee} = \text{gas limit} \times \text{price per gas} = 200{,}000 \times \left(100 \times 10^{-9}\ \text{MON}\right) = 0.02\ \text{MON} 200,000 gas is a common reference size for a swap or comparable contract call; a transaction’s actual gas depends on what it does. The table below lists representative sizes.
Monad charges the gas limit you set, not the gas actually used (details), so these amounts can’t rise after execution the way a gas-used estimate can. They are the most you would pay while the base fee is at its floor. Under sustained network load the base fee can rise above 100 MON-gwei (see base fee controller). A native MON transfer always uses exactly 21,000 gas; gas for token transfers and swaps varies by contract.

​
Gas definitions

A common point of confusion among users is the distinction between gas of a transaction (units of work) and the gas price of a transaction (price in native tokens per unit of work).

​
Gas limit, not gas used

In Monad, the gas charged for a transaction is the gas limit set in the transaction, rather than the gas used in the course of execution. This is a design decision to support asynchronous execution. Under asynchronous execution, leaders build blocks (and validators vote on block validity) prior to executing. If the protocol charged gas_used, a user could submit a transaction with a large gas_limit that actually consumes very little gas. This transaction would take up a lot of space toward the block gas limit but wouldn’t pay very much for taking up that space, opening up a DOS vector.

​
EIP-1559 Compatibility

Monad supports EIP-1559. EIP-1559 (type 2) transactions have the parameters priority_price_per_gas and max_price_per_gas, which, together with base_price_per_gas (a system parameter that changes each block), determine the gas bid for the transaction:
Notes:
  • base_price_per_gas is a system parameter that changes each block. Every transaction in the same block will have the same base_price_per_gas
  • Users specify priority_price_per_gas and max_price_per_gas when signing a transaction
  • Since everyone in the same block will pay the same base_price_per_gas, the priority_price_per_gas is a way for users to pay more to prioritize their transactions.
  • Since users don’t determine base_price_per_gas, the max_price_per_gas is a safeguard that limits the amount they may end up paying. Of course, if that value is set too low, the transaction will not end up being chosen for inclusion.
This article provides another good explanation of EIP-1559 gas pricing.

​
base_price_per_gas controller

Monad uses a different controller for base_price_per_gas than Ethereum: block_gask=∑tx∈blockkgas_limittxbase_price_per_gask+1=max⁡{min_base_price_per_gas,base_price_per_gask⋅exp⁡(ηk⋅block_gask−targetblock_gas_limit−target)}ηk=max_step_size⋅ϵϵ+momentk−trendk2trendk+1=β⋅trendk+(1−β)⋅(target−block_gask)momentk+1=β⋅momentk+(1−β)⋅(target−block_gask)2\begin{align*} \mathrm{block\_gas}_{k} &= \sum\limits_{\mathrm{tx} \in \mathrm{block}_k}\mathrm{gas\_limit}_\mathrm{tx}\\ \mathrm{base\_price\_per\_gas}_{k+1} &= \max\left\{\text{min\_base\_price\_per\_gas}, \mathrm{base\_price\_per\_gas}_k \cdot \exp \left( \eta_k \cdot \frac{\mathrm{block\_gas}_{k} - \text{target}}{\text{block\_gas\_limit} - \text{target}} \right) \right\} \\ \eta_k &= \frac{\text{max\_step\_size}\cdot\epsilon}{\epsilon+\sqrt{\mathrm{moment}_k - \mathrm{trend}_k^2}} \\ \mathrm{trend}_{k+1} &= \beta\cdot \mathrm{trend}_k + (1-\beta)\cdot \left(\text{target}-\mathrm{block\_gas}_{k} \right) \\ \mathrm{moment}_{k+1} &= \beta\cdot \mathrm{moment}_k + (1-\beta)\cdot \left(\text{target}-\mathrm{block\_gas}_{k} \right)^2 \end{align*} This inductive formula starts with base_price_per_gas0=0moment0=0trend0=0\begin{align*} \mathrm{base\_price\_per\_gas}_{0} &= 0 \\ \mathrm{moment}_{0} &= 0 \\ \mathrm{trend}_{0} &= 0 \end{align*} and with the following parameters: max_step_size=1/28target=160M (80% full) β=0.96ϵ=target=160M\begin{align*} \mathrm{max\_step\_size} &= 1/28 \\ \mathrm{target} &= 160\text{M}\ \text{(80\% full)}\ \\ \beta &= 0.96 \\ \epsilon &= \mathrm{target} = 160\text{M} \end{align*} And min_base_price_per_gas=100 MON-gwei (100×10−9 MON)\text{min\_base\_price\_per\_gas} = 100\ \text{MON-gwei}\ (100 \times 10^{-9}\ \text{MON}) Compared to the base_price_per_gas controller in Ethereum, this controller increases more slowly and decreases more quickly. This is to avoid underutilization of blockspace due to an overpriced base_price_per_gas. For a more comprehensive discussion of Monad controller design considerations and behavior, check out this blog post from Category Labs.

​
Recommendations for developers

​
Set the gas limit explicitly if it is constant

Many on-chain actions have a fixed gas cost. The simplest example is that a transfer of native tokens always costs 21,000 gas, but there are many others. For actions where the gas cost of the transaction is known ahead of time, it is recommended to set it directly prior to handing the transaction off to the wallet. This offers several benefits:
  • It reduces latency and gives users a better experience, since the wallet doesn’t have to call eth_estimateGas and wait for the RPC to respond.
  • It retains greater control over the user experience, avoiding cases where the wallet sets a high gas limit in a corner case as described in the warning below.
Some wallets, including MetaMask, are known to have the following behavior: when eth_estimateGas is called and the contract call reverts, they set the gas limit for this transaction to a very high value.This is the wallet’s way of giving up on setting the gas limit and accepting whatever gas usage is at execution time. However, it doesn’t make sense on Monad where the full gas limit is charged.Contract call reversion happens whenever the user is trying to do something impossible. For example, a user might be trying to mint an NFT that has minted out.If the gas limit is known ahead of time, setting it explicitly is best practice, since it ensures the wallet won’t handle this case unexpectedly.