Ethereum Classic Activates Phoenix Upgrade at Block 10,500,839

Ethereum Classic activated its Phoenix hard fork at block 10,500,839 on May 31, 2020 in U.S. Central Time, importing the protocol changes Ethereum had introduced through Istanbul. The block-triggered upgrade mattered because it narrowed a technical gap between two separately governed networks that shared the Ethereum Virtual Machine, making it easier for developers and infrastructure operators to support comparable behavior across both chains.

The activation date requires a timezone caveat. ETC Core’s confirmation, posted on June 1, identified the event as May 31 in Central Time, while some later Ethereum Classic timelines label it June 1. The durable fact is the activation height: 10,500,839. A May 14 ETC Labs notice had estimated that height would arrive around June 3, illustrating why hard-fork schedules based on block production can move against calendar forecasts.

What Phoenix changed

ECIP-1088 specified six Istanbul-derived changes. Phoenix added the BLAKE2 compression-function precompile under EIP-152; reduced gas costs for alt_bn128 elliptic-curve operations under EIP-1108; exposed the chain identifier to contracts through the CHAINID opcode under EIP-1344; repriced state-trie-dependent operations under EIP-1884; reduced the gas charged for nonzero transaction calldata under EIP-2028; and reworked storage gas accounting under EIP-2200.

Those changes were technical, but their institutional consequence was straightforward. Smart-contract developers could target a more closely aligned execution environment, while exchanges, wallets, miners and node providers had a single, known activation height around which to coordinate software. ECIP-1088 described the change as backward-incompatible and therefore requiring a hard fork. It listed Core-Geth, Hyperledger Besu, Multi-Geth and OpenEthereum as implementations capable of supporting Phoenix, while warning that Geth Classic would not receive the upgrade.

Compatibility did not mean that Ethereum and Ethereum Classic became one network. Their ledgers, native assets, mining activity and governance remained separate. Phoenix instead aligned a defined set of virtual-machine and gas-schedule rules. That distinction matters: protocol parity can reduce engineering friction, but it does not by itself establish application migration, liquidity, user adoption or security equivalence.

A tested replacement for an earlier plan

Phoenix was also the product of a reset in Ethereum Classic’s upgrade process. Earlier Aztlan and PhoenixFix specifications were rejected after testnet work exposed security and stability concerns. ECIP-1088 took the narrower route of implementing the Istanbul set directly. ETC Labs reported before mainnet activation that Mordor testnet had upgraded at block 999,983 on March 9, 2020 and Kotti testnet at block 2,200,013 on April 15, 2020.

That history made the May 31 activation more consequential than a routine feature release. It showed the network’s developers replacing a disputed bundle, testing the substitute on two networks, and coordinating a consensus-rule change at a fixed mainnet height. Phoenix followed Atlantis and Agharta, completing a sequence intended to restore close EVM compatibility with Ethereum’s preceding upgrades.

For market participants, the verifiable signal on May 31 was operational rather than directional. The record supports that new consensus rules activated and that service providers needed compatible clients. It does not establish that Phoenix caused any ETC price move, and no price-performance claim is made here.

Later context

Reports published after May 31 said some OpenEthereum nodes encountered synchronization trouble and that an emergency patch followed. That later evidence does not change the event-day finding that Phoenix activated at block 10,500,839; it does show that activation and smooth operation across every client are different claims.