THE xONE LAB Explore the performance record
xone.sh

REFERENCE

Glossary

Short definitions of the terms used in the xOne guides. Each term has one canonical entry on this page.

Reviewed 15 November 2026. Definitions explain concepts. They do not state that any client is ready for production.

Conformance (Conformance)
Proof, by test, that a client gives the same result as a reference client for the same input. Passing a test range is evidence for that range only. Related: ParityThe state of two clients giving the same block hash, state root and receipts root for the same blocks. Parity is measured over a stated block range., State rootA hash in the block header that commits to the full state after the block. Two clients that disagree on a state root have diverged..
Epoch (Consensus)
A fixed span of blocks. At an epoch boundary the XDPoS rules recompute the masternode set, so boundaries are important test points. Related: XDPoSThe consensus rules of XDC Network. A set of masternodes produce and validate blocks. A client must follow these rules to agree with the network., MasternodeA node that the XDPoS rules select to produce and vote on blocks. A follower node does not produce blocks..
EVM (Execution)
The Ethereum Virtual Machine. It runs contract code and changes state as the rules of the chain define. Related: Execution clientSoftware that checks blocks and transactions, runs the EVM and keeps the resulting state. The xOne family has four execution clients for XDC Network., StateThe account balances, contract code and contract storage at one block. History (headers, bodies, receipts) is separate data. See the storage guide..
Execution client (Execution)
Software that checks blocks and transactions, runs the EVM and keeps the resulting state. The xOne family has four execution clients for XDC Network. Related: EVMThe Ethereum Virtual Machine. It runs contract code and changes state as the rules of the chain define., StateThe account balances, contract code and contract storage at one block. History (headers, bodies, receipts) is separate data. See the storage guide., XDPoSThe consensus rules of XDC Network. A set of masternodes produce and validate blocks. A client must follow these rules to agree with the network..
Follower (Operations)
A node that syncs and verifies the chain but does not produce blocks. The run-a-node guide shows a Rust follower on Apothem. Related: Sync modeHow a node gets its starting data: replay every block (full) or fetch a recent state from peers (snap or fast). Each mode has its own limits. Read the client guide before you change it., MasternodeA node that the XDPoS rules select to produce and vote on blocks. A follower node does not produce blocks..
JSON-RPC (RPC)
The request and response protocol that applications use to read from a node, for example eth_blockNumber. Support differs by client, method and transport. Related: RPC namespaceA group of JSON-RPC methods with one prefix, such as eth_ or debug_. Enable only the namespaces that an application needs..
Masternode (Consensus)
A node that the XDPoS rules select to produce and vote on blocks. A follower node does not produce blocks. Related: XDPoSThe consensus rules of XDC Network. A set of masternodes produce and validate blocks. A client must follow these rules to agree with the network., EpochA fixed span of blocks. At an epoch boundary the XDPoS rules recompute the masternode set, so boundaries are important test points..
Parity (Conformance)
The state of two clients giving the same block hash, state root and receipts root for the same blocks. Parity is measured over a stated block range. Related: ConformanceProof, by test, that a client gives the same result as a reference client for the same input. Passing a test range is evidence for that range only., State rootA hash in the block header that commits to the full state after the block. Two clients that disagree on a state root have diverged..
Quorum certificate (Consensus)
In XDPoS v2, a set of enough masternode votes for a block. A client that verifies blocks checks these certificates. Related: XDPoSThe consensus rules of XDC Network. A set of masternodes produce and validate blocks. A client must follow these rules to agree with the network., MasternodeA node that the XDPoS rules select to produce and vote on blocks. A follower node does not produce blocks..
Retention (Operations)
How much history and state a node keeps on disk. Less retention uses less disk but can remove data that historical queries need. Related: StateThe account balances, contract code and contract storage at one block. History (headers, bodies, receipts) is separate data. See the storage guide., Sync modeHow a node gets its starting data: replay every block (full) or fetch a recent state from peers (snap or fast). Each mode has its own limits. Read the client guide before you change it..
RPC namespace (RPC)
A group of JSON-RPC methods with one prefix, such as eth_ or debug_. Enable only the namespaces that an application needs. Related: JSON-RPCThe request and response protocol that applications use to read from a node, for example eth_blockNumber. Support differs by client, method and transport..
State (Execution)
The account balances, contract code and contract storage at one block. History (headers, bodies, receipts) is separate data. See the storage guide. Related: RetentionHow much history and state a node keeps on disk. Less retention uses less disk but can remove data that historical queries need., State rootA hash in the block header that commits to the full state after the block. Two clients that disagree on a state root have diverged..
State root (Conformance)
A hash in the block header that commits to the full state after the block. Two clients that disagree on a state root have diverged. Related: StateThe account balances, contract code and contract storage at one block. History (headers, bodies, receipts) is separate data. See the storage guide., ParityThe state of two clients giving the same block hash, state root and receipts root for the same blocks. Parity is measured over a stated block range., ConformanceProof, by test, that a client gives the same result as a reference client for the same input. Passing a test range is evidence for that range only..
Sync mode (Operations)
How a node gets its starting data: replay every block (full) or fetch a recent state from peers (snap or fast). Each mode has its own limits. Read the client guide before you change it. Related: FollowerA node that syncs and verifies the chain but does not produce blocks. The run-a-node guide shows a Rust follower on Apothem., RetentionHow much history and state a node keeps on disk. Less retention uses less disk but can remove data that historical queries need..
XDPoS (Consensus)
The consensus rules of XDC Network. A set of masternodes produce and validate blocks. A client must follow these rules to agree with the network. Related: MasternodeA node that the XDPoS rules select to produce and vote on blocks. A follower node does not produce blocks., EpochA fixed span of blocks. At an epoch boundary the XDPoS rules recompute the masternode set, so boundaries are important test points., Quorum certificateIn XDPoS v2, a set of enough masternode votes for a block. A client that verifies blocks checks these certificates..
YOUR NEXT STEP

Build your way.

Choose an implementation to see its source-based build recipe.

Use the pinned Rust toolchain and platform build prerequisites in the repository.

git clone https://github.com/XDCIndia/xOneRS.git
cd xOneRS
cargo build --locked --release -p xone
./target/release/xone --version

This recipe builds the client; it does not start a node. Mainnet operation is not yet qualified.

Open source guide