Ethereum Classic activated its Agharta hard fork at block 9,573,000 at 10:26 p.m. Pacific Standard Time on January 11, 2020, corresponding to 06:26 UTC on January 12. The upgrade imported selected changes from Ethereum’s Constantinople and Petersburg releases, extending Ethereum Classic’s virtual machine while making its execution rules more compatible with those used by Ethereum.
The timezone distinction matters for this archive. Ethereum Classic’s historical timeline and the ETC Cooperative record the upgrade under January 11, while contemporaneous reporting used the January 12 UTC date. The protocol trigger itself was unambiguous: clients began enforcing the new rules at block 9,573,000.
Three opcodes changed the execution environment
ECIP-1056, the final Agharta specification, introduced three features. EIP-145 added the SHL, SHR and SAR bitwise-shifting instructions, giving smart contracts direct operations for shifting binary values. EIP-1014 added CREATE2, which allowed a contract address to be calculated from the deploying address, a salt and initialization code before the contract was deployed. EIP-1052 added EXTCODEHASH, allowing contracts to retrieve the hash of another account’s code without first copying all of that code into memory.
These were developer-facing changes rather than a change to Ethereum Classic’s monetary policy. They expanded what contracts could do and made software written around the same Ethereum Improvement Proposals easier to adapt across the two networks. ECIP-1056 also incorporated the Petersburg scope, avoiding the problematic net-gas-metering change associated with EIP-1283.
The proposal classified Agharta as a hard fork because the new execution rules were not backward-compatible. Node operators therefore needed software that recognized block 9,573,000 as the activation point. The specification listed Geth Classic version 6.1.0 or later, Parity Ethereum, Multi-Geth and Hyperledger Besu as supporting the relevant features; it listed IOHK’s Mantis client as unsupported at that stage.
The block arrived before the calendar estimate
ECIP-1056 associated block 9,573,000 with an estimated January 15, 2020 arrival. The network reached it several days earlier. That difference illustrates a limitation of calendar forecasts for proof-of-work upgrades: the consensus rule is attached to a block height, while the date depends on how quickly miners produce blocks before activation.
CoinDesk’s contemporaneous report said the block arrived at 06:26 UTC on January 12, citing the then-operating ETCNodes monitoring service. It also recorded 500 visible clients at the time of writing: 252 Parity Ethereum, 167 Geth Classic, 80 Multi-Geth and one Besu. Those figures described nodes visible to that monitoring service, not every node participating in consensus, and they should not be treated as a complete network census.
Client composition mattered because compatibility required more than publishing a specification. Exchanges, mining pools, wallet infrastructure and other service operators depended on upgraded nodes to recognize the same chain. A hard fork can create a lasting split when material participants continue enforcing old rules, but the reviewed event-day record described Agharta as successfully completed rather than as the creation of a separately traded asset.
What the evidence establishes
The verified development is narrow but consequential: Ethereum Classic enforced three additional EVM opcodes at the designated mainnet block and moved closer to Ethereum’s then-existing execution behavior. The records do not establish that Agharta increased application usage, improved ETC’s market value or eliminated broader network-security risks. No event-day price, volume, return or market-capitalization claim is made because the reviewed sources do not isolate a causal market response to the fork.
Later context
The ETC Cooperative’s 2020 retrospective later confirmed that Agharta activated successfully at block 9,573,000 and included Ethereum’s Constantinople and Petersburg changes. Ethereum Classic continued this compatibility program with the Phoenix upgrade later in 2020. That later record confirms the upgrade’s place in the protocol sequence; it does not retroactively prove commercial adoption or market impact on January 11, 2020.
The complete source packet and revision history are retained with the newsroom record.
Automated systems may have assisted with source organization and drafting. Coinburn is accountable for the published text and maintains a revision record.
This article provides news and analysis, not investment, legal or tax advice. Digital assets are volatile and may result in total loss.