---
eip: 7921
title: Skip `JUMPDEST` immediate argument check
description: All `JUMPDEST` bytes become valid `JUMPDEST`
author: William Morriss (@wjmelements)
discussions-to: https://ethereum-magicians.org/t/eip-7921-skip-jumpdest-immediate-argument-check/23279
status: Stagnant
type: Standards Track
category: Core
created: 2025-03-26
---

## Abstract

Allow `JUMP` and `JUMPI` to arrive at any byte matching `JUMPDEST` (`0x5b`), even if that byte is an immediate argument.

## Motivation

Immediate arguments are opcode parameters supplied within the code rather than the stack.
Currently determining the validity of a `JUMPDEST` requires determining which bytes are immediate arguments to other opcodes, such as `PUSH1`.
This presents several problems:

1. Codesize is a linear DoS vector because code must be preprocessed to determine `JUMPDEST` validity.
2. New opcodes with immediate arguments cannot be safely adopted.
3. `CODECOPY` data spans can invalidate subsequent `JUMPDEST`.

The rationale for this `JUMPDEST` validity check is to prevent unintended code execution.
However, almost all `JUMP` and `JUMPI` target constant destinations.
Removing this check allows larger programs and better opcodes.
Therefore, the cost of this safety check outweighs the benefit.

## Specification

When activated, all `0x5b` bytes are valid `JUMPDEST` for `JUMPI` and `JUMP` opcodes.

## Rationale

Removing the check solves several problems while reducing EVM complexity.

## Backwards Compatibility

Code previously only had one interpretation for disassembly.
With this change, a `JUMPDEST` located inside an immediate argument can cause multiple disassembly interpretations.
Usually the interpretations will converge after a few bytes but the length of such a dispute can be unbounded.
`CODECOPY` data has always been difficult to identify.
It is recommended that disassemblers provide all possible interpretations in their output in order to reveal possible underhanded functionality.

## Security Considerations

Current contracts performing dynamic jumps may gain new unintended functionality if it is possible to jump to an immediate argument containing `JUMPDEST`.
It is expected that very few contracts will become vulnerable in this way.
Most smart contract programming languages do not even allow dynamic jumps, and of those that do, few will have `JUMPDEST` in an accessible immediate argument.
Therefore it is expected that few contracts will become vulnerable, and for many of them the newly possible codepaths will contain invalid opcodes.
A static analysis tool should be developed and made publicly available to test if a contract might become vulnerable, and the program should be run for all current contracts in order to notify projects about potential security issues.
Affected programs will have ample time to migrate.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).