We’re bringing ethrex to @EFDevcon. We’d like to exchange ideas with other teams, hear what you’re working on, and connect with people using ethrex or interested in trying it. DM us to coordinate a meetup.

Great to see ethrex proving Sepolia blocks side by side with @openvm_org. Ethereum’s move toward execution proofs should preserve client diversity from day one. Thanks @ignaciohagopia, @TauLepton_, and everyone bringing EIP-8025 to life!

ethrex v30.0.1 unschedules Glamsterdam on Hoodi, after the ACDE call unscheduled it yesterday. If you run a Hoodi node on v30.0.0, or on one of its release candidates, you need this release before 26 October at 17:42:48 UTC. That is the time v30.0.0 still has the fork set for, and a node that activates it alone splits off from the rest of Hoodi. L2 operators running a sequencer or a follower should upgrade too. Mainnet and Sepolia are unchanged, so operators there who do not run an L2 or the stateless validator can stay on v30.0.0. ⚠️ The stateless-validator guests move to ERE v0.19.5 (SP1 v6.9.0, ZisK v1.3.2-alpha), and the ZisK guest's verification key changes. Anyone who verifies ethrex's stateless-validator proofs, such as zkEVM integrations, has to move to this release's keys together. Node operators who do not use the stateless validator are unaffected. The rest of the release is mostly L2 reliability. A follower whose head was past the last sealed batch used to stop importing blocks when the sequencer or the follower restarted, and only wiping its data brought it back; it now resumes from its own head. A node holding more than one connection to the sequencer could stall mid-sync with RPC and logging frozen, so blocks are now imported in order by a single importer per node. Catch-up is faster as well: the sequencer sends a reconnecting peer only the blocks it is missing and up to 16 batches at a time, and followers no longer commit trie layers to disk after every imported block. Also in v30.0.1: - Stateless validation: witnesses with trie paths that do not end at the hashed key length are rejected, and zero-amount withdrawals read their recipient, as the specification requires. The check runs while the witness tries are rebuilt, so it adds little proving cost. - Block building: withdrawals are applied before the request system calls, the order the specification and block import already use. Only chains with custom request predeploy code were affected, not mainnet or the public testnets. - Networking: node records are encoded without base64 padding, so clients with strict parsers can bootstrap from an ethrex node. If you run ethrex on Hoodi, upgrade before 26 October. No resync is needed.

ethrex v30.0.0 schedules Glamsterdam on Hoodi. If you run ethrex on Hoodi, this is the release you need to follow the fork. Hoodi activates Glamsterdam at timestamp 1793036568, which is 2026-10-26 17:42:48 UTC. This is the first ethrex release with the fork scheduled on Hoodi, so earlier releases stop following the chain at that point, and it needs to be paired with a consensus client release that ships the Hoodi Gloas config. Mainnet has no Glamsterdam time scheduled. ⚠️ L2: the prover and the SP1 guest move to SP1 6.9.0, and SP1 6 proofs need the SP1 v6.1.0 Groth16 verifier. An existing deployment's SP1 5 verifier rejects them whatever key is registered, so the order matters. Let every committed batch be verified before the upgraded sequencer commits anything, then upgrade the OnChainProposer and replace the verifier in a single Timelock call, upgradeToAndCall(newImplementation, upgradeSP1Verifier(newVerifier)), and register this release's verification key. Full procedure: Aligned mode is unavailable until Aligned ships SP1 6 support, and the OpenVM L2 prover backend is removed. L1 node operators are unaffected. The rest of the release is mostly hardening, on the paths where something outside the node decides how much work it does. JSON-RPC parsing is bounded in memory and the Auth-RPC token is checked before the request body is read. eth_getLogs and log filter polls are bounded in cost, serving eth/72 cells to peers is bounded in CPU, and what a peer's transaction announcements can make the node track is bounded. Maps keyed by contract- or block-chosen values are seeded, and MODEXP gas is charged before its operands are sized. Also in v30.0.0: - RPC: eth_getFilterChanges reports each new log once, and the receipts of blocks still held in memory come back in full. - Sync: snap/2 catch-up charges peers that cannot serve block access lists, and accounts left with no storage slots get the empty storage root. - Performance and zkVM guests: calldata, CALL arguments and CREATE initcode are no longer copied per call, so zkVM guests stop running out of heap. Finality pruning no longer piles up overlapping range deletes, and state-history journaling skips layers that are already final. - L2: the committer generates the prover input for batches another build sealed, so a sequencer that takes over, or batches committed again after a revert, can still be proven. If you run ethrex on Hoodi, upgrade before 26 October. Everyone else, upgrade at your convenience. No resync is needed.

From our point of view, yesterday's ACDC decision on EIP-8025 was the wrong call for Ethereum's long-term interests. EIP-8025 proposes optional execution proofs, a first step toward the zkEVM roadmap, and the client teams declined to commit to it. Framing the proposal as an "optional feature" may have worked against it. Calling something optional makes it easy to dismiss as low priority. To be clear, it was a proposal, and proposals can be accepted or rejected; nothing obligated anyone to approve it. And it is true that this feature does not inherently require a hard fork. But that is precisely what makes the question of commitment unavoidable: with nothing at the protocol level forcing the work to happen, progress depends entirely on whether people are actually assigned to it. Execution proofs only become real if client developers implement them, if testing teams build the coverage they need, and if DevOps keeps the infrastructure running. Declining to prioritize the proposal means the work simply does not happen. The optionality was meant for operators, those choosing whether to enable execution proofs, not for the people deciding whether the work happens at all. Operators should be able to opt in regardless of which client they run, and a decision taken without all teams present cannot credibly settle a question that depends on all teams delivering. Optional proofs are the foundation of Ethereum's zkEVM roadmap. That roadmap is complex, and it demands extensive integration and testing across teams. Getting there requires a shared, sustained commitment. We need to test under realistic conditions and investigate failures before consensus depends on proofs, and that work should proceed alongside research into mandatory proofs. Every integration bug we uncover now is one we won't be discovering after consensus depends on it. The more groundwork we lay today, the more bandwidth we have later for the challenges specific to mandatory proofs, including the ones we haven't found yet.

At the latest ACDT meeting, we decided to rename the devnet branches to better reflect their scope. The FOCIL devnets are now called Heze and will include CL EIPs, while the Frames devnets are now called Bogotá and will include EL EIPs. The combined devnets that follow will be called Hegotá, following the usual naming convention. The launch of bogota-devnet-1 (formerly frames-devnet-1) is just around the corner, with EIPs 8141, 8250, 8272, and 7906 included. The latest execution spec tests release (bogota-devnet@v1.1.0) is already out, and we’re passing all the tests! We’re excited to see this devnet go live!

It’s been a couple of weeks since the first official Frame Transactions devnet launched. frames-devnet-0, which includes only EIP-8141, will soon give way to frames-devnet-1, adding EIP-8250, EIP-8272, and EIP-7906. The execution-spec tests for frames-devnet-1 (frames-devnet@v1.0.0) came out today, and ethrex already implements the required changes and passes the full suite! We’ve been working on these EIPs for a while, and it shows 😉. Getting ready for devnets is starting to feel routine 💅.

ethrex leading stateful Glamsterdam repricing benchmarks 🫡 We are in the top 3 for the compute ones, and after a couple of performance improvements land on main, we'll likely lead that one too.

The official @ethPandaOps frames devnet is live: frames-devnet-0 is now the shared testing ground for EIP-8141 frame transactions, and ethrex is running on it. We've hosted a public frames testnet since frames were first proposed as a headliner, so builders and client teams had somewhere to test while the spec settled. @Nethermind validated on it, and @go_ethereum joined the effort along the way, and it did its job. Now that there's an official devnet, we're shutting ours down so everyone tests against one network. Thanks to everyone who built on it, validated on it, and reported bugs. If you want to keep testing frames, move over here:

Over the last few months, we've been working with EF researchers and EIP authors on Hegota proposals, implementing them in ethrex and opening our public testnets to users and other client teams. We wanted to share our execution EIP tier list, which follows the EF Protocol team's scoring system and tier definitions. After spending these months building and testing several of these proposals, we're excited to contribute to the discussion of what should come next for Ethereum. We'll also share our consensus EIP tier list soon, as part of a blog post where we'll expand on our thoughts about Hegota.

We are running a public testnet for the EIPs behind Ethereum's privacy roadmap, built on top of Glamsterdam. It runs EIP-8141 (Frame Transactions), EIP-8250 (Keyed Nonces), EIP-8272 (Recent Roots), EIP-7805 (FOCIL), and EIP-8369 (VOPS profiles), each implementation up to date with its spec. The frames implementation matches the latest execution spec tests release. Anyone can sync, peer, transact, and use the faucet to fund test accounts. The only permissioned part of the network is validator entry. If your client team is working on any of these EIPs and wants to validate, reach out to us, and we'll get you set up with deposit tokens. RPC, explorer, and tooling notes:

EIP-8141 (Frame Transactions) was SFI'd in the last ACDE. We've been frames-pilled since it was first proposed as a headliner, and we started building a reference implementation on ethrex back then. Adoption grew with time: other clients picked frames up, there are now execution spec tests (our implementation matches the latest release), and an official EthPandaOps-hosted frames devnet is getting close. We didn't want to make anyone wait for it, so we're already hosting a public testnet for frame transactions, built on top of Glamsterdam. Validator entry is permissioned; everything else on the chain is not. Anyone can sync, peer, and transact, and the faucet funds test accounts. If your client team is working on frames and wants to validate, reach out and we'll set you up with deposit tokens. RPC, explorer, and frame tooling, including a CLI that builds and submits frame transactions:

ethrex has been running in production on Ethereum mainnet for six months. Independent staking operators validate through it, and we wrote up what those months actually looked like. The short version: @SerenitaIO, @Stakely_io, and @RockLogicGmbH (among Lido's curated operators) run ethrex alongside the other execution clients. @LeastAuthority audited the full stack, and every finding is addressed. Thirteen stable releases since January, weekly since May, and every upgrade is a drop-in restart with no resync. The write-up also covers what a young client's first months really involve: getting shipped by eth-docker from @ethStaker, Stereum from @stereumdev, and @EthereumOnARM, getting marked stable on clientdiversity (.org), first interop as a participating client, and the parts that aren't solved yet. Market share is still minimal, some packagers lag a few versions behind, and a couple of integrations are still open PRs. Our conformance and Hive results stay public, whether they flatter us or not. If you run validators and want a second (or fifth) execution client: ethrex syncs mainnet in about an hour and a half on 4-8 cores, 32 GB RAM, and a 1 TB NVMe. Read the full story in our new blog post ⬇️

We open-sourced libssz, a fast, no_std SSZ library in Rust. It's available on EL clients are picking up SSZ. In ethrex we keep dependencies minimal and care a lot about performance, so we built our own: fast for binary SSZ transport, fast and zkVM-friendly for EIP-8025 proving. Faster than Lighthouse on encode and decode. Passes 62,489 consensus spec tests across all forks. Multiple differential fuzz targets against Lighthouse and ssz_rs are running nightly. Pluggable SHA-256 backend so zkVM vendors can use their own accelerators. We're already using it in @ethrex_client and @ethlambda_lean. ere-guests switched and measured a 2x hash_tree_root speedup inside ziskemu. Compiles on RISC-V and thumbv7m out of the box.