OPERATE THE NETWORK

Run an XDC node

Choose a node role, understand participation requirements, and prepare your infrastructure for XDC.

IN THIS GUIDE

Five ways to participate What your infrastructure contributes Plan the role before the server See all topics

On this page

A node runs the software that keeps a local view of the blockchain and communicates with other participants. Your operating role determines whether you serve application data, retain historical state, or take part in consensus.

Start with the role your service needs. A data-access node does not need to become a staked validator. Validator candidacy adds stake, identity, availability and operational responsibilities.

Node counts, reward examples and upgrade targets on the source page are not live guarantees. Published sources disagree on some figures; current software, contracts and maintainer guidance determine operational requirements.

Five ways to participate

The network portal describes Full, Archive, Core Validator, Protector and Observer roles. Other documentation also uses the broader term Standby. Confirm the role supported by your selected release before provisioning.

Data access

Full node

Independently verifies blockchain data and can serve application queries. No validator stake is required merely to run a data-access node; the portal does not assign node-operation rewards to this role.

Historical state

Archive node

Keeps historical state needed for older-state queries, analytics and specialized explorer workloads. Storage and synchronization requirements differ from a node serving only current state.

Consensus

Core Validator / Masternode

Proposes and confirms blocks under the consensus rules. Mainnet candidacy requires 10,000,000 XDC and the documented identity process. Maintain reliable infrastructure and monitor participation.

Standby support

Protector node

The network portal describes a 10,000,000 XDC standby role supporting validator redundancy. Its protector-to-validator ratios conflict, so use current operational guidance for selection and rewards.

Published role; verify current rules

Observation

Observer node

The portal describes a 10,000,000 XDC role observing consensus without producing blocks. Reward eligibility and transitions to other roles require confirmation against the current system.

Published role; verify current rules

What your infrastructure contributes

Independent verification

Full nodes check the ledger locally. Validators also perform consensus duties, so transaction verification and block production should not be treated as the same role.

Block production and confirmation

Active validators coordinate proposals and signatures. A short block interval is useful for applications, but inclusion and consensus finality are separate milestones.

Participation and governance

Understand the distinction between running infrastructure, becoming an eligible candidate and taking part in governance. Follow the documented process for each action.

Operational resilience

Reliable peers, monitored storage, protected keys and timely maintenance help the network keep progressing. Plan recovery before an outage occurs.

Participation incentives

Reward mechanisms are intended to support eligible network participation. Eligibility, timing and amounts depend on current rules and activity; operating a node is not a promise of returns.

Plan the role before the server

5 entries

Plan the role before the server
Item	Details
Full node	Validator stake: not required for data access. Plan compute, disk and network capacity for your actual RPC workload.
Archive node	Validator stake: not required for archival data access. Retaining historical state changes storage, synchronization and backup planning.
Core Validator	Published mainnet candidacy: 10,000,000 XDC plus identity requirements. Continuous operation and signing participation matter; staking alone does not prove active-validator selection.
Protector / Observer	The portal lists 10,000,000 XDC for each role. Confirm current eligibility, selection and uptime policy with the maintainers before committing infrastructure.
Server capacity	Use the Docker guide as a starting reference, then size for the selected client, full/archive mode, chain growth and the current release.

From a synchronized node to a candidate

1. Prepare and synchronize the node
Choose the correct network, deploy the supported client and verify that the node follows the chain. Keep your configuration and signing material backed up.
Explore resource
2. Open the official staking interface
Use master.xinfin.network and select Mainnet or Apothem deliberately. Confirm the connected wallet is using the same network.
Explore resource
3. Review the candidacy requirements
The documented mainnet path requires the stake, your node’s coinbase address and the identity information requested in the official form. Read the current form before submitting documents.
Explore resource
4. Check addresses and sign
Enter the correct node address, review the transaction in your wallet and confirm only when the details match your intent. The owner wallet and node identity serve different purposes.
Explore resource
5. Verify the application
Check the transaction and candidacy status after submission. Continue monitoring node health; successful submission is not a guarantee of active selection.
Explore resource

Understand rewards and published figures

The portal and reward documentation contain inconsistent quantities and timing descriptions. The values below explain what those sources publish; they are not a payout calculator, current network snapshot or guaranteed policy.

The source page says Protector and Observer payouts use an ecosystem reward wallet while full automation is planned. Its October 2026 target does not establish that activation has occurred. Check a dated release or governance announcement for the deployed state.

7 entries

Understand rewards and published figures
Item	Details
Validator set	Architecture documentation describes a maximum active set of 108. Check monitoring and the staking interface for current membership. Protocol description, not live count
Protector count	The portal’s role text says two per validator, while its illustration says four and lists 432. Do not use either as a verified current allocation. Conflicting source figures
Observer count	The source illustration describes the set as unlimited. This is a description of intended capacity, not a count of currently participating nodes. Source illustration
Locked XDC	The portal illustration displays 3,711 million XDC without a measurement timestamp. Use an explorer or current network data for an up-to-date total. Undated illustration
Epoch rewards	The portal illustration states 6,000 XDC per epoch. The work-in-progress rewards document uses a different total and internally inconsistent monthly examples. No single figure is presented here as current entitlement. Needs authoritative reconciliation
Protector and Observer rewards	The portal describes shared Protector rewards and an Observer amount linked to them. Eligibility and the actual distribution mechanism must be checked against current policy; those descriptions do not establish fixed returns. Verify current policy
Timing	Documentation describes 900-block epochs. Elapsed time depends on block production; the portal’s roughly 50-minute statement conflicts with the reward document’s roughly 30-minute model. Use block-based epoch boundaries

Infrastructure operators and institutions

All 29 organizations below appear in the infrastructure-operator and institution section of the official masternode page, reviewed on 22 October 2026. This preserves that published directory; it does not independently verify current validator addresses, active-set membership or an endorsement.

Names follow the source listing. Destinations were opened during review and may resolve to a regional page or updated brand.

29 entries · First 24 shown

Official portal listing