Interstellar EVM Upgrade (VIP-255)

VIPs
1

Proposal Summary

Interstellar marks the next major leap forward in the VeChain Renaissance, further advancing VeChainThor’s technical foundations and opening the network more broadly to the global Web3 ecosystem. Building upon Galactica’s EVM modernisation and Hayabusa’s transformation of consensus and tokenomics, VIP-255 begins the Interstellar phase by introducing compatible execution-layer improvements from Ethereum’s Cancun, Prague and Osaka releases—expanding developer capabilities, improving smart-contract portability and strengthening network resilience for the future.

The upgrade introduces:

  • New EVM opcodes for transient storage, memory copying and computational efficiency

  • Cryptographic precompiled contracts supporting BLS12-381 and secp256r1

  • Improved access to historical block information

  • Updated transaction gas and block-size safeguards

  • Revised SELFDESTRUCT behaviour aligned with modern EVM standards

These changes improve developer compatibility, expand available functionality, and enhance overall network robustness.

Motivation

Interstellar is a proposed network upgrade (hardfork) that modernises the VeChainThor EVM. It is designed to deepen compatibility with the wider Ethereum ecosystem, expand developer capabilities, improve smart-contract portability and strengthen network resilience.

VIP-255 addresses this by adopting key improvements from multiple Ethereum releases in a single upgrade, including:

  • Transient storage for efficient temporary state handling

  • MCOPY for faster memory operations

  • BLS12-381 for advanced cryptographic use cases

  • secp256r1 for modern authentication and hardware-backed security

  • Improved execution limits for better predictability and stability

This consolidated upgrade significantly reduces the EVM compatibility gap while minimising the need for multiple future hardforks.

Proposed Technical Upgrades

New EVM Opcodes

  • EIP-1153: Transient Storage Opcodes
    Introduces TLOAD and TSTORE, providing gas-efficient temporary storage that does not persist permanently on-chain.

  • EIP-5656: MCOPY
    Introduces a dedicated instruction for efficiently copying data between memory locations.

  • EIP-6780: Updated SELFDESTRUCT Behaviour
    Restricts contract deletion through SELFDESTRUCT, reducing unexpected state changes and aligning VeChainThor with modern EVM behaviour.

  • EIP-7939: Count Leading Zeros
    Introduces the CLZ opcode for more efficient mathematical operations, compression, bitmap processing and zero-knowledge applications.

Cryptographic Precompiled Contracts

  • EIP-2537: BLS12-381 Curve Operations
    Adds efficient cryptographic operations used by zero-knowledge systems, aggregated signatures and interoperability protocols.

  • EIP-7951: secp256r1 Curve Support
    Adds native verification for signatures produced by widely used secure hardware and authentication standards, including Apple Secure Enclave, Android Keystore, FIDO2 and WebAuthn.

  • EIP-7823: MODEXP Input Limits
    Limits the base, exponent and modulus inputs of the MODEXP precompile to 1,024 bytes each, reducing consensus risk from impractically large inputs.

  • EIP-7883: MODEXP Gas-Cost Increase
    Updates MODEXP gas costs to reflect its computational requirements more accurately.

Core Protocol Improvements

VeChainThor-Specific Implementation

VeChainThor has architectural differences from Ethereum, including multi-clause transactions, a dual-token model and its own block-ID structure. VIP-255 preserves these characteristics while adopting the applicable EVM functionality.

The principal differences include:

  • Transient storage is scoped to an individual clause and cleared when that clause completes.

  • The revised SELFDESTRUCT rule evaluates contract creation and destruction within the same clause.

  • Historical block queries return VeChainThor block IDs using VeChainThor’s existing state architecture.

  • Blob-carrying transactions and blob-related opcodes are not introduced.

  • Precompiled-contract addresses continue to follow VeChainThor’s existing account-code convention.

Developers porting contracts from Ethereum must account for these differences. The complete implementation requirements are documented in VIP-255.

VeChainThor’s existing multi-clause transactions and fee-delegation functionality remain available and unchanged.

Impact to Stakeholders

VET and VTHO Holders

No action is required from ordinary VET or VTHO holders. This proposal does not change the tokenomics of either VET or VTHO, including:

  • VET or VTHO supply

  • VTHO issuance or burning rules

  • Staking rewards

  • Validator and Delegator reward allocation

  • StarGate NFTs

  • Governance voting power

  • Existing wallet addresses or token contracts

No token migration, asset swap or contract-address change is required.

Validators, Node Operators and Infrastructure partners

Validators, public-node operators, exchanges, custodians and other infrastructure providers operating VeChainThor nodes will be required to deploy the compatible Thor client release before the announced activation block. Nodes that are not upgraded in time will no longer follow the canonical VeChainThor chain.

The required Thor version, release notes, upgrade instructions and activation block will be communicated separately to allow stakeholders to prepare for the network upgrade.

The upgrade does not change VET or VTHO balances, token contracts or deposit addresses, and no token migration or asset swap is required. Exchanges and custodians may temporarily suspend deposits and withdrawals around the activation period in accordance with their standard network-upgrade procedures.

Your Vote Matters

As with every VeChainThor upgrade, community consensus through a successful public vote is essential before onchain activation. This is your opportunity to influence the next evolution of the network. Cast your vote and help define the next era of VeChain.