Ethereum Classic Community Call #53
Neo Classic
Heads up: next call (54) is at 1500 UTC. The June 12 call has been shifted from the regular 0200 UTC slot to 1500 UTC due to travel. There will be no green room that week. Regular timing resumes after.
Key Points Discussed
- Green-room poker session with InArgentumVeritas ran successfully on ETC, including a cryptographic-randomness ceremony; Istora invited more app builders to use future green rooms as a live testing ground
- Website rebrand framing: switch the Gatsby stack to Astro, lean into a minimal landing with content tucked away, and move toward a wiki-style content model that allows multiple viewpoints rather than implying an “official” position
- AI translations endorsed for multi-language coverage; AI-generated content for the core articles pushed back on by Lunar
- Diego walked through the eight-EIP shortlist (1153, 5656, 6780, 2537, 7823, 7883, 7939, 7951), framing them as compatibility, cryptographic-primitive, and security hardening additions that don’t touch the fundamentals
- ECIP-6780 (SELFDESTRUCT same-tx) tied into the broader stateless roadmap — Diego flagged ETC’s archive state growing ~10GB/month, with stateless making future thin-client validation possible
- Lunar’s ossification argument: every hard fork chips away at the network’s “code is law” credibility, even uncontroversial ones; eventual goal should be Bitcoin-style “in theory we can fork, in practice we never do”
- Diego/Istora counter: the smart-contract layer is genuinely different from Bitcoin’s reserve-of-value layer and needs ongoing maintenance, and ETC has a precedent (gas-token fix, difficulty-bomb removal) for narrow EVM-layer changes
- Diego corrected the “longest chain” framing — ETC and Ethereum use heaviest-chain (total difficulty), not longest-chain
- EIP-1559 and EIP-7702 deferred indefinitely per Lunar’s pushback
- Quantum debate ran long: Istora cited OpenSSH’s post-quantum push as a signal, Diego put a meaningful threat around six years out, Lunar dismissed it as Napoleon-fire hype; open question about how any quantum migration (sweep vs freeze) would actually work
- “Hard fork” vs “network upgrade” terminology: Diego prefers “network upgrade”; Istora keeps “hard fork” as the technically neutral term
Full AI Summary and Transcript ↓
Green Room: InArgentumVeritas Poker Session
Before the call, the green room will host an InArgentumVeritas poker session. Join an hour early if you’d like to play.
Preamble
Hello, and Welcome!
This community call is an open voice chat discussion about Ethereum Classic. Everyone is welcome.
The call will be published on YouTube. We kindly ask that discussion stays focused on ideas rather than individuals. Let’s keep it classy.
Find past episodes, transcripts, subscribe to calendar, and more at https://cc.ethereumclassic.org.
Today’s Agenda
- Neo Classic Website Rebrand
- Enter The Matrix?
- Next Hard Fork: EIPs Shortlist
- Coinbase Storage Mechanics for ECIP-1120
Introductions
Quick round of introductions for everyone on the call, and if there’s anything you want to talk about.
Agenda
Neo Classic Website Rebrand
Rework of ethereumclassic.org. Quick takes on:
- Who is it for, and what should they leave with?
- Minimal landing + deep wiki, à la getmonero.org? Or marketing-style?
- Stack: Astro SSG. Objections?
- Design competition. Brief, judges, must-haves?
- Who owns content, and how do contributions land?
- LLM translations for multi-language coverage?
Open call for contributors. Rewards on offer.
Enter The Matrix?
Matrix server as a Discord backup, à la Monero and other decentralised projects. Quick takes on:
- Worth standing one up?
- Who runs it?
- Bridge to Discord, or keep separate?
Next Hard Fork: EIPs Shortlist
Picking up from the call 49 review with Diego.
Needs discussion
| EIP | Discussion Notes |
|---|---|
| 7823: Upper bounds for MODEXP inputs | Effectively pairs with 7883: adopting 7883 alone leaves the bounded branch under-priced, adopting 7823 alone keeps legacy pricing for unbounded inputs. Include as a pair? |
| 7939: CLZ (count leading zeros) opcode | Low-complexity, no dependencies. Worth including? |
| 7910: eth_config RPC method | Was green in call 49. Still in scope, or moved to a separate track? |
Green - Uncontentious
| EIP | Discussion Notes |
|---|---|
| 1153: Transient storage opcodes (TLOAD / TSTORE) | Cancun. Occupies previously-invalid opcode slots, so existing contracts are unaffected. Now heavily used by modern Solidity (reentrancy guards, cheap per-tx scratch space). Keeps ETC at parity with post-Cancun tooling |
| 5656: MCOPY opcode | Cancun. Another previously-invalid opcode slot. Solidity emits MCOPY for memory copy by default, so without it modern compiler output silently falls back to the old, more expensive sequence |
| 6780: SELFDESTRUCT restricted to same transaction | Cancun. Operational follow-up to EIP-6049, which ETC already adopted in Spiral (ECIP-1109) and which signalled future behaviour changes. Live on Ethereum mainnet since March 2024 with no production incidents; balance transfer is preserved, only post-creation state-deletion is narrowed |
| 2537: BLS12-381 precompiles | Prague. New precompiles at previously-empty addresses, so existing contracts are unaffected. Unlocks ZK and threshold-signature primitives on ETC |
| 7883: MODEXP gas cost increase | Osaka. Repricing of underpriced math; hardens against cheap-CPU DoS at large inputs. Pair with 7823 (adopting either alone leaves a mispriced branch) |
| 7951: secp256r1 (P-256) verification precompile | Osaka. New precompile at a previously-empty address. Enables WebAuthn / passkey signature verification on-chain, unlocking modern wallet UX without bespoke crypto |
Deferred
| EIP | Discussion Notes |
|---|---|
| 2935: Historical block hashes in state | Designed for stateless clients / beacon bridges. Defer until ETC has a stateless roadmap |
| 7623: Calldata cost increase | Tied to EIP-1559 economics. Needs a native ETC cost model first |
| 7702: Set EOA account code | Depends on EIP-1559 fields; replay / sponsorship surface still settling upstream |
| 7825: Per-transaction gas limit cap (~16.7M) | Redundant at ETC’s current ~8M block gas limit |
| 7935: Default gas limit to 60M | Advisory only; on ETC miners set the limit. Should stay out |
| 7934: RLP block size limit at 10 MiB | Includes 2 MiB margin for beacon wrapping that doesn’t apply; revisit later |
| 4844: Shard blob transactions | PoS / beacon-only |
Next Fork Competing Bundles
| EIP | 11?? | 1121 |
|---|---|---|
| 1153: Transient storage opcodes (TLOAD / TSTORE) | 🟢 | 🟢 |
| 5656: MCOPY opcode | 🟢 | 🟢 |
| 6780: SELFDESTRUCT only in same transaction | 🟢 | 🟢 |
| 2537: Precompiles for BLS12-381 curve operations | 🟢 | 🟢 |
| 7823: Set upper bounds for MODEXP inputs | 🟢 | 🔴 |
| 7883: MODEXP gas cost increase | 🟢 | 🟢 |
| 7939: CLZ opcode (count leading zeros) | 🟢 | 🔴 |
| 7951: Precompile for secp256r1 (P256VERIFY) | 🟢 | 🟢 |
| 7910: eth_config RPC method | 🔴 | 🟢 |
| 7935: Default gas limit to 60M | 🔴 | 🟢 |
| 2935: Historical block hashes in state | 🔴 | 🟢 |
| 7623: Calldata cost increase | 🔴 | 🟢 |
| 7825: Per-transaction gas limit cap (~16.7M) | 🔴 | 🟢 |
| 7934: RLP block size limit at 10 MiB | 🔴 | 🟢 |
| 7702: Set EOA account code | 🔴 | 🟢 |
Open questions:
- Bring any deferred items back?
- Mordor / mainnet target blocks?
- Soonest realistic activation?
Coinbase Storage Mechanics for ECIP-1120
Diego to walk through the details.
AI Summary
Green Room Poker Session and App-Testing Format
The call opened with a recap of the pre-call green-room session running the InArgentumVeritas poker dApp.
- Details
- Istora: IAV ran the InArgentumVeritas poker app in the green room; chips were deposited, hands played, and chips withdrawn end-to-end against ETC
- Istora: The app combines a WebSocket chat layer with Web3 wallet sign-in for identity, plus a shared-secret ceremony to ensure cryptographically-random card dealing
- Istora: Worked smoothly with some UX polish needed; live multi-user testing was exactly the point
- IAV: Wanted to run his own node for the app but resigned because of the 32 GB RAM requirement
- Istora: Invited other app builders to use future green rooms as a low-friction multi-user testing ground
- Conclusion
- The green room is a useful format for live app testing with real users
- Node hardware requirements remain a barrier for hobby operators, which feeds into the stateless discussion later
Website Rebrand: Stack, Structure, and Voice
The first agenda item was the proposed rework of ethereumclassic.org.
- Details
- Istora: The current site is built on Gatsby, which is no longer well maintained; moving to Astro brings better SEO, load times, and build times
- Istora: Proposed visual direction is minimal landing with content tucked away “Apple-advanced-settings style,” so new visitors aren’t overwhelmed
- Lunar: Liked the existing long-form articles (notably the “Why Classic” piece) and asked that they remain prominent
- Istora: Floated AI-generated video summaries per article; Lunar pushed back hard (“no AI slop”); compromise was video summaries as a possible add-on, original articles untouched
- IAV: Consolidate the user/researcher/investor/miner/developer/contributor tabs into a less-overwhelming first impression
- Istora: Considered a wiki-style content model so multiple viewpoints can be published, since the site has effectively been treated as “official” while having no actual official status
- Istora: AI is acceptable for translations specifically, since unpopular language pairs otherwise stay untranslated
- Istora: Proposed a community design competition with multiple competing designs and community voting; Lunar noted few people may be interested in design but supported the open process
- Conclusion
- Astro SSG is the working stack choice; visual brief is minimal landing + deep content
- Wiki-style multiple-opinions model is a candidate for handling the “official-ness” problem
- AI usage scoped to translations only, not core article content
- Community design competition with voting is the planned process
EIP Shortlist Walkthrough with Diego
Diego stepped through the eight-EIP shortlist for the next ETC network upgrade.
- Details
- Diego: Reviewed Cancun (Mar 2024), Prague (May 2025) and Osaka (Dec 2025) and filtered for what’s relevant to a PoW chain without beacon-chain or 1559 dependencies
- Diego: EIPs 1153 (TLOAD/TSTORE) and 5656 (MCOPY) are Solidity-team requests that enable contract optimisations and keep ETC compatible with modern mainnet contracts
- Diego: EIP-6780 narrows SELFDESTRUCT to same-transaction, important for the longer-term stateless roadmap
- Diego: ETC archive-node state grows ~10GB/month; stateless validation would let lightweight clients (potentially phones) validate single blocks without holding full state
- Istora: Framed the stateless benefit as cryptographic guarantees on RPC responses without trusting the provider
- Diego: EIP-7939 (CLZ) is another Solidity/Vyper request, affects compilation
- Diego: EIPs 2537 (BLS12-381) and 7951 (secp256r1) are precompiles enabling zero-knowledge proofs and passkey-based signing respectively
- Diego: EIPs 7823 and 7883 cap MODEXP inputs and reprice the opcode to harden against under-priced computation
- Diego: 7702 deferred for further discussion, 1559 deferred indefinitely per Lunar
- Diego: Corrected the “longest chain” framing — ETC follows heaviest-chain (total difficulty), so a short high-difficulty chain wins against a longer low-difficulty one
- Conclusion
- The eight-EIP set is technically uncontroversial: opcode optimisations, two cryptographic precompiles, MODEXP hardening, and a SELFDESTRUCT narrowing that aligns with future stateless work
- 1559 and EOA-code (7702) are off the table for this upgrade
- The heaviest-chain clarification is worth carrying through to the docs
Ossification vs Maintenance Debate
The bulk of the call became a philosophical exchange between Lunar (ossify) and Istora/Diego (narrow ongoing maintenance is fine).
- Details
- Lunar: Every hard fork erodes ETC’s “code is law” credibility because it proves the protocol can be forked; the long-term value comes from being unchangeable, à la Bitcoin
- Lunar: Cited Don McIntyre’s view that ETC is essentially done and should now wait for the rest of the market to come around
- Lunar: BTC is the most valuable because it never changes the core protocol, despite client-side maintenance; ETC should aspire to the same posture
- Diego: Bitcoin solves a different use case from a smart-contract chain. The reserve-of-value layer is the analogue to BTC; the EVM layer needs ongoing maintenance because Turing-complete contracts can have real bugs and underpriced opcodes
- Istora: Referenced the gas-token fix and difficulty-bomb removal as precedents for narrowly-scoped ETC changes that didn’t touch the fundamentals
- Istora: “Code is law” applies to the application layer (contract behaviour preserved), not the client codebase, which has to be maintained for security
- Lunar: Accepted the eight-EIP set on those grounds but framed it as a concession, not an endorsement, and asked for the term “hard fork” to be retired in favour of “network upgrade”
- Diego: Agreed “network upgrade” is the term he prefers; Istora kept “hard fork” as the technically neutral framing to avoid loading the conversation
- Istora: Asked how the ECIP process resolves with three positions in the room (Olympia / less-controversial bundle / zero upgrades); no concrete answer
- Conclusion
- The room landed on a working consensus that narrow EVM-layer additions are acceptable, but the bar for any future fork should remain high
- The terminology question (“hard fork” vs “network upgrade”) is unresolved but the framing matters for how proposals are received
- The deadlock in the ECIP process itself is the bigger open question
Quantum Threat and Migration Mechanics
The closing thread covered quantum risk and how any future migration would work in practice.
- Details
- IAV: Asked how ETC should respond to a quantum threat
- Lunar: Quantum is “Napoleon fire” hype; current quantum computers can’t factor large numbers, so this is years away and not actionable now
- Istora: Posted an OpenSSH link in the chat showing the SSH community is already pushing post-quantum upgrades, as evidence of mainstream-cryptography concern
- Diego: Put a meaningful threat horizon around six years and noted that post-quantum algorithms already exist, so preparation is feasible
- Diego: The real question isn’t when commodity quantum arrives but whether any government or private lab is already ahead in secret
- Lunar: Worried that quantum framing can be used as a “Napoleon fire” pretext, citing the recent Bitcoin BIP (Jameson Lopp) to freeze old coins as cover for what’s effectively a wealth-transfer to newer holders
- Istora: Walked through Bitcoin’s two unappealing options — Satoshi-era coins get spent and crash the price, or funds get frozen and forced migration is required
- Diego: Couldn’t see a clean technical mechanism for forcing migration on an open chain; users can’t be required to act to stay safe
- Conclusion
- There is no working consensus on whether quantum warrants pre-emptive action, but there is broad agreement post-quantum primitives should be researched
- The migration-mechanics problem (sweep vs freeze, who decides) is genuinely unsolved and worth its own follow-up
- The political risk of using quantum framing as cover for unrelated changes is a legitimate concern the room flagged
Action Items
- Istora: Drive the website rebrand process, opening the door for contributors (design, copy, content, infra) with rewards on offer
- Istora: Continue the EIP shortlist conversation toward a formal ECIP, taking the heaviest-chain clarification on board
- Diego: Continue work toward a draft ECIP for the eight-EIP bundle and on the underlying client work
- Diego: Think further on quantum-migration mechanics; revisit on a future call
- Community: Submit feedback on the EIP shortlist and the website rebrand direction (via Discord or directly)
- Wego (if available): Join call 54 to weigh in on the website rebrand
- All: Next call is June 12 at 1500 UTC (no green room) due to travel; regular timing resumes after