Abstract
This MIP proposes a new opcode EXTENSION (0xAE) 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. It defines the encoding scheme for extended instructions, including the extension selector and two styles for encoding immediate arguments, and aligns with EIP-8163, which reserves the same opcode on Ethereum L1.
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-4 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.
EIP-8163 reserves the EXTENSION (0xAE) opcode on Ethereum L1 specifically to enable non-L1 EVM chains to safely experiment with extensions without risking future incompatibility. This MIP adopts that reservation for Monad.
Specification
Extended Opcode Encoding
The EXTENSION opcode (0xAE) MUST be immediately followed by a 1-byte extension selector. The extension selector MUST NOT be 0x5B (JUMPDEST) or in the range 0x60-0x7F (PUSH1-PUSH32). An extension selector in this excluded range MUST cause an exceptional halt, consuming all remaining gas.
Define extended opcode as the 2-byte sequence 0xAE XX.
Until a future MIP assigns meaning to a given selector, executing any extended opcode MUST behave as if INVALID (0xFE) had been executed.
Argument Encoding
If a particular extension requires immediate arguments, future MIPs MUST use one of the two encoding styles:
Restricted-Range Immediates
Similar to EIP-8024, argument bytes follow the extended opcode directly:
0xAE XX a1 a2 ...
Each argument byte MUST NOT be 0x5B or in the range 0x60-0x7F. The number of argument bytes is fixed per extension selector and MUST be specified by the MIP that defines the extension.
PUSH-Prefix Immediates
Argument bytes are framed by a PUSHx byte (0x60-0x7F) that follows the extended opcode:
0xAE XX PUSHx b1 b2 ... bn
The PUSHx byte determines the argument length (n = opcode − 0x5F). The full byte range 0x00-0xFF is available.
In either encoding style, an extended opcode followed by incorrectly encoded bytes MUST behave as if INVALID (0xFE) had been executed.
Rationale
Several alternative designs were considered:
No Extension
In this design, new implementation-specific opcodes are simply allocated to unused bytes in the existing EVM opcode space. This design is simple from an implementation perspective, but risks collision with future Ethereum upgrades. If such a collision were to occur, it is likely that a more complex resolution would be required, or that Monad would have to accept a permanent break of compatibility with Ethereum. A single reserved extension opcode reduces this risk substantially.
Selector Encoding like PUSH1
The currently accepted approach to introducing multibyte opcodes is to do so in a JUMPDEST analysis preserving way, following the precedent of EIP-8024. JUMPDEST analysis is unaffected by EXTENSION and by either of its argument encodings.
An earlier version of this MIP proposed that EXTENSION carry a single-byte immediate operand (structurally identical to PUSH1), forming a two-byte 0xAEXX instruction and skipping over the XX byte during JUMPDEST analysis. This conflicts with JUMPDEST analysis preservation and compromises code portability across chains.
Stack-based
Rather than encoding extension arguments as immediate data, an alternative would be to pop the implementation-specific opcode from the stack. Doing so has the advantage of simpler upstream compatibility. The main downside of this approach is performance: popping a 32-byte word from the stack, interpreting it as an opcode, and dispatching on it would exit the hot path of typical interpreter designs. However, it is worth noting that the Monad VM’s native-code compiler could trivially inline the presumed common pattern of PUSH1 0xXX; EXTENSION with zero overhead.
Additionally, stack-based dispatch would allow opcode selection to come from runtime data or computation, preventing static analysis of stack contents and extension behavior, and hindering EVM execution optimization.
Gas Costs
No gas costs for individual extension opcodes are proposed by this MIP. Any invalid or undefined extension opcode should cost the same as executing INVALID (consume all gas and revert).
Choice of Immediates Encoding Style
This MIP leaves the choice of immediates encoding style to the particular selector. Restricted-range immediates are compact and suitable for short arguments that do not require the full byte range. PUSH-prefix immediates allow arbitrary byte values at the cost of an extra framing byte.
Precompiles
Some features could potentially be implemented either as new opcodes or as precompiles: adding precompiles is less risky from a collision perspective, but calling precompiles incurs additional overhead for ABI compatibility that may not be viable for all features.
Backwards Compatibility
The opcode 0xAE is currently invalid in both Ethereum and Monad. Since JUMPDEST analysis is unaffected by EXTENSION, no existing code behavior changes.
Security Considerations
Because JUMPDEST analysis is unaffected by EXTENSION, the risks associated with divergent jump analysis between Monad and Ethereum are mitigated. On both chains, 0xAE followed by 0x5B results in the 0x5B remaining a valid jump destination.
References
- EIP-8163: Reserve EXTENSION (0xAE) Opcode
- EIP-8024: Backward Compatible SWAPN, DUPN, EXCHANGE
- Monad Initial Specification
Copyright
Copyright and related rights waived via CC0.