Moving a Core-Geth v1.12 Node to the v1.13 Line

Every Core-Geth node still on a v1.12 release should move to the v1.13 line, published from ethereumclassic/core-geth in the ethereumclassic GitHub organization. The steps for each platform are on coregeth.com, and the migration guide gives the reasons behind them.

Who should move

Every node on a v1.12 release, v1.12.23 included, whatever it serves: an exchange or custodian, a mining pool or solo miner, an RPC endpoint, an explorer, or a node you run for yourself. The emergency releases cut in 2026 closed some of the v1.12 flaws and left others open, so no v1.12 release is one to stay on.

A node on a release older than v1.12.17 is a separate case. Those releases do not schedule the Spiral upgrade, so such a node left Ethereum Classic at block 19,250,000 and does not resume where it stopped.

Why

Core-Geth went 21 months without security maintenance, from v1.12.20 in June 2024 to the emergency releases of March 2026. In March 2026 one of the flaws left open in that time, the handshake crash CVE-2026-22862, was used against Core-Geth v1.12 bootnodes, which crash-looped until a patch reached them. The v1.12 releases cut since then closed some of the flaws and left others open, and every v1.12 archive was built with a Go toolchain that no longer receives security fixes.

The v1.13 line closes every client CVE the audits found in the v1.12 client code, bounds GraphQL queries, carries neither of the regressions the last v1.12 releases introduced, and is built with a supported Go toolchain. On September 17, 2026, etcnodes.org counted 524 Core-Geth nodes, and 9 of them ran v1.13.0. coregeth.com/security has the audits, and what each v1.12 release fixed and left open.

What the move changes

• The P2P node key rotates, and that is required. One of the v1.12 flaws leaks bits of the node key across repeated handshakes, and no fix can take back what already leaked. The move renames the old key file aside, and the node writes a new key on its next start, so its enode ID changes: give the new ID to every node that lists this one as a static or trusted peer, and to the monitoring and allowlists that name it. A key that has only ever run the v1.13 line was never exposed. The node key explains it.
• MESS is set explicitly. An upgrade can change whether a node runs MESS, which decides which of two competing chains the node keeps during a deep chain reorganization, so the move sets it with --mess or --mess=false. Give every node you run the same setting. Which setting fits which operator sets out the choice.
• Discovery settings added for `v1.12` come out. A --discovery.dns or --bootnodes flag added on the v1.12 line comes out before the first start on the v1.13 line, and a config file loses its BootstrapNodes, EthDiscoveryURLs and SnapDiscoveryURLs lines unless you set them yourself on purpose, so the node reads the bootnodes and peer discovery lists its release ships with.
• A container keeps its chain only where its data is mounted. A container started with no data mount holds the chain inside itself, so the container steps check where the data is before the stop, and copy it out first when it is inside the container.
• The chain data and the accounts stay. Nothing resyncs, and the account keystore is not touched.

Each of these is a step on coregeth.com/downloads, with the commands for Linux, macOS, Windows, containers and a build from source.

In what order

1. Optional, and best practice: one trial node. Before moving a node you depend on, set up one new node on the v1.13 line on a machine of its own, point no RPC clients or miners at it, and let it catch up with the network, as checked below.
2. Then each node in turn, with the steps for its platform. They keep the node running until the release is downloaded and checked, keep the old binary or container so you can roll back, and rotate the key before the node starts again. coregeth.com/downloads has them, and the migration guide has a guide per platform and the rollback.

The trial node has caught up when the first command returns false and the second returns a number above zero, where <datadir> is the node's data directory. How to tell it is done has two more checks.

geth --classic attach --exec 'eth.syncing' <datadir>/geth.ipc
geth --classic attach --exec 'net.peerCount' <datadir>/geth.ipc

A node that cannot move yet

A v1.12 node that cannot move yet can add the --discovery.dns flag, which points it at the peer discovery lists published from the ethereumclassic organization, so it keeps finding peers after the lists v1.12 releases read by default stop being updated. It is a small step that closes none of the flaws the audits found in the v1.12 line. coregeth.com has the flag for each network, and what changes for a node started from a config file or in a container.

Where releases come from

Core-Geth releases are published from ethereumclassic/core-geth. etclabscore/core-geth is the previous namespace: archives still published there are built from the older code, none carries every v1.13 fix, and the ETC Cooperative board has communicated its intent to archive that repository. A node, script or mirror watching it will not see a new release. Check each download's checksum and build attestation with the steps on coregeth.com/downloads.

What else moves as the ETC Cooperative winds down

• Peer discovery. The v1.13 line reads the lists published from ethereumclassic/discv4-dns-lists by default, and ships with bootnodes run by the Core-Geth maintainers.
• Public JSON-RPC. etc.rivet.link went offline in late August 2026. For a public endpoint, use the lists on ChainList for Ethereum Classic and Mordor while endpoints run from the ethereumclassic organization are stood up. Anything you depend on should run against a node you control.
• Security contact. Pools, exchanges and service providers should use security@ethereumclassic.net. A person answers it: one of the core developers who maintain Core-Geth.

The ETC Cooperative transition lists where each service continues.

Who maintains and funds Core-Geth

Core-Geth is maintained in the ethereumclassic organization by Ethereum Classic's core developers and community contributors, who do the work, together with the Ethereum Classic DAO, a Wyoming DAO LLC and the standing legal entity that maintains and funds the client today as its funder of last resort. The DAO does not control or lead Ethereum Classic, and it is not the only organization that can fund the work: what the work needs is steady funding from the stakeholders who depend on it, so that it no longer rests on a single backer. coregeth.com/sponsor sets out who has funded Core-Geth and how to sponsor it, and sponsorship is arranged through donations@ethereumclassic.net.