EIP-7686 Stagnant EL

Linear EVM memory limits

Authors:

Adjust memory limits and gas limits of sub-calls to create a clear linear bound on how much total memory an EVM execution can consume

Timeline

Glamsterdam

Carl Beekhuizen

Declined · Dec 18, 2025 · ACDE #226

Dec 18, 2025 · ACDE #226

Proposed

EIP Created Apr 15, 2024

Key Benefits

● Provides a clear linear upper bound on total memory a transaction can consume.
● Simplifies EVM memory pricing by removing the quadratic term from the cost function.
● Makes worst-case resource usage easier to estimate for EVM executions and client operators.
● Aligns call-gas limits with memory usage, avoiding unbounded memory growth across nested sub-calls.

Trade-offs & Considerations

No trade-offs documented yet.

Stakeholder Impact

End Users

For ordinary users this change is largely invisible, mainly constraining unusually memory-heavy transactions that approach gas and resource limits.

Application Developers

Contract developers may review patterns that access high memory with little gas, though typical applications fit within the new limits.

Wallet Developers

Wallets that implement their own gas estimation must update memory-cost logic; others inherit the behavior change from underlying nodes.

Tooling / Infrastructure

Gas analyzers, simulators, and tracing tools must update their memory cost and call-gas models to match the new linear rules.

Layer 2s

EVM-compatible rollups mirroring mainnet gas rules would implement the new memory limit and pricing to maintain behavior compatibility.

Stakers & Node Operators

Node operators benefit from a linear bound on per-transaction memory usage, simplifying capacity planning and reducing worst-case memory exhaustion risk.

CL Client Developers

Consensus-layer clients see minimal direct impact; they mainly ensure testing and fork configuration align with updated execution-layer behavior.

EL Client Developers

Execution-layer clients must update EVM memory-cost calculation, enforce the new per-context memory cap, and adjust call-gas logic accordingly.

Abstract

Add a hard memory limit equal to the gas limit of the current context. Make the maximum gas cost of a sub-call depend on the memory used in the current context. The two rules together ensure that a transaction with N gas can use at most N bytes of memory.

Motivation

Today, memory pricing rules are complicated: we have the quadratic cost for expanding memory as well as the 63/64 rule for how much gas can go into a child call. This also makes it extremely hard to calculate a maximum possible amount of memory required to process a given EVM execution.

The rules in this post simplify these rules, and add a new hard limit: an EVM execution with N gas can require at most N total bytes of memory to process. This limit is tight: there are easy ways for an N-gas call to use N - O(1) bytes of memory.

Specification

Change memory_cost from:

memory_size_word = (memory_byte_size + 31) / 32
memory_cost = (memory_size_word ** 2) / 512 + (3 * memory_size_word)

To:

memory_size_word = (memory_byte_size + 31) / 32
memory_cost = 3 * memory_size_word

Additionally, if a memory expansion would lead to memory_byte_size strictly exceeding the current call's initial gas limit, revert with an error.

When making any type of call, change the maximum gas limit from the current EIP-150 definition:

def max_call_gas(gas):
    return gas - (gas // 64)

To:

def max_call_gas(gas, memory_byte_size):
    return gas - max(gas // 64, memory_byte_size)

Rationale

With this EIP, there is a simple EVM implementation that can process an N-gas call using an N-byte bytearray as memory: allocate all bytes to the current context, when doing a child call use the remaining memory starting from the position memory_byte_size for the child call's memory, and so on recursively.

Having this clean invariant is useful for EVM implementations, especially EVM implementations in constrained environments (eg. ZK-SNARK provers).

The 3 gas per word memory expansion cost is retained because it is equivalent to MCOPY, and so the operation of clearing memory at the end of a child call (cheap in regular machines, but more expensive in ZK-SNARKs and other unusual contexts) can be implemented with the same logic as that used to implement the MCOPY opcode itself.

The 63/64 rule is maintained in order to maintain the current de-facto call stack depth limit of roughly 1 + log((gaslimit + 6300) / 6400) / log(64/63) = 537.

Backwards Compatibility

It is theoretically possible for EVM code that works today to fail to work under this new EIP, if that code accesses a high index in memory but is called with a low gas limit. However, almost all EVM execution consumes far more code than it uses bytes of memory. For example, for a call to cause even a single state change, it must have at least 5000 gas. This would allow it 5000 bytes of memory, which is greater than that used by almost all applications. More complex applications would have even higher limits.

Security Considerations

No security concerns were raised.