# 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:** 2

<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 4, 2026, 1:57pm UTC](https://forum.monad.xyz/t/mip-7-extension-opcodes/387/2 "2026-02-04T13:57:53Z")

</div>

Disclaimer: I’m currently analyzing the JUMPDEST situation, and might propose a different approach to it (that there are reasons for the extension opcode to be JUMPDEST-analysis neutral).

This is more of an editorial suggestion to current approach:

In the `Jumpdest Analysis` section, the rule is too weak. In current form `0xEE605B` would cause the `0x5B` to be an invalid jump destination. I think it should read:

> As for `PUSH1` opcode, an immediate data byte following a `0xEE` byte is skipped over during JUMPDEST analysis.

In particular:

1. In `0xEE5B` the `0x5B` is not a valid jump destination
2. In `0xEE605B` the `0x5B` is a valid jump destination
3. In `0xEE615B5B`both `0x5B`’s are valid jump destinations etc.

For completeness: we’re unfortunate EIP-8024 is considered for Amsterdam, complicating things. If it goes in, `0xE6EE5B`, `0xEEE65B` (and similar) must be dealt with.

---

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