Private XDC Network RPC Endpoints on a Dedicated Node

An XDC Network RPC node is a server running the XDPoSChain client that exposes APIs your app uses to read blockchain data and broadcast transactions. Because XDC is EVM-compatible, it serves standard Ethereum JSON-RPC, so dApps, wallets, indexers, and dashboards get stable, predictable access.

Yes. XDC is EVM-compatible, so you can deploy Solidity contracts and use familiar tools like MetaMask, Hardhat, and Truffle with minimal changes. The chain ID is 50 for mainnet and 51 for the Apothem testnet. Note that XDC addresses use an "xdc" prefix, but the chain works with standard Ethereum JSON-RPC.

XDC uses XDPoS, the XinFin Delegated Proof of Stake mechanism, which combines delegated proof of stake with a practical Byzantine Fault Tolerance layer. It runs up to 108 masternodes, with ~2 second blocks and near-instant finality, which is why a dedicated node stays close to chain tip during bursts.

Choose a standard full node when you mainly need the latest state, receipts, and recent logs. Choose an archive node when you need deep historical state for analytics, explorers, audits, or long-range backfills. A dedicated setup lets you pick the right tier without sharing limits.

Yes. XDC consensus runs on masternodes under XDPoS. We provision single-tenant bare metal with full root, KVM, and IPMI so you run the masternode with customer-held keys, while we keep the hardware stable and recoverable. You hold the keys, we run the metal.

Shared RPC endpoints throttle, vary in latency, and change policies without warning. A dedicated XDC node runs on single-tenant CPU, RAM, and NVMe, so your throughput and response times depend on your hardware headroom, not other tenants or shared quotas.

Most failures trace back to storage I/O saturation, CPU contention, or too many concurrent WebSocket sessions. Dedicated hardware removes noisy-neighbor contention, and local NVMe reduces read and write stalls. That is why teams move to a dedicated XDC RPC node when usage becomes production-grade.

No. Unlike shared RPC providers that bill per "compute unit" and throttle you past a quota, a dedicated node is a flat monthly price with unlimited requests and zero overages. One node equals all the throughput your hardware can serve. That makes budgeting predictable and removes the surprise bills that come with usage-based RPC pricing.

Shared RPC pools serve thousands of customers from pooled infrastructure, so you inherit rate limits, noisy-neighbor latency, and compute-unit billing. A RedSwitches node runs on single-tenant bare metal that is yours alone: reserved CPU, RAM, and NVMe, a dedicated 10/25 Gbps port, and a private endpoint you control. Performance tracks your hardware, not another tenant's traffic.

No. We provision from current snapshots so your node is live in hours rather than syncing from genesis for days. You can run it yourself with full root access, or choose our fully managed option where our engineers handle the sync, updates, and monitoring. Either way you receive a working private endpoint, not an empty server.

Yes. With 20+ Tier III locations across the US, EU, Asia, and Australia you can place your node in the same region as your users or a chain's sequencer to cut round-trip latency. Tell us your target region and we will recommend the closest facility. You can also run multi-region nodes for redundancy and split read and write endpoints.