MIP-7: Extension Opcodes

baltoli · January 29, 2026, 9:57am

MIPS/MIP-7.md

main

---
mip: 7
title: Extension opcodes
description: Add a reserved two-byte opcode family for implementation-defined extension opcodes
author: Category Labs
category: Core
created: 2026-01-28
---

## Abstract

This MIP proposes a new 2-byte opcode `EXTENSION` (`0xEEXX`, where `XX` is a single byte immediate operand) that can be used to extend the Monad VM with new opcode-level features, while minimizing the risk of collision with future changes to the Ethereum execution layer.

## Motivation

At present, bytecode execution in the Monad VM is fully Ethereum-compatible: all Ethereum opcodes are supported, and there are no additional opcodes implemented by Monad that are not present in Ethereum. However, in the future, new features will be proposed for Monad that warrant the addition of new opcodes. For example, an early version of [MIP-3](./MIP-3.md) specified the addition of an opcode to inspect the state of Monad's reserve balance mechanism. While that MIP rejected the opcode-based design in favour of a precompile, the design decisions discussed in relation to that early version prompted this MIP.

## Specification

Add a new opcode `0xEE` that carries a single-byte immediate operand (structurally identical to `PUSH1`). The immediate operand is intended to encode a Monad-specific opcode value. No such opcodes are proposed by this MIP: until amended by future MIPs, all extension opcodes should behave as if `INVALID` had been executed.

This file has been truncated. show original

This MIP proposes a generic scheme by which new opcodes can be added to the Monad VM, while minimising the risk of collisions with future Ethereum changes.

pdobacz · February 4, 2026, 1:57pm

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:

In 0xEE5B the 0x5B is not a valid jump destination
In 0xEE605B the 0x5B is a valid jump destination
In 0xEE615B5Bboth 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.

Topic		Replies	Views
Updates and Announcements Announcements	1	334	September 26, 2023
MIP-5: Fusaka EIP Activation MIPs	1	93	January 21, 2026
MIP-4: Reserve Balance Introspection MIPs	6	242	January 29, 2026
About the MIPs category MIPs	0	55	June 18, 2025
Monad Initial Specification Proposal Protocol	7	1180	October 24, 2025

MIP-7: Extension Opcodes

Related topics