Skip to main content

Olympia

Client Implementations

A client is the software a node runs. It keeps a copy of the chain, checks every block against the rules, and passes on the ones that hold up. Ethereum Classic has two clients through the Olympia upgrade, and for the first time one of them was built for this network rather than adapted from an Ethereum client.

Why the network needs more than one

  1. One client's bugs become the network's rules

    If every node runs the same software, nothing on the network is in a position to disagree with it. A second independent implementation of the same specification turns a silent wrong answer into a visible argument between two clients, which is the only way a fault of that kind gets caught before it becomes the network's history.

  2. Software stops being maintained

    This is not a hypothetical on Ethereum Classic. The client the network relied on went 21 months without a maintenance release while six security fixes waited, and in March 2026 its mainnet bootnodes came under active attack. A network with one client has no answer to that. A network with two independent ones does.

    The record, in full

  3. Operators are not all the same

    An exchange, a mining pool, a block explorer and a person running a node at home are solving different problems on different infrastructure. More than one implementation means the choice of language, runtime and operational model belongs to the operator rather than to the protocol.

The clients

Both carry the Olympia parameters. What settles conformance is not a client’s own account of itself: cross-client state-transition equivalence is demonstrated on Mordor before a mainnet activation block is scheduled. The two are not interchangeable choices, and the page for each says why.

PrimaryScala

Fukuii

Ethereum Classic's first native client, built for this network from the start rather than adapted from an existing Ethereum client.

More on Fukuii

An EVM execution client written in Scala 3 and running on the JVM. One binary runs several networks at once in a single process, each with its own state, its own metrics and its own configuration, so a further network is configuration rather than a new client. Consensus is chosen per deployment: native Proof-of-Work for Ethereum Classic and Mordor, or Proof-of-Stake with a built-in consensus layer or an external consensus client driving it over the Engine API.

  • Built ground-up for Ethereum Classic, not derived from an Ethereum client
  • Runs Ethereum Classic and Mordor from the same binary as any other configured network
  • Apache 2.0, developed in public, with signed builds and a bill of materials on every release
fukuii.orgDocumentationSourceReleases
MaintenanceGo

Core-Geth

The client Ethereum Classic has run for years. It is a go-ethereum derivative, and it is now kept working rather than actively developed.

More on Core-Geth

A go-ethereum derivative maintained for Ethereum Classic. It carries the Olympia parameters, so an operator already running it has a path through the upgrade without changing client. It is in maintenance rather than active development, and new deployments should use Fukuii.

SourceReleasesSecurity audit

Plugins for upstream clients

Future work

Ethereum clients keep the part that agrees on blocks separate from the part that executes them. A plugin uses that seam to add Ethereum Classic support to a client that already exists, so nobody has to maintain a full fork of it just to follow this chain.

A plugin is not a client of its own and it carries no mining or Proof-of-Work consensus, which is why the ones below would serve exchanges, RPC providers, block explorers and indexers rather than miners. All six plugins are future work, and none of them ships today.

Two of the six clients are separately in scope, and that is a different thing from a plugin for them. The specifications track Besu and Nethermind as Olympia implementations, carrying the era gas target hardcoded so miner configuration cannot override it. An implementation of the client is not the plugin described here, and neither fact cancels the other.

  • Besu

    Java

    Adds Ethereum Classic support to Besu, an enterprise-grade Java client.

    The specifications track this client as an Olympia implementation, separately from the plugin.

    Upstream project

  • Erigon

    Go

    Adds Ethereum Classic support to Erigon, a storage-optimized archival client.

    Upstream project

  • Ethrex

    Rust

    Adds Ethereum Classic support to Ethrex, a minimalist Rust client.

    Upstream project

  • Go-Ethereum

    Go

    Adds Ethereum Classic support to Go-Ethereum, the most widely deployed EVM client.

    Upstream project

  • Nethermind

    C#

    Adds Ethereum Classic support to Nethermind, a high-performance .NET client.

    The specifications track this client as an Olympia implementation, separately from the plugin.

    Upstream project

  • Reth

    Rust

    Adds Ethereum Classic support to Reth, a modular Rust client built for throughput.

    Upstream project

Running one

Every node has to be on an Olympia release before the activation block, whichever client it runs. The upgrade page has the instructions and the timing.

How to upgrade a node