ethrex

A modular, Ethereum L1 & L2 execution client in Rust. Built by @class_lambda.

[ethrex @ethrex_client]

Don't forget, our Community Call is tomorrow at 2:30 PM UTC on X. We'll cover what we've been shipping and where we're headed next.

[ethrex @ethrex_client]

With psn, your wallet can use a local node that holds the state it needs and checks the answers it serves. EIP-8440 support adds a path toward verifying the execution behind those answers, too.

The mode is experimental, Sepolia-only for now, and behind a Cargo feature. Existing ethrex nodes are unaffected, and no resync is needed.

We’d love wallet builders and node operators to try it and share their feedback. We want more wallet users to have a small node of their own.

[ethrex @ethrex_client]

We loved chibi, so we added partial stateful node support to ethrex.

A node for your wallet that keeps only the accounts and storage you use, verifies the values it serves, and follows the chain without executing blocks. Your wallet gets local JSON-RPC, with no RPC provider to trust.

In one Sepolia run: 29–34 MB of memory, about 3% of one core, and negligible disk usage beyond the binary. Anchoring took a couple of minutes while waiting for a peer that answered headers. Experimental and Sepolia-only for now, since it needs Glamsterdam’s block access lists.

We’ve also added experimental EIP-8440 execution chain proof support, with off (default), observe, and require modes. Require serves state only at blocks covered by a verified proof.

https://t.co/GkQgLmahWA

Let’s walk through what the node actually does 👇

[Wei Han Ng @weiihannng]

Partial stateful node is here!

Happy to announce chibi: a node that syncs in minutes and lets you transact through your own local RPC. Trust no one because every value is proven.

It runs on practically any hardware. Need to send a transaction? Don't need to rely on RPC providers, just spin up chibi and send it right away. Live on Sepolia today and Hoodi next.

👇 demo below

[ethrex @ethrex_client]

There’s a distinction between authenticating state and proving execution.

A Merkle proof establishes that a value matches a header. A sync committee signature authenticates that header. Neither independently establishes that the block executed correctly.

A full node checks execution itself. EIP-8440 would let psn check it through an execution chain proof.

EIP-8025 covers individual payloads. EIP-8440 proposes recursive proofs covering execution from an origin block to a head. With an origin at or before your checkpoint, one recent proof could establish that every payload along that stretch executed validly.

That fits a wallet node: it wouldn’t need to collect every intermediate block and proof.

The three proof modes control how that integration affects the node.

off follows the light client’s head. observe follows that head while checking proofs and reporting coverage. require starts at the checkpoint and advances only to payloads covered by verified chain proofs whose origin is at or before it.

[ethrex @ethrex_client]

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: https://t.co/FmYlds6DGY. 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.

[ethrex @ethrex_client]

heze-devnet-2 specs: https://t.co/MdRW1KRI9P
Hive runs: https://t.co/QF1rNdyd0g

[ethrex @ethrex_client]

The Hive tests for Heze devnet 2 are live, and ethrex is the first EL client ready to run them. Our heze-devnet-2 branch is already passing the full suite!

The devnet itself hasn’t launched yet. Its planned scope includes:

- FOCIL (EIP-7805)
- Removal of the deposit and eth1data fields (EIP-8015)
- Disallowing new validators with 0x00 withdrawal credentials (EIP-8365)
- Quick Slots (EIP-8198)

[ethrex @ethrex_client]

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 ([email protected]) is already out, and we’re passing all the tests!

We’re excited to see this devnet go live! https://t.co/Kzo3pIMhBH

[ethrex @ethrex_client]

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.

[Forkcast @forkcast_eth]

hegota scoping ⚡

ACDC #189 - ultra tl;dr

DFI:
🪓 7716: Anti-Correlation Attestation Penalties
🪓 8025: Optional Execution Proofs
🪓 8359: Beacon Block Reporting Field
🪓 8371: RowDAS

generally liked EIPs, but teams found that they weren't urgent enough to schedule (7716, 8359, 8371) or that they could be tackled without CFI (8025)

5 more EIPs to assess next meeting

video and summary:
https://t.co/xhINSmwsxj

[ethrex @ethrex_client]

@kenzimerkie We'll be enabling DMs from verified accounts soon. In the meantime, connect with @lean_knack, please.

[ethrex @ethrex_client]

ethrex is validating Ethereum mainnet blocks inside @titanrelayxyz!

@gattacahq has integrated ethrex into Helix, the open-source software behind their relay, to execute submitted blocks and verify their validity.

Titan accounted for roughly 32% of relay payload deliveries tracked by @relayscan_io in the seven days ending October 6. ethrex is part of the validation infrastructure supporting that operation.

We're building ethrex so other teams can build on it. Proud to see Gattaca putting it to work in Ethereum's block production pipeline.

[ethrex @ethrex_client]

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 ([email protected]) is already out, and we’re passing all the tests!

We’re excited to see this devnet go live! https://t.co/Kzo3pIMhBH

[ethrex @ethrex_client]

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 ([email protected]) 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 @ethrex_client]

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 ([email protected]) 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 @ethrex_client]

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: https://t.co/KwF0e3AGTC

[ethrex @ethrex_client]

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.

[ethrex @ethrex_client]

Explore Helix on GitHub: https://t.co/yloFkBhsqu
Relayscan: https://t.co/hzKzGpgFBD

[ethrex @ethrex_client]

Don't forget, our Community Call is tomorrow at 2:30 PM UTC on X. We'll cover what we've been shipping and where we're headed next.

[ethlambda @ethlambda_lean]

Proud to see all ethlambda validators perform as expected through Sepolia's Glamsterdam transition.
Great milestone for the team.

[ethrex @ethrex_client]

ethrex handled Sepolia’s transition to Glamsterdam without issues!

We’re running 100 validators on Sepolia across different setups, all backed by ethrex.

After our first appearance in an EF upgrade announcement, we’re proud to follow through with a smooth fork on Sepolia and help ship Ethereum’s next upgrade. Next stop: Hoodi, with our sights on mainnet.

A shoutout to @ethlambda_lean: ten of our validators ran ethlambda, and all ten performed as expected through the transition.