> ## Documentation Index
> Fetch the complete documentation index at: https://monadfoundation-40611fb6-devops-1498-direct-udp-implementat.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Gas Pricing
> An estimated USD cost for a typical Monad transaction, plus how gas fees are calculated.
## 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](/developer-essentials/opcode-pricing), describes how much
each opcode costs in units of gas.
| Feature | Detail |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Gas charged** | The gas charged for a transaction is the **gas limit**. [Discussion](#gas-limit-not-gas-used) |
| **Price per gas** | EIP-1559-compatible, i.e. price paid per unit of gas is the sum of a system-controlled base fee and a user-specified priority fee. [Discussion](#eip-1559-compatibility) |
| **Base fee** | Base fee (aka `base_price_per_gas`) follows a dynamic controller, similar to the EIP-1559 controller but with slower increases and faster decreases. [Details](#base_price_per_gas-controller) |
| **Minimum base fee** | 100 MON-gwei (`100 * 10^-9 MON`) |
| **Typical cost** | A typical 200,000-gas transaction costs about **\$0.0005** at the minimum base fee (≈ 0.02 MON). [Worked example](#how-much-does-a-transaction-cost) |
| **Block gas limit** | 150M gas |
| **Transaction gas limit** | 30M gas |
| **Opcode pricing** | See [Opcode Pricing](/developer-essentials/opcode-pricing) |
| **Transaction ordering** | Default Monad client behavior is to order transactions according to a Priority Gas Auction (descending total gas price). |
These changes are covered formally in the
[Monad Initial Spec Proposal](https://category-labs.github.io/category-research/monad-initial-spec-proposal.pdf)
## 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:
$$
\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.
| Transaction | Gas limit | Cost (MON) | Cost (USD, approx.) |
| --------------------- | --------- | ------------ | ------------------- |
| Native MON transfer | 21,000 | 0.0021 MON | \~\$0.00005 |
| ERC-20 token transfer | \~65,000 | \~0.0065 MON | \~\$0.00016 |
| Typical DEX swap | \~200,000 | \~0.02 MON | \~\$0.0005 |
Monad charges the **gas limit** you set, not the gas actually used
([details](#gas-limit-not-gas-used)), 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](#base_price_per_gas-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).
| Feature | Definition |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Gas** | A unit of work. Gas measures the amount of work the network has to do to process something.
Since the network has multiple kinds of resources (network bandwidth, CPU, SSD bandwidth, and state growth), gas is inherently a projection from many dimensions into a single one. |
| **Gas price (price\_per\_gas)** | The **price** (in native tokens) paid **to process one unit** of gas. |
| **Gas limit** | The maximum **number of units of gas** that a transaction is allowed to consume. |
## 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.
```
gas_paid = gas_limit * price_per_gas
```
## 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:
```
price_per_gas = min(base_price_per_gas + priority_price_per_gas, max_price_per_gas)
```
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](https://www.blocknative.com/blog/eip-1559-fees) 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:
$$
\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
$$
\begin{align*}
\mathrm{base\_price\_per\_gas}_{0} &= 0 \\
\mathrm{moment}_{0} &= 0 \\
\mathrm{trend}_{0} &= 0
\end{align*}
$$
and with the following parameters:
$$
\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
$$
\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](https://www.category.xyz/blogs/redesigning-a-base-fee-for-monad) 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.