• ACDC #161: Devnet‑3 live; RCs late Aug; pre‑Devconnect mainnet target.

• Glamsterdam shortlist: EPBS, 6‑sec slots, FOCIL.

• R&D: Post‑quantum devnets, VRF‑SSLE, zkVM memory model.

Summary :
Developers wrapped up Devnet‑2 and brought Devnet‑3 online (it started about a day before the call), with a fork to Fulu happening right after. Early tests showed sync problems for a couple of clients (Lodestar and Nethermind) when lots of data (“blobs”) are in play. To make tests more realistic, the team will add internet speed limits to most test nodes (think ~100 Mbps down / 50 Mbps up) while a smaller set of “super nodes” stays fast. The plan is to stabilize through August, publish release‑candidate builds by late August, then move to public testnets. If things look good, the goal is a Fusaka mainnet before Devconnect, leaving about 30 days of safety time between each step.

For the next upgrade (“Glamsterdam”), the group will shortlist three possible “headline” features—EPBS (a block‑building design), 6‑second slots (faster blocks), and FOCIL—and pick one on the next call. There’s also active work on reducing the “free‑option” risk in EPBS (builders backing out late).

Action items

• Devnet‑3: Fix the Lodestar/Nethermind sync issues; turn on speed limits for most nodes; keep a few super nodes unlimited for comparison.

• Hardening: Use late July–August to fix bugs, measure network behavior, and lock configs.

• Release candidates: Aim to publish RC builds by late August if Devnet‑3 is stable.

• Testnets → mainnet: Move to public testnets, then target Fusaka mainnet before Devconnect, keeping ~30‑day safety gaps between each phase.

• Glamsterdam (next fork): Shortlist EPBS, 6‑second slots, and FOCIL now; choose the headliner next call. Continue exploring ways to reduce EPBS’s “free‑option” risk.

• Specs: Move ahead with a small SSZ‑types addition (clearly marked as temporary) to unblock testing.

Timeline

• Now: Devnet‑3 live; Fulu fork right after the call.

• Late July → August: Stabilize & measure; add speed limits; fix sync issues.

• Late August: Release‑candidate builds (if stable).

• September (if RCs hold): Public testnets.

• ~30 days after the last stable testnet: Mainnet — target is before Devconnect (November).

• Next ACDC call: Decide Glamsterdam headliner (EPBS vs. 6‑second slots vs. FOCIL).

What this is:
“Post‑quantum” means crypto that stays safe even if powerful quantum computers appear. Teams are trying ideas on small throw‑away networks so they can learn quickly without touching Ethereum mainnet.

Plan:
Start with a simple chain that just moves forward. Then add post‑quantum signatures. Later, test how to bundle and spread messages efficiently.

Why it matters:
This keeps Ethereum future‑proof and gives client teams a shared place to experiment in the open.

• Finalize the Devnet‑0 plan in the new coordination repo.

• Try short 4‑second slots and a newer network setting (called gossipsub v1.2) to speed up experiments.

• Publish easy Python test files and set up repeatable devnet tooling.

• This month: Lock Devnet‑0 settings.

• Next: Run Devnet‑0 (basic chain), then Devnet‑1 (add post‑quantum signatures) when libraries are ready.

• By Devconnect (November): Stretch goal for a PQ‑signature devnet if everything lines up.

What this is:
When apps talk to Ethereum nodes, they use RPC—a standard set of requests and replies. The group keeps those standards clean and well‑tested.

What changed:

• A test for e_simulate is failing; a fix is on the way.

• A small “schema viewer” now pops up and shows exactly where a test failed, which makes debugging much easier.

• The group will pick one JSON‑Schema version and explore a linter so mistakes are caught early.

Why it matters:
Better tools → clearer errors → faster fixes across clients and libraries.

• Merge the e_simulate test fix.

• Use the schema viewer in CI and local testing.

• Agree on a JSON‑Schema baseline and trial a linter.

• Before the next call: Land the e_simulate fix and the first schema‑viewer integration.

• This quarter: Lock the schema version and test the linter in CI.

The idea:
Use a tiny “secret lottery” each slot to pick who builds the next block. The winner can check privately if they won and later prove it to everyone with a short cryptographic proof (a VRF). Hiding the winner until reveal can reduce targeted attacks.

Open questions:
How best to feed randomness into the lottery, and how it behaves under stress or bribery attempts.

• Write a short, concrete spec for review.

• Build a small prototype and run simulations.

The idea:
A zkVM (zero-knowledge virtual machine) runs code and proves it ran correctly. This note lays out a clear map of memory:

• ROM: set once, then read‑only (like a sealed manual).

• RAM: normal read/write space (like a working table).

• INPUT/OUTPUT/System: dedicated areas so nothing gets mixed up.

It also defines simple rules for how reads and writes are ordered, and a small alignment helper so odd‑sized reads act predictably. Clarity here makes proofs easier and faster.

• Freeze the memory layout and rules.

• Publish test cases that show reads/writes across all regions.

• EIP-7979: Call and Return Opcodes for the EVM — Adds opcodes to make calling and returning in smart contracts simpler and cheaper.

• The BIG ‘introduce yourself’ thread — Community welcome thread for quick intros and what folks are working on.

• ERC-7818: Expirable ERC20 — Tokens that can expire after a set time (think promos, allowances, or rebates).

• Soliciting stakeholder feedback on Glamsterdam headliners — Gathering input on which features should lead the next upgrade.

• Increasing address size from 20 to 32 bytes — Debate on moving to 32‑byte addresses and what that would mean for UX, storage, and tooling.

• EIP-7987: Transaction Gas Limit Cap at 2^24 — Caps how much gas a single transaction can use for safety and predictability.

• New ERC: Best Practices for Dapps (dappspec)

For more updates subscribe to Ethereum Daily and follow us on the social media platforms below.

Disclosures: Ethereum Daily is an independent publication and does not offer financial or investment advice. Content may include opinions, affiliate links, or references to projects in which contributors have a financial interest. Always do your own research.