Summary
Monad is a highly optimized system that introduces efficiencies across all dimensions - compute, state access, and bandwidth utilization. However, the multiplier relative to legacy EVM systems is not equal across all dimensions. As a result, some opcode gas price changes are needed so that applications can unlock the full potential of the chain. To minimize the number of gas price changes, rather than adjusting the gas pricing of almost all opcodes down, Monad instead adjusts a few opcode prices up. This has the same relative effect as discounting almost all opcodes. The following costs are changed: All other costs are as on Ethereum; evm.codes is a helpful reference.These changes are covered formally in the
Monad Initial Spec Proposal
Why are changes needed?
The EVM’s current pricing model needs adaptation to support a high-performance, low-fee regime. The pricing model assigns a weight (gas amount) to each opcode based on perceived costliness to the system, then charges the user only based on the calculated sum of weights. As resource scarcity changes - and especially in the event of a completely new system - those weightings must be revised. The changes described in this page make the minimal set of adjustments to allow Monad to deliver high performance and low fees, while minimizing disruption to users and protecting the system against DOS attacks.Cold access cost
To account for the relatively higher cost of state reads from disk when compared to computation in the Monad execution client, the cost for “cold” account and storage access costs changes:
The following opcodes are impacted because of the differed gas costs:
- Account access:
BALANCE,EXTCODESIZE,EXTCODECOPY,EXTCODEHASH,CALL,CALLCODE,DELEGATECALL,STATICCALL,SELFDESTRUCT - Storage access:
SLOAD,SSTORE
Gas costs for warm account access (100 gas) and storage access (100 gas) are the same on Monad as on Ethereum.
Storage pages
Storage slots are grouped into pages of 128 consecutive slots. A slot’s page is the slot index with its lowest 7 bits stripped:mapping still resolves to its own
page, but the struct fields stored under that key share it.
SLOAD
SSTORE
SSTORE charges for page I/O and for state growth. The applicable components are summed:
State growth is counted per page as a high-water mark over the transaction, so creating a slot to
replace one cleared earlier in the same page is not charged for growth. Ethereum’s 20,000 gas for
writing a fresh slot and 2900 gas for overwriting an existing one do not apply.
Cost examples
Costs for consecutive operations on one account within a single transaction:
An EIP-2930 access list entry warms the whole page
containing the listed key, and
eth_createAccessList deduplicates storage keys by page.
Precompiles
A few precompiles have been repriced to accurately reflect their relative costs in execution.
A point is a 192-byte pair of
G1 and G2 elements, as in
EIP-1108.
Memory expansion
Memory expansion is priced linearly, and the memory a transaction can use is capped at 8 MB (8,388,608 bytes).
where is the memory size in 32-byte words. Expanding all the way to the 8 MB cap costs 131,072 gas.
Memory is counted cumulatively across call frames: the memory available to a child call is 8 MB
minus the memory already used by the current call and its parents. Memory returns to the pool
once a call returns.
Exceeding the limit halts the call frame exceptionally, consuming all the gas that frame
was given and reverting its state changes. From the caller’s perspective this is
indistinguishable from an ordinary out-of-gas.
These changes are activated in the
MONAD_NINE revision.