R3E Network has released neox-rs, a Rust-based Neo X full-node client built on Paradigm’s Reth framework, giving the network its first alternative implementation alongside the existing Go-based Neo X Geth. The client, currently at pre-release v2.4.1-rc.5, has completed a full MainNet sync of approximately 7.15 million blocks with zero state-root mismatch, though it is not yet approved for MainNet validator use.

Reth is a modular Ethereum execution client developed by Paradigm, written in Rust and designed for performance and extensibility. neox-rs extends Reth’s EVM, RPC, and staged sync architecture with Neo X-specific protocol support, including dBFT consensus finality, the anti-MEV envelope system powered by threshold public-key encryption, and distributed key generation with a 5-of-7 threshold scheme.

Jimmy Liao, Neo core developer and R3E Network founder, announced the release on July 20:

“Introducing neox-rs: a Reth-based Rust full node with full Neo X protocol support. It provides an independent client implementation that syncs from the Neo X network and reproduces canonical block hashes and execution roots, bringing Reth’s modular node stack to Neo X.”

Verification and interoperability

The neox-rs client has been verified across the full span of Neo X’s MainNet history, including blocks spanning the pre-DKG, DKG (height 3,623,040), and anti-MEV (height 3,749,760) eras. Block hashes and state roots were checked against public reference checkpoints with no discrepancies found.

Mixed-client network testing has also been completed. In a test environment combining neox-rs and Neo X Geth validators, both clients successfully produced and validated blocks for each other, confirming lockstep dBFT finality across implementations. A separate smoke test ran one neox-rs node alongside eight Geth clients on a ZK private network.

Performance benchmarks

Initial benchmarks show modest performance advantages for neox-rs in certain workloads. Across 22 semantic RPC test cases, neox-rs demonstrated a 1.05x median throughput advantage over Neo X Geth at concurrency level four, with specific improvements of 30.6% for eth_getCode and 20.2% for full block retrieval.

In a MainNet sync benchmark covering blocks one through 20,000, neox-rs completed first in all six paired runs with a median speed advantage of 1.45x. The release notes caution that early blocks are transaction-sparse and the results do not generalize to overall full-node sync performance.

Security review

Five independent adversarial reviewers conducted an internal security review of neox-rs. Two findings were confirmed and fixed. The first, rated high severity, involved a pre-authorization CPU denial-of-service vector where an unauthenticated peer could force approximately 100,000 BLS12-381 subgroup checks per frame via a crafted dBFT recovery message. The fix moved payload decoding to a separate validation step after sender authorization.

The second finding, rated low severity, addressed private key material left in freed heap memory during raw file reads. The fix copies key data to a fixed array and wipes the source buffer.

No defects were found in quorum arithmetic, witness verification, subgroup validation, ECDSA parent-reseal paths, governance storage-slot derivation, or policy-aware pool enforcement. The review recommends an independent third-party audit before any MainNet validator deployment.

Pre-release status

Liao was explicit about the client’s current limitations, stating: “Validator prerelease, not for MainNet validators. DKG validation, Anti-MEV decryption, and validator gates are in progress.”

Several gates remain open before neox-rs can be considered for validator use. These include completing a full DKG window with on-chain proof submission, end-to-end anti-MEV decryption during live block production, and an independent third-party security audit. Full-node operation in a non-validator capacity is currently functional.

Client diversity

The release introduces client diversity to Neo X for the first time. Since launch, the network has relied on a single client, Neo X Geth, maintained by Bane Labs and built as a fork of Ethereum’s Go-based Geth. Ethereum’s own ecosystem maintains multiple independent execution and consensus clients specifically to reduce correlated failure risk. A bug in a supermajority client could compromise network finality or cause chain splits. An independent Rust implementation built on a different codebase provides Neo X with a similar safeguard, should neox-rs reach production readiness.

Operational tooling

The rc.5 release ships with operational infrastructure for node operators, including a health monitoring script that polls RPC and Prometheus endpoints with alerting via Better Stack, Prometheus alert rules for detecting stalled block height, peer loss, dBFT rejection spikes, and DKG failures, and hardened systemd service units. A one-line installer script and a DKG keystore migration utility for operators transitioning from Geth are also included.

Binary packages are available for Linux x86_64, Linux ARM64, and macOS Apple Silicon. The project is licensed under Apache 2.0.

The full release can be found at the link below:
https://github.com/r3e-network/neox-rs/releases/tag/neox-v2.4.1-rc.5