Gas on Monad

Gas pricing is the same on Monad as on Ethereum.

There is one difference: the gas charged for a transaction is the gas limit, not the gas used. This behavior is on Monad Testnet and is being actively evaluated for mainnet.

Quick Hits

Feature	Detail
Opcode pricing	All opcodes cost the same amount of gas as on Ethereum, see reference. For example, ADD costs 3 gas.
EIP-1559	Monad is EIP-1559-compatible; base fee and priority fee work as on Ethereum. See this section for details.
Base fee	Hard-coded to 50 monad gwei (i.e. 50 * 10^-9 MON) per unit of gas on testnet. This will become dynamic in the future.
Transaction ordering	Default Monad client behavior is that transactions are ordered according to a Priority Gas Auction (descending total gas price).
Gas charged	The gas charged for a transaction is the gas limit. That is: total tokens deducted from the sender's balance is value + gas_price * gas_limit. This is a DOS-prevention measure for asynchronous execution, see discussion below.

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. When a user signs a transaction, the transaction specifies a gas limit and a price limit (tokens-per-gas limit). Since tokens_spent = tokens_per_gas * gas, the user is signing off on a maximum amount of native tokens they are willing to spend on the transaction.

Gas price detail

This article provides a good explanation of EIP-1559 gas pricing. A summary follows.

Gas price is expressed using three parameters: base_price_per_gas, priority_price_per_gas, and max_price_per_gas.

• base_price_per_gas is a network-determined parameter. 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
• When a transaction is included, the price_per_gas paid is the minimum of max_price_per_gas and base_price_per_gas + priority_price_per_gas
• 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.

On Monad Testnet, these dynamics still apply, but base_price_per_gas is set to a static value of 50 monad gwei.

This means that price_per_gas is the minimum of max_price_per_gas and 50 * 10^9 wei + priority_price_per_gas; users can set either parameter to achieve the same effect.

Why charge gas limit rather than gas used?

Asynchronous execution means that leaders build blocks (and validators vote on block validity) prior to executing the transactions.

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.

The pricing formula is being actively discussed and may change before mainnet.

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.

warning

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 Testnet where the 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.