02 / THE DEVELOPER HANDBOOK
From curiosity
to your terminal.
A practical map through the xOne clients, the XDC networks, and the evidence behind each implementation.
Start with the right path.Build from source.
Pick a language. Verify a build.
02 / OPERATORSFollow the network.
Start with the Rust Apothem guide.
03 / CONTRIBUTORSMove the work forward.
Find a focused change to review.
THE COMPLETE SITE INDEX
Find your next step.
38 pages to explore
Client family
Independent implementations bring different tools, runtimes, and engineering perspectives to the same XDC protocol.
02 /xOneRS
A layered Rust execution client with revm, MDBX storage, and XDPoS V1/V2 consensus. Documented follower paths for Apothem and net2040.
03 /xOneC
A C++23 execution client with its own EVM interpreter, libmdbx storage, and XDC consensus modules. Explore the source and current development gates.
04 /xOnePy
A Python execution client with typed workspace packages, a py-evm adapter, and SQLite WAL storage. Explore follower, snapshot, and producer implementations.
05 /xOneTS
A TypeScript execution client on Bun, with modular packages, an EthereumJS EVM adapter, and SQLite-backed state. Built for developers who think in TypeScript.
06 /Documentation hub
A practical map through the xOne clients, the XDC networks, and the evidence behind each implementation.
07 /Getting started
Choose a language, check repository access, and verify a local build before connecting it to a network.
08 /Networks & connectivity
Network identity comes first. Keep test assets, data directories, and configuration separate between environments.
09 /Run a follower
A source-based Rust follower path for chain 51. This recipe does not enable mining or signing.
10 /Node operations
Keep build identity, network progress, disk growth, and recovery evidence close to the node.
11 /Storage & sync
Sync mode, state placement, and history retention solve different problems. Choose them against the data your workload needs.
12 /JSON-RPC
JSON-RPC compatibility varies by client, method, and transport. Inspect the source-backed matrix before relying on an API.
13 /Architecture
A shared protocol, implemented through independent runtimes. Start with the Rust layering, then compare the sibling designs.
14 /Troubleshooting
Start with the observable symptom. Preserve enough context to distinguish configuration, connectivity, storage, and protocol failures.
15 /Performance lab
Explore repository-reported CPU, memory, and RPC observations alongside their workload, conditions, and limits.
16 /Compare clients
Compare the four xOne implementations, then explore the wider execution-client ecosystem. The source review is dated 14 November 2026.
17 /Roadmap
xOne qualification gates, seven competitor planning references, and a source-linked opportunity backlog. Evidence defines the next step.
18 /Releases & builds
Start from the source, inspect available release artifacts, and retain the identity of every binary you deploy.
19 /Contribute
Protocol engineering, testing, operations, documentation, and reproducible bug reports all move the project forward.
20 /About xOne
xOne is a family of XDC execution-client implementations in Rust, C++, Python, and TypeScript.
21 /Frequently asked questions
Practical answers about the client family, development status, builds, and operation.
22 /Resource library
Find a guide, inspect the evidence, or open the source. Choose a path by the work in front of you.
23 /XDC ecosystem
Public network resources for learning, testing, and inspecting XDC. Inclusion is a useful link, not a claim of partnership or xOne integration.
24 /Community
Start a technical conversation in the place where the work can be reproduced, reviewed, and followed through.
25 /Security
Understand the limits of the reviewed builds, keep sensitive interfaces bounded, and handle vulnerability details carefully.
26 /xOne home
One network. Many minds. The client collective.
27 /Field notes journal
Read the xOne client blog.
28 /Engineering audit
Source evidence, feature gaps, findings, and issue references.
29 /The conformance and replay gate
How xOne checks its blocks, roots and RPC answers against a pinned geth-XDC, and what 0 mismatches covers today.
30 /Four clients, one protocol: what each xOne client is for
xOneRS, xOneTS, xOnePy and xOneC implement the same XDC rules from one specification; this post compares them and says how to choose.
31 /Archive mode in xOne
What an archive node is, which RPC reads need one, and the archive status of each xOne client on main today.
32 /How xOne releases are made, and how to read the version stamp
The current tags of the four xOne clients, the version stamp format, and the checks a release must pass.
33 /The xOne JSON-RPC surface and how parity is checked
Which JSON-RPC namespaces xOneRS serves, how they are exposed, how answers are diffed against geth-XDC, and what is still missing.
34 /How sync works in xOne: full, snap, fast and minimal
What each sync mode downloads, verifies and keeps in the four xOne clients, which flag selects it, and which modes run on net2040 today.
35 /xOneRS: a Rust foundation for XDC
A layered Rust execution client with revm, MDBX storage, and XDPoS V1/V2 consensus.
36 /xOneC: close to the machine, open to ideas
A C++23 execution client with its own EVM interpreter, libmdbx storage, and XDC consensus modules.
37 /xOnePy: a readable path into the protocol
A Python execution client with typed workspace packages, a py-evm adapter, and SQLite WAL storage.
38 /xOneTS: the protocol, in a familiar language
A TypeScript execution client on Bun, with modular packages, an EthereumJS EVM adapter, and SQLite-backed state.
KEEP THE CURIOSITY GOING