From geth to reth: The Evolution of X Layer's Execution Client

X Layer is OKX's EVM-compatible Layer 2 network built on the OP Stack. Since its launch, X Layer has undergone two major architectural transitions: an initial migration from Polygon CDK (zkEVM Validium) to the OP Stack, followed by a swap of the execution client from geth to reth. This post covers the second transition — the rationale behind choosing reth and the engineering work required to make it production-ready for X Layer.

The default execution client for OP Stack chains is geth, a fork of go-ethereum maintained alongside the Optimism codebase. geth is battle-tested and widely deployed, but as transaction throughput scales, two structural limitations of the go-ethereum architecture become increasingly difficult to work around.The first is storage growth. Geth's archive node disk usage expands linearly with chain history, and at L2 throughput levels the rate is significant enough to create real operational pressure over time. The second is latency consistency. Go's garbage collector introduces non-deterministic pauses under sustained load, and background LevelDB/PebbleDB compaction periodically stalls block production — both of which show up as tail latency spikes that users feel directly.Reth, Paradigm's Rust reimplementation of an Ethereum execution client, addresses both at the architecture level. Rust's compile-time memory model eliminates the runtime GC entirely. reth pairs this with the MDBX storage engine and a staged sync pipeline, delivering meaningfully better disk efficiency and more predictable latency under load.Extensibility was equally important. Reth ships a full Node Builder API — a set of well-defined hooks that let you inject custom logic into the node lifecycle without modifying upstream source. For an L2 execution client that requires significant customization, this matters: upgrades stay tractable, custom logic stays isolated, and the gap between your client and upstream never quietly grows out of control.

xlayer-reth sits at the top of a three-layer dependency hierarchy:

All X Layer–specific code lives exclusively in the top layer, wired in through reth's extension hooks. The two layers below are consumed as-is from their respective upstream repositories, with no private patches applied. This structure makes it straightforward to pull in upstream security fixes and performance improvements — merging upstream changes doesn't require reconciling a divergent core.Each feature is organized as an independent crate: Chainspec, the legacy RPC router, Flashblocks, custom RPC extensions, and others. The main binary assembles them. Each crate evolves and is tested in isolation.

xlayer-reth ships a complete Chainspec for each of X Layer's three networks: mainnet (chain ID 196), testnet, and devnet. Each spec encodes the chain ID, genesis block parameters, and the full hardfork activation schedule.Every Ethereum hardfork from Frontier through OP Stack Isthmus is activated at genesis. A newly synced node starts with full EVM capability from its genesis block, without needing to replay protocol transitions. This avoids the complexity of bootstrapping a node that must walk through historical fork rules before reaching the current execution environment.X Layer also introduces a custom hardfork named Jovian, corresponding to OP Stack Network Upgrade 17. Jovian activated on mainnet in December 2025, keeping X Layer's protocol evolution synchronized with the broader OP ecosystem.

xlayer-reth exposes two X Layer–specific JSON-RPC methods alongside the standard Ethereum API:

• eth_flashblocksEnabled — returns whether the node's Flashblocks service is active and receives data from the sequencer.

• eth_flashblocksPeerStatus — returns the P2P peer connectivity status of the Flashblocks layer on sequencer nodes, primarily for operational monitoring.

Both methods are registered via reth's RPC extension mechanism and coexist with the standard API without modifying or conflicting with any existing method behavior.

The move from geth to reth was motivated by performance — lower block construction latency, reduced storage footprint, and faster node sync times. Realizing those gains in production required building out the execution layer features specific to X Layer's history and operational requirements: a non-zero genesis block inherited from a prior chain, years of historical state stored on a legacy node, chain configuration spanning two protocol architectures, a pre-confirmation system that fundamentally changes how clients interact with pending state, and the operational tooling to monitor the system.Building on a mature open-source framework rather than forking core infrastructure, and contributing reusable improvements back to that framework, is how X Layer approaches sustainable infrastructure development — and how the broader L2 ecosystem benefits from work done by individual teams.