Opcode Pricing

​

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:

• Cold access to state
• A few precompiles
• Memory expansion

All other costs are as on Ethereum; evm.codes is a helpful reference.

​

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

​

Precompiles

A few precompiles have been repriced to accurately reflect their relative costs in execution. ∗: Per input/operation, as defined in the respective precompile specification

​

Memory expansion

Memory expansion is priced linearly, and the memory a transaction can use is capped at 8 MB (8,388,608 bytes). where $w$ 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.