ECIP 1104: Mystique EVM and Protocol Upgrades Source

AuthorCody Burns

Simple Summary

Enable the outstanding Ethereum Foundation London network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Mystique to enable maximum compatibility across these networks.


Add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the London hardforks. The proposed changes for Ethereum Classic’s London upgrade include:

EIP Eth PR omit or include
3198 (BASEFEE opcode) #22837 Include
3529 (Alternative refund reduction) #22733 Include
3541 (Reject new contracts starting with the 0xEF byte) #22809 Include
1559 (Fee market change) #22837 #22896 Omit
3228 (💣 delay) #22840 and #22870 Omit

The fee market change and bomb delay are omitted at this time as they are not applicable for Ethereum Classic. The fee market change puts the network at longterm risk since as ETC currently has a capped supply and fixed emmision epocs. The bomb was disarmed in ETC code base in a previous hardfork.

EIP Summaries and expected action

  • EIP 3198 “BASEFEE opcode”: Adds an opcode that gives the EVM access to the block’s base fee.
    • For ETC, BASEFEE opcode shall return 0. This opcode is being added to ensure alignement with evm standards but will not be used on chain. The assumption being that contracts using BASEFEE sould do GASPRICE - BASEFEE to get the proper value
  • EIP 3529 “Alternative refund reduction” Remove gas refunds for SELFDESTRUCT, and reduce gas refunds for SSTORE to a lower level where the refunds are still substantial, but they are no longer high enough for current “exploits” of the refund mechanism to be viable.
    • gas price should be adjusted on respective opcodes to reflect the new EVM standard
  • EIP 3541 “Reject new contracts starting with the 0xEF byte”: Disallow new code starting with the 0xEF byte to be deployed. Code already existing in the account trie starting with 0xEF byte is not affected semantically by this change.
    • No future contracts shall be deployed on chain with 0xEF prefix. Clients should respond with an error message citing ECIP 1104 as justification of rejection.
  • EIP 1559 “Fee market change”: A transaction pricing mechanism that includes fixed-per-block network fee that is burned and dynamically expands/contracts block sizes to deal with transient congestion.
    • Undesirable to implement at this time as it would conflict with the current monetary policy set in ECIP-1017
  • EIP 3228 ”💣 delay”: Delays the difficulty bomb to show effect the first week of December 2021.
    • Not applicable to ETC due to difficulty bomb being defused

This document proposes the following blocks at which to implement these changes in the Classic networks:

  • Dec 15th 2022 on Mordor Classic PoW-testnet
  • Jan 5th 2022 on Kotti Classic PoA-testnet
  • Jan 19th 2022 on Ethereum Classic PoW-mainnet

For more information on the opcodes and their respective EIPs and implementations, please see the Specification section of this document.


To enhance the Ethereum Virtual Machine’s (EVM) capabilities, various opcodes shall be added to the Ethereum Classic networks, all of which have been in use on the Ethereum Foundation networks since early 2021.

Specific to EIP 3529: Refunds are currently only applied after transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. Hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable.

Gas tokens will become valueless.


Technical specifications for each EIP can be found at those documents respectively:


Interoperability: Establishing and maintaining interoperable behavior between Ethereum clients is essential for developers and end-user adoption, yielding benefits for all participating chains (e.g., ETH and ETC, Ropsten and Mordor, Görli and Kotti).

Immutability: None of the introduced new opcodes in the EVM has the potential to change the behavior of existing contracts; in the case where previously an arbitrary invalid bytecode would have been deployed to the network, none of them would be able to modify the state of the Ethereum Classic networks retrospectively. Adding opcodes to the EVM increases its functionality and should be considered a feature upgrade rather than a modification.

Standards Compliance: In order to guarantee that every EOF-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. New code starting with the 0xEF byte will not be deployable, and contract creation will result in a failure. However, given bytecode is executed starting at its first byte, code deployed with 0xEF as the first byte is not executable anyway.

While this means no currently executable contract is affected, it does rejects deployment of new data contracts starting with the 0xEF byte.


Adoption of the content of this ECIP requires a hard fork as it introduces changes that are not backward compatible.

The following clients with Ethereum Classic support implement the London features currently and will be able to support the Mystique upgrade:

  • Core-Geth (maintained by ETC Core)
  • Hyperledger Besu (maintained by ConsenSys)

Proposed Timeline

  • make sure draft will be ready and “pre-approved” by the core teams have some rough consensus to put it in last call (“day X”)
  • Nov 23 + 2 weeks - move to accepted unless there are issues/concerns
  • Dec 15th - Mordor activation
  • Jan 5th - Kotti activation
  • Jan 26th - Mainnet activation

Copyright and related rights waived via CC0.