EIP-8163 Reserving the EXTENSION (0xae) opcode (Reserve `EXTENSION (0xae)` opcode)
Hegota Considered for Inclusion · EVM & execution · EIP status Review · created 2026-02-13
It reserves the opcode EXTENSION (0xae), which will never become a valid instruction on Ethereum L1, so that other EVM chains can use it as an extension prefix to add new instructions safely.
Why it is needed
Non-Ethereum EVM chains find it hard to add new instructions (opcodes) to the EVM freely today. If Ethereum L1 or another chain later decides to use an opcode with the same number for a different function, the same code will behave differently on different chains, which creates a compatibility problem. This proposal picks one opcode (0xae) and commits that it will never be made a valid instruction on Ethereum L1. Other EVM chains can then safely use this opcode as the prefix for extension instructions. Features validated there can later be brought back to Ethereum L1 through separate proposals, and innovation happens inside the EVM rather than outside it, which also strengthens the network effects of the tooling ecosystem. The behavior of Ethereum L1 itself does not change at all, and no execution client changes are needed.
What changes
Today
- An EVM chain outside L1 that adds a new opcode takes on the risk of a later conflict with L1
- No one guarantees which opcode will stay unused forever
- EVM innovation tends to happen outside the EVM because of compatibility concerns
After EIP-8163
- 0xae is guaranteed to behave like INVALID on L1 forever
- Other EVM chains can build their own extension instructions by appending bytes after 0xae
- Extension features validated on L2s and elsewhere can be backported to L1 through separate EIPs
- L1 clients do not need to change their code
Who is affected
- Ethereum L2s and alternative L1s: They can experiment with their own extension instructions using 0xae as a prefix, and how it is used is coordinated in this EIP's discussion thread.
- L1 client teams: No changes are needed because execution behavior does not change. Showing the reserved opcode name in display layers such as traces is optional.
- Ordinary users: L1 behavior does not change, so there is no change you will directly notice.
- Compiler and analysis tool developers: Tools can be built on the assumption of the same prefix convention across many chains, which widens the EVM tooling ecosystem.
In depth
Behaves exactly the same as INVALID on L1
The new opcode EXTENSION (0xae) MUST behave exactly like INVALID (0xfe) from EIP-141 on all Ethereum L1 chains, including Ethereum mainnet and testnets. Specifically, there are three requirements. First, executing EXTENSION causes an exceptional halt, which exits the current execution frame and consumes all remaining gas. Second, an EXTENSION byte in bytecode must not affect JUMPDEST analysis in any way, and the validity of every jump destination must remain unchanged. Third, if bytecode validation, static analysis, or preprocessing is introduced in the future, an EXTENSION byte must not affect that process any more than INVALID does.
Usage conventions outside L1
Outside Ethereum L1, EXTENSION may perform a meaningful operation when executed, and the specific behavior is determined by each EVM implementation. However, even in an EVM that executes EXTENSION, JUMPDEST analysis must not be affected, and the set of valid jump destinations must be identical to the one obtained on Ethereum L1. The behavior of an extension instruction is determined by interpreting the bytes that follow EXTENSION as immediate args. If 0xae is the last byte of the bytecode, execution must end with an exceptional halt, which is the opposite of the zero-padding behavior of PUSHn, EIP-8024 opcodes, CODECOPY, and EXTCODECOPY. The specific usage on each chain is coordinated in this EIP's discussion thread.
A design that leaves JUMPDEST analysis untouched
An alternative was considered in which a 0x5b after EXTENSION is excluded from the valid jump destinations and a following PUSHx is skipped, but it was not adopted. That approach would require this EIP to specify the size of the immediate args, would conflict with immediate-argument opcodes introduced by other EIPs, and would give the same bytecode different jump destination validity inside and outside L1, which breaks code portability. Therefore the design assumes that the 0xae5b sequence cannot be a valid extension instruction and that the second byte remains a valid jump destination. Sequences from 0xae60 to 0xae7f are also not valid extension instructions, with one exception: using the PUSH1 (0x60) through PUSH32 (0x7f) bytes to carry immediate args that are neutral to JUMPDEST. This is because PUSHx data is already skipped in JUMPDEST analysis. For example, 0xae605b... is a valid extension that carries the 0x5b argument in PUSH1 data, and in that case 0x5b is not a valid jump destination.
No encoding scheme is defined, and L1 multibyte opcodes are explicitly prohibited
To keep its scope as narrow as possible, this EIP does not define any extension encoding scheme. If an encoding scheme is needed, it will be introduced and discussed in a separate proposal. In addition, support for multibyte opcodes using EXTENSION on the Ethereum L1 EVM is explicitly prohibited. If multibyte opcodes become necessary on L1 in the future, they must be implemented with a different prefix. When functionality implemented with EXTENSION must be ported back to L1, a separate EIP chooses a distinct opcode. If that EIP is also adopted on the original chain, that chain will operate two ways of accessing the same functionality side by side.
Backward compatibility and client impact
EXTENSION is currently an invalid opcode on Ethereum and does not affect JUMPDEST analysis, so the behavior of existing code that contains this byte does not change. Because the behavior of Ethereum execution layer clients does not change, there is no reference implementation, and the source lists the security considerations as none. Clients may optionally update to show the name of the reserved opcode in display layers such as traces. Test cases are to be provided in the Ethereum Execution Layer Specs format.
Status and call decisions
The status of this EIP is Review, so its content may still change. On the core developer calls, ACDE #245 on 09.10 postponed the decision by two weeks and summarized that DFI is the default if the champion does not bring back real demand signals from L2s and alternative L1s. Then at ACDE #246 on 09.24, EIP-8163 was moved to Considered for Inclusion (CFI) for Hegotá. The call also included an explanation that this is a guarantee that one opcode that does nothing on L1 will not be repurposed for another use.