01 / EXECUTIONIn review
Compute roots together.
Parallel transaction, receipt, and state roots for larger blocks. Reported root-phase gains vary from 3–21%; the sequential-pair result was within noise.
Review the experiment · #334
THE XDC CLIENT COLLECTIVE
xOne.
One network.
Many minds.
Four ways to build the future of XDC.
Independent code. A shared protocol.
BUILT FOR THE PEOPLEWHO BUILD THE NETWORK
01 / THE FAMILYFind your language.02 / PERFORMANCEFollow the evidence.03 / SIDE BY SIDEChoose with context.
01 / THE CLIENT FAMILY
DIFFERENT BY DESIGNYour language.
Your way in.
Pick a codebase that feels like home.
Explore its architecture, follow the evidence,
and help shape what comes next.
Development clientGPL-3.0-or-later
A Rust foundation for XDC.
A layered Rust execution client with revm, MDBX storage, and XDPoS V1/V2 consensus. Documented follower paths for Apothem and net2040.
- RUNTIME
- Native / Rust
- STATE STORE
- MDBX
- EXECUTION
- revm + XDC hooks
- CURRENT FOCUS
- Conformance & operations
↳ All four clients are in development. Rust mainnet following is not yet qualified; mainnet block production remains gated across the family. Read the readiness evidence
02 / THE PERFORMANCE LAB
MEASURE. IMPROVE. VERIFY.Performance.
With proof.
Smarter execution. A smaller working set.
Explore the reported results, the conditions behind them, and the next improvements.
xOneRS / SIGNER RECOVERYMerged · PR #319
52%
less replay CPU
A libsecp256k1 change reduced reported CPU work in a 20,000-block net2040 replay. Zero mismatches were reported in each run.
Read the original resultContext matters. Shared Intel i5-13500 build host under heavy, variable load. This is CPU time for a replay, not wall-clock latency, follower throughput, or a comparison against another client. Repository-reported results; not independently reproduced here.
Workload, build, and measurement method
WHAT WAS MEASURED
Sequential replay from genesis to block 20,000, release build, nice -n 19, checkpoint-every 0. Each run reports 200 archive hash checks and 11 V2 epoch switches.
IMPLEMENTATION & EVIDENCE
Before: b055158. After: 5839f94. Change merged as PR #319; reported measurements were not independently reproduced here.
Open the linked engineering work02 / DISK & STORAGETracked work
Retain what you need.
Separate hot state from history. Add retention policies, compressed segments, and bounded cleanup. Disk savings still need a controlled measurement.
Explore pruning · #17703 / RPC & QUERIESTracked work
Make queries predictable.
Replay real traffic by method. Measure tail latency under load, then verify log-index and bloom-filter improvements against the same requests.
Follow RPC benchmarking · #197What makes a fair speed comparison?
KEEP THE WORKLOAD EQUAL
- Use the same network, block range, transactions, and state.
- Match full/archive retention, pruning, and RPC configuration.
- Pin client commits, compiler flags, hardware, and storage.
REPORT THE COMPLETE RESULT
- Repeat warm and cold runs; retain variance and failures.
- Separate CPU time, wall time, throughput, and latency.
- Report p50/p95/p99, errors, RSS, disk growth, and correctness.
A controlled cross-client ranking is still pending.Download the evidence
03 / A SHARED DIRECTION
SAME PROTOCOL. MORE PERSPECTIVES.A network is stronger
with more than
one point of view.
Client diversity is an engineering discipline. Different implementations create more ways to inspect, test, and understand the same protocol.
Explore the shared specificationIndependent paths.
Rust, C++, Python, and TypeScript bring different runtimes and engineering perspectives to XDC execution.
Evidence before claims.
Replay records, conformance vectors, and explicit readiness gates make progress inspectable.
Operators in the loop.
Sync, storage, RPC, and recovery are part of the product. Follow the work that makes a client usable.
ONE XDC PROTOCOLRead the decisions
04 / SIDE BY SIDE
THE DETAILS MAKE THE DIFFERENCEOne family.
Distinct choices.
Look beneath the language.
Compare execution, storage, RPC support,
and the performance evidence available today.
Swipe the table to compare all four clients →
Present in source Partial / limited Missing / not measured
| CAPABILITY | xOneRSRUST | xOneCC++ | xOnePyPYTHON | xOneTSTYPESCRIPT |
|---|---|---|---|---|
| Language / runtime | Rust / nativeSource | C++23 / nativeSource | Python / CPythonSource | TypeScript / BunSource |
| Execution engine | revm + XDC hooksSource | C++ EVM interpreterSource | py-evm adapterSource | EthereumJS adapterSource |
| State storage | MDBXAppend-only history segmentsSource | libmdbxSource | SQLite WALSource | SQLiteSource |
| License | GPL-3.0-or-laterSource | MITSource | MITSource | Apache-2.0Source |
| Repository | PublicSource | Access requiredSource | Access requiredSource | Access requiredSource |
| Mainnet production | GatedDevelopment clientSource | GatedDevelopment clientSource | GatedDevelopment clientSource | GatedDevelopment clientSource |
Four implementations of the XDC protocol, with different engines and storage choices. Language alone does not establish performance.
| CLIENT | LANGUAGE | NETWORK / ROLE | PERFORMANCE / OPERATIONS | EXPLORE |
|---|---|---|---|---|
| xOne familyFour development implementations | Rust · C++ · Python · TS | XDC / XDPoS | Independent implementations & conformance | Source |
| XDPoSChainXDC reference | Go | XDC / XDPoS | XDC protocol & node operation | Source |
| Gethgo-ethereum | Go | Ethereum execution | Snap state synchronization | Source |
| Rethparadigmxyz/reth | Rust | Ethereum execution | Archive, full, minimal & custom pruning | Source |
| Erigonerigontech/erigon | Go | Ethereum execution | History profiles & snapshot retirement | Source |
| NethermindXDC plugin present in source | C# | Ethereum · XDC plugin | Configurable state pruning | Source |
| Besubesu-eth/besu | Java | Ethereum & private networks | Performance, JVM & operations guides | Source |
| ethrexlambdaclass/ethrex | Rust | Ethereum execution | Snap synchronization design | Source |
Source snapshot · 14 NOV 2026
Source presence does not certify live readiness. Comparable cross-client throughput, sync, RAM, and disk benchmarks have not been established in this review.
View audit & sources05 / FROM CURIOSITY TO CODE
The next chapter
starts in
your terminal.
Explore the Rust client on Apothem, or build a sibling implementation locally. Start with the source and the current readiness notes.
git clone https://github.com/XDCIndia/xOneRS.git
cd xOneRS
cargo build --locked --release -p xone
./target/release/xone --version↳ Build recipe from the repository.
Use its pinned toolchain and platform prerequisites.
Use its pinned toolchain and platform prerequisites.
06 / KEEP EXPLORING
OPEN THE NEXT DOORGet closer
to the protocol.
01
Get to know xOneRS
START HERE02Architecture, status, and the current evidence boundary.
Follow the Apothem network
OPERATOR GUIDE03Rust follower setup, bootnodes, ports, and observability.
Understand storage & recovery
ARCHITECTURE04MDBX, publication rules, disk state, and recovery decisions.
Inspect the conformance record
VERIFICATION05Replay ranges, execution evidence, and known limits.
Explore the gap audit
ENGINEERING06Competitor evidence, client RPC gaps, and the issue ledger.
Pick up an open issue
CONTRIBUTEFollow the development backlog and contribute a focused change.
No matching resources. Try “sync”, “storage”, or “RPC”.
THE NETWORK IS A COLLECTIVE EFFORT.