# MIP-7: Extension Opcodes

**URL:** <https://forum.monad.xyz/t/mip-7-extension-opcodes/387>\
**Category:** MIPs\
**Created:** [January 29, 2026, 9:57am UTC](https://forum.monad.xyz/t/mip-7-extension-opcodes/387 "2026-01-29T09:57:15Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![pdobacz](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/pdobacz/32/171_2.png) [@pdobacz](https://forum.monad.xyz/u/pdobacz)\
**Post date:** [February 9, 2026, 10:00am UTC](https://forum.monad.xyz/t/mip-7-extension-opcodes/387/3 "2026-02-09T10:00:58Z")

</div>

I would recommend that an [EIP-8024](https://eips.ethereum.org/EIPS/eip-8024#specification)-like approach to JUMPDEST-analysis is taken.

### Problem statement

Let’s call the current approach “JUMPDEST-analysis expanding”, because we’re expanding the rules of the analysis, to cover `0xEE` immediate arguments.

The interaction of current JUMPDEST-analysis expanding MIP-7 and EIP-8024 is broken:

Consider the bytecode: `0xE6 0xEE 0x60 0x5B`. Here we compare how its JUMPDEST analysis and execution unfold:

| EVM | Jumpdest Analysis | Execution |
| --- | --- | --- |
| **Osaka** | `0x5B` is an invalid jumpdest as it is a PUSH1 argument: **JD✗** | `invalid`, `invalid`, `PUSH1 0x5B` |
| **EIP-8024** | `0x5B` is an invalid jumpdest as it is a PUSH1 argument: **JD✗** | `DUPN-0xEE` (valid), `PUSH1-0x5B` |
| **MIP-7** | `0xEE` skips `0x60` making `0x5B` a valid jump destination: **JD✓** | `invalid`, `EXTENSION-0x60`, `JUMPDEST` |
| **Both** | `0xEE` skips `0x60` making `0x5B` a valid jump destination: **JD✓** | `DUPN-0xEE` (valid), `PUSH1-0x5B` |

**Osaka** and **MIP-7** rows are less of a concern, as they contain invalid operation in the bytecode. However, code which is correct under **EIP-8024** and executes as a `DUPN-0xEE` and `PUSH1-0x5B`, with the argument of the push being an invalid jump destination, becomes something different when combined with MIP-7.

A more severe variant is `0xE6 0xEE 0x60 0x60 0x5B`, where MIP-7 causes the jump destination to vanish. `0xE6 0xEE 0x7F ... 0x5B` demonstrates that the effect can cascade across the entire remainder of the bytecode.

### Proposed solution

In general, let’s declare that the extension opcode `0xEE` (in MIP-7 but also in whatever EIP we’re going to put up) **is not altering JUMPDEST analysis** in any way, that is, the set of valid jump destinations remains the same with or without MIP-7, for all bytecodes.

One way to do this is to adopt the approach EIP-8024 is taking, discussed as [2.2.1 in here](https://ethereum-magicians.org/t/evm-immediates/25605). The advantages of this are:

1. Increases the chance of success of the MIP-7’s EIP counterpart, because it dodges the subject of backwards comptibility of JUMPDEST-analysis, just like EIP-8024 did
2. Increases the cross-compatiblity of the bytecode between EVMs adopting MIP-7 and others. Imagine bytecode which is aware of the EVM it’s running in (think a bundler which runs a hypothetical `0xEE-0x60` combo on a chain which recognizes this extension and jumps over it otherwise). It would not work cross chain if `0xEE 0x60 0x5B` combination was treated with expanded JUMPDEST-analysis
3. Consistent with EIP-8024, which I assume Monad is going to adopt anyway, if it goes into Amsterdam
4. Still bytecode-efficient compared to [2.2.3 in here](https://ethereum-magicians.org/t/evm-immediates/25605), and cleaner than 2.2.2 therein

In case \>1byte immediate arguments are needed (or variadic) for the extension, [approach 2.2.3 in here](https://ethereum-magicians.org/t/evm-immediates/25605) still can be used. MIP-7’s EIP counterpart may not prescribe the concrete variant, but it should require that the extension opcode doesn’t alter JUMPDEST analysis generally.

---

_[View the full topic](https://forum.monad.xyz/t/mip-7-extension-opcodes/387)._