Disclosure: I maintain chippr-robotics/fukuii, a Scala 3 execution client that continues IOHK’s Mantis. The developer behind White B0x contributed to it until July 2026, then started fukuii-project, a separate, ground-up client that uses the same name. I haven’t contributed to fukuii-project, and I didn’t agree to the credit lines naming Chippr Robotics; I’ve asked for them to be removed and for the project to be renamed. I also sit on the ETC Cooperative board. I proposed moving ethereumclassic.org’s canonical core-geth pointer to ethereumclassic/core-geth (website PR #1678). In that repository I opened a draft, agent-drafted pull request for a signed GHCR release workflow (#37), which was closed without merging on 12 September, and I’ve filed issues #38 and #44–#46. I didn’t write or review any of the changes in core-geth v1.13.0
What happened
On 14 September, core-geth v1.13.0 was tagged in ethereumclassic/core-geth and announced to node operators as a security update. None of its changes went through a pull request. They were committed directly to main, and several of them change how a node selects its chain and finds its peers. Some pool nodes moved to it and then moved back. No blocks or funds were lost.
The v1.13.0 README, the migration guide, and a security audit page on ethereumclassic.com describe Fukuii as core-geth’s “preferred successor.” The audit page says no client other than Fukuii is recommended. Two commits also point core-geth at a repository in the Fukuii project’s org: 693d8e4 swaps the ETC consensus test fixtures submodule from etclabscore/tests to fukuii-project/archive-reference-material, and ed99f02 adds go.mod replace directives that build core-geth’s OpenRPC modules from the same place.
What I didn’t authorize
archive-reference-material is a reference archive. I didn’t authorize core-geth to use it as a test fixture source. A client shouldn’t validate consensus against fixtures hosted by another client’s project; that couples two implementations that exist precisely to be independent. Both commits should be reverted.
Fukuii isn’t core-geth’s successor, and “no client other than Fukuii is recommended” isn’t advice I’d give anyone. It should earn operators the way every other client does: on the record, over time, alongside the others.
The same failure, in both core-geth repositories
Read the Classix incident report and the ethereumclassic.com audit side by side, and they describe the same problem: one person with release authority and no required review. They disagree only about who it applies to.
It applies to both, and GitHub’s own records show it.
On etclabscore/core-geth, the pull requests behind v1.12.21 (#694), v1.12.22 (#696) and the Argos backport (#699) were each opened and merged by their author. GitHub records no review on any of them.
On ethereumclassic/core-geth, 27 pull requests (#10–#36) were opened on 20–21 March with CVE fixes, toolchain upgrades and tests. None received a human review, and none was merged. Four were closed by their author the day they were opened. The other 23 sat for five and a half months until their author closed them on 4 September; the work had been carried onto main directly. On 12 September, the day the first v1.13.0 release candidate was tagged, two open pull requests from other contributors, mine and one from a longtime core-geth maintainer, were closed without merging. The two pull requests merged since the release, including one that hardens the RLPx handshake, were merged by their author with only an automated review.
The scale differed. The etclabscore merges were targeted backports of upstream fixes under active attack. v1.13.0 was a large change to chain selection and peer discovery, pushed to pools as urgent. But the norm broken was the same.
The rest mirrors too. Both camps speak through community-named channels. Both attach funding asks to the argument. Both accuse the other of building on someone else’s work without credit. And both claim the authority of a project that, by its own founding principle, has no official anything.
Why I still want one repository
I believe that if core-geth had been consolidated in the ethereumclassic org, with required review and the existing maintainer on board, most of this wouldn’t have happened. In March, the same fixes were being worked on in two repositories at once: 27 pull requests in one, emergency backports in the other. Neither side reviewed the other’s work; they weren’t working in the same place. One repository with both people in it puts all of that through one review queue.
But moving the pointer without the controls would have made September worse, not better. v1.13.0 would have landed in the canonical repository, and operators would have had nowhere to roll back to. The incident was contained because pools had another release to go back to.
So consolidation is right, and the order is controls first. Named maintainers. A protected default branch. At least one human review before anything lands. Releases that run on Mordor before they reach mainnet. Every client listed on equal terms. Rules that bind whoever holds the keys make the label worthless to capture, and then there’s nothing left to fight over.
What v1.13.0 got right, and where it went wrong
The underlying security work was real. The 21-month maintenance gap was real, the CVEs were real, and moving off an end-of-life Go toolchain was overdue. That work deserves credit.
The release didn’t hold up.
MESS. Commit a7fd45b ships MESS enabled by removing the Spiral deactivation block. ECIP-1110 turned MESS off at Spiral after public discussion, specifically to avoid a network where some nodes run MESS and others don’t. Reversing that is an ECIP decision, not a release decision.
Node key rotation. Rotating is a reasonable precaution for any node that ran a release before v1.12.21 while publicly reachable: the fix stops new leakage, but it can’t recall bits already exposed. It isn’t tied to v1.13.0, though. Rotating on v1.12.23 does the same job. Weigh it against the cost: your enode ID changes and static peerings break.
Peer discovery. Commit eb0cb35 replaces the DNS discovery signing key and bootnodes, with all three new zones served from a single DNS account, as the code’s own comment notes. That deserves its own proposal and review. It shouldn’t ride along inside a security release.
What I’ve done
I’ve opened three issues on ethereumclassic/core-geth: restoring the ECIP-1110 MESS default (#44), making the README describe the client rather than the latest release (#45), and requiring at least one human review before code lands on main (#46).
If you run a node
Check your MESS setting. Until the MESS default is restored and the release has had a human review, I wouldn’t run v1.13.0 in production.
Stay on the release you already trust until a reviewed tag exists.
There’s no official anything in Ethereum Classic. That includes clients, and it includes mine.
