Monad Monad Gas Limits and Fee Calculation
Transaction fees on this EVM-compatible Layer 1 blockchain cover the full gas limit declared before execution. An oversized wallet limit therefore increases the MON charge when the per-gas price stays unchanged.
Updated:- Fee Asset
- MON, the network’s native token.
- Charged Quantity
- The transaction’s declared gas limit, including any gas units execution does not consume.
- Network Fee Formula
-
gas_limit * price_per_gas, expressed in MON when the price uses MON per gas unit. - Minimum Base Fee
-
100 MON-gwei per gas unit, equivalent to
100 * 10^-9 MONper gas unit. Sustained network load can raise the base fee, and priority fees can increase the effective price.
Capacity Accounting Before Execution
Asynchronous execution lets validators agree on blocks before the execution client processes their transactions. Validators assess block capacity using declared gas limits, without needing measured gas consumption. Charging only for consumption would underprice transactions reserving large limits but performing little work. Charging for the reserved capacity addresses this denial-of-service risk.
Category Labs’ Monad Initial Specification Proposal, version 2.0.1 (November 19, 2025), specifies the gas-limit basis for both base and priority fees. The protocol burns the base-fee portion and includes the priority portion in the block validator’s reward.
The Gas Limit and the Price Ceiling
The gas limit caps permitted work, while the maximum price caps the charge per gas unit. For EIP-1559 type 2 transactions, the block supplies the base fee. The sender selects a priority-fee bid and a maximum price per gas unit:
price_per_gas = min(base_price_per_gas + priority_price_per_gas, max_price_per_gas)
The maximum price limits the effective per-gas price without determining it on its own. Inclusion also requires that effective price to meet the block’s base fee. A low price ceiling can therefore prevent inclusion, even when the account holds enough MON.
Fee Settings and Their Consequences
| Fee-Setting Choice | Cost and Inclusion Conditions |
|---|---|
| Explicit Limit for a Known Fixed Requirement | Developers can supply the known requirement before handing the transaction to the wallet, avoiding the estimation RPC request. A simple native MON transfer requires 21,000 gas; token transfers and swaps vary by contract. |
| Wallet Estimation for a Contract Call |
When
eth_estimateGas
encounters a reverting call, some wallets, including MetaMask, may substitute a very high limit. This fallback supplies a chargeable gas limit without confirming the call can succeed.
|
| Gas Limit Above the Execution Requirement | Unused gas units remain chargeable. At an unchanged gas price, raising this limit increases the MON fee. |
| Gas Limit Below Intrinsic Gas | The transaction does not qualify for inclusion because its limit cannot cover the required intrinsic gas. |
| Higher Type 2 Priority-Fee Bid | At the same base fee, a higher priority bid can raise the effective gas price. The signed maximum price still bounds that increase. |
| Type 2 Maximum Price Below the Block Base Fee | The resulting gas bid cannot meet the block’s base-fee check, so the transaction cannot qualify for inclusion. |
| Legacy Type 0 or Type 1 Pricing |
The version 2.0.1 specification uses
gasPrice
directly as the bid for these formats. Its payment rule still multiplies that bid by the full gas limit.
|
| Other Validity Requirements | Block validity also requires a matching account nonce and a gas limit within the network’s per-transaction maximum. |
Gas Affordability and Execution Reversion
Reserve Balance rules let consensus assess gas affordability using its delayed view of account state. Those rules distinguish gas spending from MON transferred during execution. An included transaction can still revert when its value transfer exceeds the account balance available during execution. The sender pays the gas charge for that included transaction even when the intended transfer fails.
