Classix spent the first week of November in Mumbai. Devcon 8 opened there on 2026-11-03, and on the evening before it we hosted an Ethereum Classic meetup.
This post is our notes from the week. It starts with the Ethereum Cypherpunk Congress, then our meetup and the community survey the talks ended on, then what Devcon had on quantum security and privacy, and some good news from Besu. The second half is a list of ideas for ETC that we came home with.
Mumbai Happenings
We’ll start with what happened in Mumbai that week, and the ideas we came home with follow in the second half.
Ethereum Cypherpunk Congress Mumbai
The third Ethereum Cypherpunk Congress was at the Yashwantrao Chavan Centre on 2026-11-02, the day before Devcon opened and a few hours before our meetup. We like the Congress logo, which has the ETC logo at its centre.
The day ran on the Make Ethereum Cypherpunk Again narrative, with privacy, decentralisation and cypherpunk philosophy in nearly every session. That agenda is ETC’s agenda, and we said so at the meetup that evening. These ideas are baked into ETC’s DNA, and ETC is far more aligned with them than our big purple sister.
Make Ethereum cypherpunk again? Always has been.
Vitalik talked a lot about his Kohaku project that week, and about cryptography breaking because of AI and quantum computers. We cover both later in this post, in Kohaku Classic and in the quantum ideas that start with the strawmap.
Ethereum Classic Mumbai Meetup
Our announcement post for the meetup sent people to Luma to register, and we capped the guest list at 150. By the night 162 were going and another 213 were on the waitlist, so the upstairs room at Leopold Cafe in Colaba was full.
It went really well, and we think a real world presence is extremely valuable for ETC. Plenty of guests turned up, and we had a productive discussion about India, ETC and a good few other topics. Istora opened the talks by saying we hadn’t expected so many RSVPs, and that next year we’ll need a bigger venue.
There were three short talks before everyone broke into groups. Istora gave two of them, the first and the last, which together make one talk on ETC’s past, present and future. It goes from The DAO and the fork through ten years of upgrades to what AI and quantum computing mean for the chain. Diego spoke in between on the state of the Ethereum Classic clients, and on what a bug in the majority client does to a network. All three are on YouTube as they were given on the night, in our Ethereum Classic Mumbai playlist.
Past, Present and Future, Part 1 Istora Mandiri 
Ethereum Classic Clients Diego López León 
Past, Present and Future, Part 2 Istora Mandiri The main takeaway Istora highlighted was that ETC is in a good position on quantum security, because its proof of work and its Merkle trees are already hash-based. That leaves the ECDSA signature on each transaction as the one layer ETC has to hard fork to change, and since Ethereum has to replace it too, we think ETC should follow Ethereum’s lead and stay compatible. We said the same in our notes from TOKEN2049.
Diego’s talk made the case for client diversity. He started with the Bitcoin chain split of March 2013, which came from a bug in a single client and had to be fixed by the mining pools agreeing to downgrade. A chain’s rules only run as software, and software has bugs, so a network where nearly everyone runs one client is exposed to the same thing. On ETC today 94% of reachable nodes run Core-Geth, a bigger share than Geth ever had on Ethereum. He called running a minority client “a cheap and easy insurance”.
Diego and Istora will both be following up on their talks with actions in the coming months. The meetup was a success and we plan to do it again next year in Lisbon during Devcon 9.
ETC Community Survey
Istora’s presentation ended with the announcement of the ETC Community Survey 2026, which is open now at survey.classix.dev. The last survey of the ETC community we can find is a poll from November 2019 that got 32 responses, so this is the first in seven years.
It takes around ten minutes, every question is optional and it comes in nine languages. It’s for anyone who holds, uses, mines, builds on or follows ETC, and for people who used to and stepped away. We’ll use the answers to decide what to work on. If you finish it you get a thank-you NFT and can enter a draw for 8.88 ETC.
There are more details in our post about the survey.
Devcon 8
Diego and Istora both went to Devcon, and we were pleasantly surprised by the quality of the talks. We both noticed that attendance was significantly lower than in Bangkok two years before.
24 of the 370 sessions on the Devcon agenda mention quantum. The first was Post-Quantum Transition, a main stage keynote on the opening day, 2026-11-03, and Justin Drake of the Ethereum Foundation used it to pull Ethereum’s post-quantum deadline forward by a year, as CoinTurk reported.
Ethereum Foundation researcher Justin Drake has set an ambitious timeline […] calling on developers to deliver three major hard forks within a 24-month window following the upcoming Glamsterdam upgrade. […] Drake emphasized the importance of completing these upgrades by December 2028—one year ahead of the foundation’s official December 2029 target.
The same piece has Drake hoping that “by December 2028 we’ll be able to wrap up the full post-quantum and post-AI transition”.
He also announced that day that leanVM, the minimal zkVM Ethereum plans to use to aggregate hash-based validator signatures, had been formally verified end to end (Crypto Briefing). His odds of a quantum computer that breaks today’s elliptic curves are 10% by 2029 and 50% by 2032 (Crypto Times).
All of this rests on hash-based signatures, with leanXMSS replacing BLS for Ethereum’s validators and leanSPHINCS as the candidate for user accounts. leanSPHINCS had two Devcon sessions of its own on 2026-11-05, a lightning talk called leanSPHINCS: Signing for the long run and a workshop, leanSPHINCS for developers.
Devcon was a success for us too, because we learned almost exactly which signature scheme we need to focus on, and that’s leanSPHINCS. We took a lot of other ideas from the week, which the second half of this post goes through, and we expect to bring some of them up on the community calls.
Besu Is Taking Diego’s Plugin API
Diego has been moving ETC out of forked clients and into plugins. His Besu ETC plugin holds ETC’s rules while the rest of the client stays stock Besu, and the Nethermind ETC plugin does the same for Nethermind.
During Devcon we found out that upstream Besu is taking Diego’s work on a new plugin API that makes this possible. Gary Schulte, one of Besu’s leads, opened PR #11887, Pluggable protocol schedule customization, on 2026-11-07, and its description credits him.
Thanks to @diega for the design and most of the implementation.
This is a major win for the maintainability of Ethereum Classic, because ETC’s rules can then sit in a plugin on stock Besu and nobody has to carry a fork. The PR is still open against Besu’s plugin-api-refactor branch, so it isn’t in a Besu release yet, but it’s likely to be merged because a Besu lead opened it. There is more on the client work in Twelve More Months of Client Maintenance.
The Idea Harvest
We came home with a list of things ETC could do next. Most of them are still ideas and a few will turn out to be wrong, so we’re writing them down for the ETC community to pick apart. The trip to Mumbai will culminate in, and heavily influence, our new 2027 pathway, which we’ll announce next month.
An ETC Quantum Strawmap Is Coming
Ethereum’s Strawmap outlines seven forks by 2029 and has five goals it calls north stars, of which this is the fourth.
post quantum L1: centuries-long cryptographic security, via hash-based schemes
We’ll publish a strawmap of our own for ETC. It will sort Ethereum’s changes into the ones ETC needs and the ones it already has through proof of work, and then put the first group in the order ECIPs could bring them in.
leanSPHINCS Is the Future of ETC, Probably
leanSPHINCS is the Lean Ethereum project’s proposal for a stateless, hash-based signature for Ethereum accounts. The exact scheme is being chosen through a competition called sig.golf. It isn’t taking submissions yet, and for now its repo has the draft rules.
Draft rules for leanSPHINCS: an autoresearch competition for the post-quantum hash-based signature of Ethereum accounts
The best place to see what it gives you is sphincs.art, Tom Wambsgans’ interactive exploration of leanSPHINCS. You choose a key lifetime, a hash (Keccak-256, SHA-256 or BLAKE2s) and either FORS or a WOTS forest, and it shows the signature size and the cost of verifying and signing, for a single signer and for threshold signing. There are links to the Lean proofs and to a note describing the scheme as well.
Another one was on screen in the Devcon workshop leanSPHINCS for developers. It’s Project Eleven’s SPHINCS Playground, which describes itself as “A gamified explainer of SPHINCS+ and SPHINCS G few-time signatures”.
This is the piece ETC needs, because the signature on each transaction is the part of its stack that takes a hard fork to make quantum-safe. There are probably other parts that aren’t quantum-safe yet, in the peer-to-peer layer for example, but those are much easier to update. Istora’s talk at the meetup made that point the evening before Devcon opened. Now that Devcon has happened we know, more or less exactly, what Ethereum will implement for accounts, and it rests on the same assumption as ETC’s proof of work, that the hash function stays secure, so ETC should probably copy it.
The catch is that a leanSPHINCS signature is big, at 7,740 bytes, and on ETC today one takes about 123,000 gas of calldata and another 86,000 to verify. Ethereum’s answer is EIP-8288, a draft by Vitalik Buterin and Thomas Coratger that keeps signatures off chain. Mempool nodes fold the signatures they see into a recursive STARK, which is built from hashes and so stays post-quantum, and in the end
the block contains one single recursive STARK that proves their existence
The prover Ethereum is building for this is leanVM, a minimal zkVM that Tom Wambsgans presented at Devcon in LeanVM. The session abstract lists “Aggregating PQ user signatures (sphincs based)” among its jobs, next to aggregating validator signatures, and names a “secure hash function” as its single cryptographic assumption. More work needs to be done on exactly how ETC would use leanVM.
Nothing in the draft needs proof of stake, so aggregation is possible on ETC, and we have to figure out the best way to implement it. Miners and pools would be the ones merging proofs before they hand out work, every ETC client would need a leanSTARK prover, and the EIP sits on top of EIP-8141 frame transactions and EIP-1559, which ECIP-1120 proposes for ETC. Ethereum is also sketching native support for the signature itself. An open pull request to EIP-8141, add lean sphincs, which lightclient opened during Devcon, makes leanSPHINCS a scheme the protocol verifies directly and prices it at 12,600 gas. A contract on ETC spends about 86,000 on the same check today.
A Post-Quantum ETC Multisig
Safe is the multisig wallet treasuries and teams use on ETC today, and because its owners sign with ECDSA keys it doesn’t support quantum-safe signatures yet. Safe itself doesn’t have to change to add them, because it already accepts contract signatures from owners that are themselves contracts. Write an owner contract that checks a hash-based signature and that signer has a quantum-safe key.
The owner contract can be built today. It’s a small signing contract that hands the signature to a leanSPHINCS verifier, and it runs on ETC as it is with no fork. A Safe is only as strong as its owners, so it is quantum-safe once enough of them sign this way that the ECDSA owners left can’t reach the threshold between them.
So multisigs can be made quantum-safe before any protocol upgrade happens. If you’re sitting on a large stash of ETC, you’re welcome to reach out to us about securing it before Q-Day.
Kohaku Classic
Kohaku is Ethereum’s roadmap for private and secure wallets, and it opens with one line.
Kohaku is a set of primitives that provides wallets with security and privacy.
The Ethereum Foundation is pushing it, and Vitalik Buterin is involved. He co-presented it on Devcon’s opening day in Kohaku : privacy for everyone, by default, the day after he spoke on post-AI privacy at the Ethereum Cypherpunk Congress, where wallets also had a panel of their own called “Privacy’s last-mile problem: Wallets”. With that behind it, Kohaku is likely to get attention.
So far that means an SDK plus a reference browser-extension wallet, and the feature list has private sends, a fresh address for each dapp and post-quantum accounts. Kohaku Classic would be the same SDK on ETC, and it needn’t be a project of its own. It could be a plug-in for the existing Kohaku framework, which would put ETC support upstream where both chains benefit from it, a symbiosis instead of a fork. Ethereum is setting the direction for wallet privacy and we want ETC to follow it closely, so that when private sends and per-dapp addresses become normal in Ethereum wallets, ETC users get them too.
A wallet with private sends needs a pool to send through, which is the next idea.
Anonymining Pools
During Devcon, while watching Vitalik talk about privacy pools, Diego had an interesting idea. Next year we could set up a system where miners shield the ETC they mine, moving block rewards into an anonymity pool as they earn them.
For now, we could call these anonymining pools, meaning anonymity pools for mining. They’d work like a shielded pool, where freshly mined coins with no history join a common set and nothing links them to it when they leave.
Zcash is one inspiration, and we wrote about it in our Reflections on TOKEN2049. In Mumbai privacy had a day to itself at the Ethereum Cypherpunk Congress, and then Devcon had a Privacy & Consent track with 24 sessions on its agenda. Ethereum’s Strawmap also lists a “private L1” with “L1 shielded transfers” among its five goals.
A Unified AI Upgrade Pipeline for All ETC Clients
ETC runs on more than one client, and Triforce now runs four of them side by side, Core-Geth, getc, Nethermind and Besu. Each one sits on an upstream Ethereum client, and every new upstream version has to be brought into the ETC client by hand. That is the work that comes round most often, so the first job for a pipeline of AI agents is the upgrade to each new upstream version, tested against every client and ending in a pull request.
Porting ECIPs comes second. There aren’t many of them and each one can still be implemented by hand, once per client, but the same pipeline would give an agent or a developer one standard process for all the clients, from the ECIP to the code, the tests and the pull request. Agents would also keep track of how much of each EIP is implemented in each release.
Diego’s plugin work is a start on this, since ETC’s rules now sit in a plugin for Besu and another for Nethermind while the clients themselves stay stock.
We already use agents to review client code. Our roadmap has it as automated vulnerability hunting, and it was used in the review behind the Core-Geth v1.12.23 release.
Lean 4 Is the New Rust
The heading is a saying Justin Drake passed on at Devcon. In his PQ Ethereum Q&A on 2026-11-04 he was asked what young developers and researchers should learn to help build Ethereum’s quantum-resistant future, and this is his answer in Miss Purple’s notes of the session.
It’s a programming language, and there’s a saying that Lean 4 is the new Rust.
The notes also have him saying “Personally, I’d forget about Rust and go all in on Lean 4.”
Lean 4 is a programming language and proof assistant, and Ethereum’s cryptography work is moving into it. The Verified zkEVM project uses it and the sphincs.art work on leanSPHINCS comes with security proofs in Lean 4. sig.golf goes further and scores nothing but Lean proofs, and its README calls it “a competition in which every claim is a Lean proof about a pinned contract”. With AI writing more of the proofs, we expect Lean 4 to become as normal for protocol code as Rust is now. We’ll be experimenting with Lean 4 ourselves, alongside agentic tooling.
ETC on Every Signer Device, With Clear Signing
Every hardware wallet and signer should support ETC, and show users what they are signing. The clear signing standard is ERC-7730, which is still a draft. It’s a JSON format that tells a wallet how to turn calldata into plain language, and the descriptors are kept in an open registry. None of that needs a protocol change, but listing chain ID 61 in the descriptors isn’t enough. A lot of the wallets that support ETC ignore the chain ID and treat ETC as if it were Ethereum, so the hardware wallet story on ETC needs improving first.
We also want self-custody on ETC to get better in general. Holding your own keys should come with clear procedures, and open signers such as Wedgie, Austin Griffith’s DIY hardware wallet, and Firefly should work on ETC. We’d also like to see a full guide to sovereign-grade custody on ETC that puts those procedures in one place.
Code Is Law and Kleros
“Code is law” is ETC’s founding principle, but when code is ambiguous someone still has to decide. Kleros runs on-chain courts with crowdsourced jurors. Its ERC-792 arbitration standard lets any contract hand a dispute to an arbitrator and enforce the ruling, so the idea is an ECIP that brings Kleros to ETC as the standard way for contracts to resolve disputes.
ETC in the Ethereum Economic Zone
The Ethereum Economic Zone (EEZ) comes from Gnosis and Zisk with funding from the Ethereum Foundation, and its announcement describes it like this.
an L1<>L2 framework built around one principle: rollups that extend Ethereum
It allows communication between EVM chains, so a contract on one chain can call a contract on another inside a single transaction. Jordi Baylina presented the design at Devcon in EEZ: Building Synchronous Ethereum with Real-Time ZK Proofs.
We’d like to get ETC into the EEZ. It was written with Ethereum in mind, and a proof-of-work chain brings extra things to work through, mainly asynchronicity and finality, since a mined block is only final with some probability and can still be reorganised. We talked to the EEZ team about it, and it looks doable.
Hackathons and AI Reimplementations in 2027
Agentic AI development is in a golden era, and in 2027 we want to use it to generate many ideas, reintroduce concepts that succeeded on Ethereum and create a lot of awesome stuff on ETC.
Plenty of concepts have worked on Ethereum and might work on ETC too. We no longer need to copy and paste a codebase to bring one over, because agents can reimplement it with relative ease. We want each one to have an original name of its own and to be mutated for success on ETC.
We also want to run several hackathons through the year, of different kinds. Some would be AI-driven, some in person and some online, and there’d be ideathons too, where people enter an idea and don’t have to write code.
See You in Lisbon
Overall the trip was a massive success, and an important event that will shape the future of ETC. We’d like to thank everyone we met in Mumbai, because human connections are important and you only make them by turning up.
We look forward to Devcon 9 in Lisbon.