XDC Network — Validator (Masternode) Tech Specs & Best Practices

XDC Network at a Glance

XDC Network is an enterprise-grade, EVM-compatible Layer 1 blockchain purpose-built for trade finance, cross-border payments, and real-world asset (RWA) tokenization. Founded by XinFin in 2017 and mainnet-live since June 2019, the network combines public transparency with private subnet capabilities, delivering near-instant finality, near-zero gas fees, and ISO 20022 compliance — making it one of the most business-ready blockchains in production today.

Key Milestones

Network at a Glance (as of early 2026)

1. Network Overview

2. Staking Requirements

3. Node Types Under XDC 2.0

Node selection order: The top 108 most voted candidates become active Core Validators. The next 432 are assigned as Protector Nodes (4 per Validator). Beyond that, the next 1,000 serve as Observer Nodes. Full Nodes and Archive Nodes have no cap and do not participate in consensus.

4. Hardware & Infrastructure Specs

Minimum Requirements

5. Uptime & Availability

6. Security Best Practices

Key Management

• Use a hardware wallet for the staking/owner wallet
• Keep Keystore file backed up offline in multiple secure locations
• Coinbase address (node identity) backup is critical — if lost, the masternode is unrecoverable
• For institutional setups, consider Fireblocks or similar MPC custody via WalletConnect v2

Infrastructure Security

• Harden the OS (disable root SSH, use key-based authentication, change the default SSH port)
• Keep Docker and node software on the latest stable version
• Run behind DDoS mitigation if possible
• Enable automatic security updates for the host OS
• Install fail2ban to protect against SSH brute-force attempts

Firewall & Port Configuration

For a Validator / Protector / Observer node (not serving public RPC traffic), only port 30303 should be open to the internet. All other non-essential ports must remain closed.

Port Reference:

Recommended UFW configuration for a Validator / Protector / Observer masternode:

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 30303                # P2P — required
sudo ufw allow <your_ssh_port>      # SSH — required, do NOT skip
sudo ufw enable

⚠️ Critical: Always allow your SSH port before enabling the firewall or rebooting. Otherwise you will lock yourself out of the server. If this happens, use your VPS provider's web console to regain access.

Additional hardening notes:

• On cloud providers (AWS, GCP, Azure, DigitalOcean), you must also configure provider-level Security Groups — host-level UFW alone isn't enough.
• If running a public RPC node, restrict ports 8989 / 8888 to specific IP allowlists — never leave them open to the world.
• Audit firewall rules periodically: sudo ufw status verbose.
• Block all other inbound ports by default; review any open ports against this table quarterly.

Operational Security

• Separate the masternode owner wallet from day-to-day operational wallets
• Use dedicated infrastructure — avoid sharing servers with other workloads
• Complete KYC with a valid, current corporate or individual identity document
• Maintain an incident response runbook for key compromise or node failure scenarios

7. Monitoring & Maintenance

8. Reward Economics (Indicative)

Reward Split by Node Tier

9. Deployment Quick-Start

Docker (recommended)

sudo su -c "bash <(wget -qO- https://raw.githubusercontent.com/XinFinOrg/XinFin-Node/master/setup/bootstrap.sh)" root

Follow the prompts to select mainnet, name your node, and generate or import your keys.

Testnet: Always test your setup on Apothem (apothem.network) before going live on mainnet.

Network Snapshots

Snapshots allow faster node synchronisation by downloading a pre-synced copy of the blockchain instead of syncing from genesis.

XDC Network Mainnet Snapshots:

Apothem Testnet Snapshots:

Applying a Snapshot

After downloading the snapshot, follow these steps to spin up your node. Run these commands from inside the XinFin-Node/mainnet/ directory (or testnet/ for Apothem):

# 1. Stop the running node (if already running)
bash docker-down.sh

# 2. Extract the snapshot — NOTE: use -xvf, not -xvzf
#    The xdcchain.tar is a POSIX tar archive, not gzipped
tar -xvf xdcchain.tar

# 3. Back up your existing chain data (safer than rm -rf)
mv xdcchain/XDC xdcchain/XDC_backup

# 4. Move the extracted snapshot into place
mv XDC xdcchain/XDC

# 5. Start the node back up
bash upgrade.sh

Important notes:

• Do not use tar -xvzf — the snapshot is a POSIX tar archive, not gzipped, and the z flag will throw an error.
• Keep the XDC_backup folder until you've confirmed the node is syncing correctly from the snapshot. Once verified, you can safely delete it to free disk space.
• Always verify your coinbase.txt and keystore/ files are intact in xdcchain/ after the swap. If missing, restore them from your backup.
• Monitor sync progress on stats.xinfin.network or xdcscan.io.

10. Compliance & Governance

• All validators must pass KYC (PDF format, uploaded on-chain). Refer to the KYC Document Format for requirements
• Entities with criminal records, anonymous identities, or intentions to fork are disqualified
• Validators participate in governance voting on protocol upgrades and XIPs (XDC Improvement Proposals)
• XDC 2.0 introduced a DAO structure with three chambers: Masternode Senate, Judiciary, and People's House
• Network is aligned with MiCA (EU) regulatory standards and ISO 20022 financial messaging compliance

11. Frequently Asked Questions (FAQs)

Q: How much XDC do I need to run a masternode?
You need a minimum of 10,000,000 XDC staked to become a masternode candidate. There is no upper limit. Each masternode you operate requires its own separate 10M XDC stake.

Q: Can I run more than one masternode?
Yes. You can run as many masternodes as you wish, but each one must independently meet the 10M XDC staking requirement, have its own dedicated server infrastructure, and complete separate KYC.

Q: What is the maximum number of masternodes allowed on the network?
The network supports a tiered structure: 108 Core Validator nodes, 432 Protector Nodes, and 1,000 Observer Nodes — totalling 1,540 staked node slots. The top 108 most voted candidates become active Validators, the next 432 serve as Protector Nodes, and the following 1,000 are Observer Nodes.

Q: What happens if my masternode goes offline?
If your node goes down, it may be marked as "slashed." You will miss block rewards for the epochs your node is offline, and prolonged downtime can affect your standing in the validator set. Ensure your infrastructure is always operational.

Q: What is the difference between a Validator and a Standby node?
Validator Masternodes (108 per epoch) actively validate transactions and produce blocks. Standby Masternodes are identical in setup but remain on standby — they are activated only when the number of active Validators drops below 108.

Q: How are rewards distributed?
Rewards are paid every epoch (900 blocks / ~30 minutes). The total block reward pool is 86,400,000 XDC plus transaction fees. Core Validators receive 10%, Protector Nodes receive 8%, and Observer Nodes receive 4%. Within each tier, rewards are proportional to blocks signed and validated.

Q: Can I withdraw my staked XDC at any time?
No. If you resign from your masternode, there is a mandatory 30-day lock-up period before you can retrieve your staked 10M XDC.

Q: What happens if I lose my Coinbase address or Keystore file?
Losing your Coinbase address means your masternode becomes inaccessible, and you will need to resign from the network. Losing your Keystore or private key means your funds are permanently inaccessible and you will not receive any further rewards. Always maintain secure offline backups of both.

Q: Is KYC mandatory? What format is required?
Yes, KYC is mandatory for all masternode operators. You must upload a notarised proof of identity (individual or corporate) and address in PDF format. This information is visible on the public network. Refer to the KYC Document Format for full requirements.

Q: Who is disqualified from running a masternode?
Entities or individuals that are anonymous, have a criminal record, intend to fork the XDC software, or do not comply with local laws are disqualified from becoming masternode operators.

Q: Can I set up on Windows or do I need Linux?
Both are supported. You can use the One-Click Installer for Windows and Linux, or deploy via Docker (recommended for production). Supported Linux distributions include Ubuntu 24.04+, CentOS, and RHEL.

Q: Does my server need a public IP?
Yes. Your masternode must face the internet directly with a dedicated static public IP address, without NAT.

Q: Can I use a cloud provider / VPS instead of dedicated hardware?
Yes. A VPS is optional but highly recommended if you don't have dedicated hardware that meets the specs. Ensure your provider can deliver the required CPU, RAM, disk, and network uptime.

Q: Which ports should I open on my firewall?
Only port 30303 (TCP + UDP) should be open to the internet for a Validator, Protector, or Observer node. Keep your SSH port open for admin access (22 or a custom port), but block everything else including RPC (8989) and WebSocket (8888). Only open 8989 / 8888 if you are explicitly running a public RPC node, and restrict them to specific IP allowlists.

Q: Can I test the setup before going live on mainnet?
Yes. XDC provides a testnet called Apothem (apothem.network) where you can test your entire masternode setup without using real XDC. This is strongly recommended before deploying to mainnet.

Q: Are there third-party masternode hosting services?
Yes, there are third-party service providers that can help with setup and hosting. However, XDC Network does not officially endorse any third-party services — always perform your own due diligence before engaging one.

Q: Can institutional operators use custody solutions like Fireblocks?
Yes. Institutions and enterprises can use Fireblocks via WalletConnect v2 to manage masternode staking with MPC-based custody, governance automation, and transaction policy controls.

Q: How do I check my masternode status?
You can monitor your node via stats.xinfin.network (mainnet), the masternode dashboard, or the XDCScan block explorer at xdcscan.io.

Q: What are the common setup errors?
The two most common issues are: (1) outdated Docker — install docker-compose version 1.21+; (2) port conflicts — if port 30303 is already in use, terminate the existing container and try again.

Q: How does XDC handle DDoS and spam attacks?
While XDC's transaction fees are extremely low, they are not zero. This means flooding the network requires a significant amount of XDC, making sustained spam attacks economically impractical. The network also employs on-chain forensic monitoring to detect and penalise malicious behaviour.

Q: What is an epoch?
An epoch is a cycle of 900 blocks on the XDC Network, completing in approximately 30 minutes. Validator selection, reward distribution, and governance actions are all structured around epochs.

Q: What are network snapshots and why should I use them?
Snapshots are pre-synced copies of the blockchain database. Instead of syncing your node from the genesis block (which can take days), downloading a snapshot lets you get up and running much faster. They are available for both mainnet and the Apothem testnet, in Full Node and Archive Node variants.

Q: How do I use a snapshot to speed up node setup?
Stop your node, extract the downloaded xdcchain.tar (using tar -xvf, not -xvzf), back up the existing xdcchain/XDC folder, move the extracted XDC folder into xdcchain/, and restart your node with bash upgrade.sh. It will resume syncing from the snapshot's block height instead of from zero. Always verify the snapshot source matches the official XDC download links before use.

Q: What is the difference between the Full Node and Archive Node snapshot?
The Full Node snapshot contains the current blockchain state needed for normal validation and transaction processing. The Archive Node snapshot includes the entire historical blockchain data from genesis — it's significantly larger and is only needed if you run analytics, block explorers, or dApps that require deep historical queries.

12. Key Ecosystem Partners & Integrations

Key References