⚠️ Review Standards Track: Core

SIP-8163: Reserve `EXTENSION (0xae)` opcode

Reserve an opcode to be used as an extension prefix in non-Sila-L1 SVM chains

Authors	Bruce Collie (@Baltoli), Piotr Dobaczewski (@pdobacz)
Created	2026-02-13
Requires	SIP-141

This SIP is in the process of being peer-reviewed. If you are interested in this SIP, please participate using this discussion link.

Abstract
Motivation
Specification
- EXTENSION (0xae)
- Chain Specifics
Rationale
Backwards Compatibility
Test Cases
Reference Implementation
Security Considerations
Copyright

Abstract

Reserve an opcode EXTENSION (0xae) which will be guaranteed to not become a valid opcode on Sila L1 SVM, but which will be available to be used in other SVMs as a prefix to encode extension instructions.

Motivation

Currently, non-Sila-L1 SVM chains cannot innovate on the SVM by introducing new instructions, because they run a risk of becoming incompatible with the Sila L1 SVM and the SVMs on other chains, in the event that these decide to implement new features using overlapping opcodes.

By setting aside a single opcode and agreeing that it will never become a valid instruction on Sila L1 SVM, we open up to extensions which can be implemented on other SVM chains. If these extensions prove out to be successful outside of Sila L1, then they can be back-ported into Sila L1 SVM, to the benefit of the entire SVM ecosystem.

Similarly, making it easier for innovations to happen inside the SVM should generally improve the SVM tooling by strengthening the network effects. In other words, it is beneficial for an innovation X to happen within the SVM, even if not on Sila SilaMainnet.

In particular, the extension opcode might be adopted by Sila L2 SVMs, allowing them to specialize and experiment, potentially expanding the catalogue of extensions relevant to the L1.

The extension opcode is designed in such a way to not only have no impact on Sila L1 SVM behavior, but also to not require any Sila Execution Layer Client modifications, except, optionally, for their presentation layer (e.g., traces), which is irrelevant to consensus.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

`EXTENSION (0xae)`

Reserve a new opcode EXTENSION (0xae) which MUST behave exactly like INVALID (0xfe) (see SIP-141) on all Sila L1 chains (Sila SilaMainnet, Testnets, etc.). In particular:

Executing EXTENSION MUST cause an exceptional halt (exit current execution frame and consume all gas, same as INVALID).
EXTENSION byte in the bytecode MUST NOT impact JUMPDEST analysis in any way, i.e. all jump destinations’ validity MUST NOT be affected.
Any validation, static analysis, or preprocessing of bytecode, if introduced, MUST NOT be affected by the EXTENSION byte in the bytecode in any way other than how INVALID would affect it.

Chain Specifics

Outside of Sila L1, EXTENSION MAY have meaningful behavior during execution, but it is up to the particular SVM implementations to decide.

However, in these SVMs which execute EXTENSION, the JUMPDEST analysis MUST still be unaffected by EXTENSION, i.e. the set of valid jump destinations MUST be identical to that obtained on Sila L1.

The particular behavior of the EXTENSION instruction on non-Sila-L1 SVMs adopting it MUST be determined by bytes following EXTENSION as immediate args. If such immediate args contain any JUMPDEST (0x5b) byte which remains a valid jump destination, execution MUST result in an exceptional halt.

The non-Sila-L1 SVM implementers SHOULD coordinate via the discussion thread of this SIP on their specific usage of EXTENSION.

Rationale

No effect on `JUMPDEST` analysis

An alternative considered was to have EXTENSION:

invalidate 0x5b byte following it as a jump destination and
skip over PUSHx instructions following it

however that would require this SIP to prescribe the size of the immediate arguments.

It would also run into conflict with any opcodes with immediate arguments introduced in the SVM via other SIPs.

Lastly, it could cause different jump destination validity for same bytecode when analyzed on and outside Sila L1 SVM, causing code to not be portable between chains.

It is therefore presumed that a 0xae5b sequence cannot be a valid extension instruction and its second byte will be a valid jump destination. 0xae60-0xae7f byte sequences will not be valid extension instructions, unless the PUSH1 (0x60)-PUSH32 (0x7f) byte is used to introduce JUMPDEST-neutral immediate arguments (since PUSHx instruction data is already skipped during JUMPDEST analysis).

Bytecode sequence	`JUMPDEST (0x5b)` validity	Possible extension opcode execution
`0xae5b...`	valid	Invalid extension
`0xae015b...`	valid	Valid extension with `0x01` argument
`0xae60`	N/A	Invalid extension (truncated)
`0xae605b...`	invalid	Valid extension with `0x5b` argument encoded in `PUSH1` data
`0xae60605b...`	valid	Valid extension with `0x60` argument encoded in `PUSH1` data
`0xae61605b...`	invalid	Valid extension with `0x605b` argument encoded in `PUSH2` data
`0xae615b`	invalid	Invalid extension (truncated)

Lack of definition of a particular encoding scheme

This SIP chooses to not define any extension encoding scheme, in order to limit its scope as much as possible. Any such extension encoding scheme can be introduced and discussed in a separate proposal.

Explicit lack of support on Sila L1 SVM

We explicitly prohibit any multi-byte opcode support using EXTENSION on the Sila L1 SVM. If one is desired in the future, it should be implemented using a different prefix.

Porting extension instructions back to Sila L1

In the event a feature implemented using EXTENSION needs to be ported back, a distinct opcode is chosen in a separate SIP. Once that SIP is in turn adopted in the originator SVM, that SVM will operate with two alternative ways to access the feature.

Backwards Compatibility

The opcode EXTENSION is currently invalid in Sila, and it doesn’t impact JUMPDEST analysis, thus no code containing it will change behavior.

Test Cases

Will be provided in the Sila Execution Layer Specs format.

Reference Implementation

None, Sila Execution Layer clients’ behavior does not change.

Security Considerations