# XDC Network: full content > XDC Network is an EVM-compatible Layer 1 blockchain focused on real-world assets, trade finance and payments. This site covers the network, developer and node-operator guides, multi-client engineering and post-quantum research from XDC Innovation Labs. Generated from the site source at build time. Canonical site: https://xdc.network/ · Index: https://xdc.network/llms.txt · Last updated: 2026-10-22 ## Key facts - What it is: An EVM-compatible Layer 1 blockchain focused on real-world assets, trade finance and payments - Founded: 2017 - Consensus: XDPoS 2.0 - Execution: EVM compatible (Solidity and Ethereum tooling) - Chain IDs: 50 (mainnet) · 51 (Apothem testnet) - Native token: XDC - Block interval: Approximately 2 seconds --- ## About XDC Network URL: https://xdc.network/about/ Last reviewed: 2026-10-22 A community-driven blockchain for global trade, payments and an inclusive digital economy. ### Built for global participation Founded in 2017, XDC Network brings together developers, early adopters and advocates around an open-source smart-contract platform for trade finance and payments. The network’s mission connects decentralized infrastructure with practical economic activity: cross-border transactions, trade operations and access to financial services. ### Three commitments - **Empowering global trade**: Smart contracts help businesses and individuals exchange value across borders with a transparent transaction record. - **Community engagement**: Local communities raise awareness, support adoption and help make blockchain applications relevant to different regions. - **Economic progress**: More effective infrastructure and financial transactions can support economic participation and global GDP growth. ### Advisory board - **Tadashi Yoshida**: A specialist in developing and managing startup support programs including accelerator and incubation program, Tadashi initiated and operated the Japan's first govt. managed accelerator program at SME support Japan. Having extended support to several new startups development in Japan, he has gained extensive experience in providing consultation and ideation of business ideas across the globe. ### Core team & ecosystem leadership Meet the professionals contributing technology, enterprise experience, regional development and education to the XDC ecosystem. 14 entries, including: Atul Khekade, Ritesh Kakkad, Sunil Senapati, Bill Sebell, André Casterman, Andrea Frosinini, Confidence Nyirenda, Rebecah Dausen, Sean White, Can Inac, Chen Shanlong, Arturo Cantera. See the page for the full list. ### Developer support - **XDC developer forum**: Ask technical questions and share implementation experience. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC developer community. (https://t.me/xinfintech) - **XDC documentation**: Network, smart-contract and node documentation. (https://docs.xdc.network/) - **CodeRun.AI**: AI-assisted technical support and development tools. (https://coderun.ai/) --- ## XDC Network FAQs URL: https://xdc.network/faqs/ Last reviewed: 2026-10-22 Understand the network, XDC utility, development, token standards and enterprise use cases. ### Frequently asked questions 14 entries, including: What is the XDC Network?, What makes the XDC Network different from other blockchains?, What are the main use cases of the XDC Network?, What is the XDC token used for?, Is the XDC Network EVM compatible?, How fast and cost-efficient is the XDC Network?, Who can build on the XDC Network?, How can developers get started with XDC Network?, Is the XDC Network suitable for enterprises and institutions?, What is ISO 20022?, What is a Masternode on the XDC Network?, Can I create my own token on the XDC Network?. See the page for the full list. ### Developer support - **XDC developer forum**: Ask technical questions and share implementation experience. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC developer community. (https://t.me/xinfintech) - **XDC documentation**: Network, smart-contract and node documentation. (https://docs.xdc.network/) - **CodeRun.AI**: AI-assisted technical support and development tools. (https://coderun.ai/) --- ## XDPoS 2.0 URL: https://xdc.network/xdpos/ Last reviewed: 2026-10-22 Delegated proof of stake, Byzantine fault tolerance and forensic accountability at the core of XDC Network. ### The journey to decentralized trust Blockchain systems allow participants to coordinate without depending on a single trusted intermediary. Bitcoin introduced a permissionless ledger; Ethereum added programmable smart contracts; proof-of-stake designs addressed resource use and scalability. XDPoS 2.0 builds on this history with a focus on accountability. Its research asks not only when a blockchain remains secure, but how cryptographic records can identify malicious behavior when safety is violated. ### The three pillars of XDPoS 2.0 - **Masternode election**: Delegated proof of stake selects nodes that create and approve blocks. The documented consensus design uses a 108-member committee. Eligibility, stake and operational requirements determine participation; consult current node documentation before deployment. - **HotStuff consensus**: Rounds, leaders and voting rules organize Byzantine fault-tolerant agreement. Confirmed-block finality depends on the protocol’s assumptions about faulty committee members and network behavior. - **Validator rewards**: A reward mechanism encourages nodes to contribute to network operation. XDC’s consensus overview describes approximately six-second finalization; block production and transaction finality are different measurements. ### Security with accountability The consensus paper integrates accountability and forensic analysis into the blockchain record. The objective is to retain evidence that can attribute misconduct to participating actors. Security claims have explicit assumptions. The HotStuff discussion describes safety when fewer than one-third of committee members are adversarial, alongside network conditions for progress. Operators should evaluate the current software, committee rules and monitoring requirements. ### Why this design matters - **Fast finalization**: Transactions reach a defined final state without relying solely on probabilistic confirmation depth. - **Byzantine fault tolerance**: The protocol coordinates agreement even when some participants behave incorrectly, within its fault threshold. - **Transparent accountability**: Cryptographic evidence supports forensic investigation of consensus behavior. - **Incentivized participation**: Rewards encourage validators to maintain the network and contribute reliable infrastructure. ### Read the consensus research Accountability and Forensics in Blockchains: XDC Consensus Engine DPoS 2.0 was published in August 2021 by Gerui Wang, Jerome Wang, Liam Lai and Fisher Yu of Hash Laboratories. - **Consensus research paper**: Protocol design, election, HotStuff, rewards and forensic monitoring. (https://arxiv.org/pdf/2108.01420.pdf) ### Developer support - **XDC developer forum**: Ask technical questions and share implementation experience. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC developer community. (https://t.me/xinfintech) - **XDC documentation**: Network, smart-contract and node documentation. (https://docs.xdc.network/) - **CodeRun.AI**: AI-assisted technical support and development tools. (https://coderun.ai/) --- ## XDC Subnet URL: https://xdc.network/xdc-subnet/ Last reviewed: 2026-10-22 Create a configurable network within the XDC ecosystem for private applications, specialized workloads and interoperable workflows. ### A network tailored to your organization - **Sovereignty**: Control the network configuration, participating validators, access rules and data governance. - **Scalability**: Create infrastructure for an application’s workload and adjust capacity as requirements evolve. - **Security**: Use the XDC 2.0 consensus design, monitoring and checkpoint verification within the deployment’s operating assumptions. - **Privacy**: Limit access to authorized participants and keep application transactions within a permissioned environment. ### Customer-owned architecture The subnet, relayer, checkpoint contract and wallet interfaces are part of a deployment controlled by the customer. - **Customer subnet**: An XDC 2.0 consensus engine runs with system settings, validators, governance and access rules chosen for the deployment. - **Relayer**: A relayer periodically submits critical consensus data from the subnet to XDC Mainnet. - **Mainnet checkpoint contract**: A smart contract verifies and records the submitted checkpoints, creating a public integrity reference. - **Wallet APIs**: Wallet interfaces connect users and applications to the subnet’s transaction workflows. - **Explorer and forensic monitoring**: Network tools provide transaction visibility and consensus monitoring within the deployment’s access policy. ### Interoperability & mainnet checkpointing A subnet can maintain its own validators and permissioned application state. A relayer sends consensus checkpoints to a smart contract on XDC Mainnet, producing a public record for integrity checks without publishing the underlying private transactions. XDC Zero handles communication between a subnet and XDC Mainnet. Endpoint contracts send and receive messages, a relayer transports the payload, and an oracle provides block-header data for validation. Applications can build data exchange and asset-transfer workflows on these components. Checkpointing and cross-chain execution solve different problems. Each deployment must define its verification rules, operator responsibilities and failure handling. Proposed XIM research extends this model toward heterogeneous ledgers and authenticated financial gateways; it is not a production service. ### Build for your use case - **Private blockchain networks**: Create an application network with confidential records, defined membership and organization-specific rules. - **Cross-chain transactions**: Coordinate messages and asset-transfer workflows between networks using an explicitly chosen verification policy. - **Supply-chain security**: Track the movement and provenance of goods and materials with a shared transaction record. - **Decentralized applications**: Deploy smart-contract applications on infrastructure configured for their security, access and scaling requirements. ### Operational advantages - **Cost control**: Configure infrastructure and transaction models around the application’s needs; evaluate total operating and mainnet checkpoint costs. - **Speed and capacity**: Isolate application workloads and tune deployment resources as usage grows. - **Security operations**: Combine consensus controls with monitoring, operational procedures and checkpoint validation. - **Guarded privacy**: Define who can access network data and who can submit or validate transactions. ### Validator & partner network The XDC Subnet overview highlights SBI VC Japan, Deutsche Telekom, Contour and Zanzibar NBN in the wider validator and partner ecosystem. A subnet’s own operators and security policies remain deployment-specific. - **SBI VC Japan** (https://www.sbivc.co.jp/) - **Deutsche Telekom** (https://www.telekom.com/) - **Contour** (https://www.contour.network/) - **Zanzibar NBN** ### Guides, videos & research - **Gasless subnet whitepaper**: September 2024 technical proposal by Mohuya Chakraborty and Atul Khekade. - **Subnet architecture**: Components and design in the official network documentation. (https://docs.xdc.network/subnet/overview/) - **XDC Zero**: Endpoint, relayer and oracle messaging components. (https://docs.xdc.network/subnet/components/xdc_zero/) - **Docker installation guide**: Prepare Docker, generate configuration, deploy nodes, create a checkpoint contract and start subnet services. (https://www.xdc.dev/vinn_9686/xdc-subnet-installation-guide-building-a-secure-and-scalable-network-4hb3) - **Set up your own subnet**: Video walkthrough of subnet setup. (https://www.youtube.com/embed/VwfI4VTMUnY?si=VpFlH7anidYYHX-A) - **Introducing XDC Subnet**: Video introduction to the subnet model. (https://www.youtube.com/embed/53zTfZCRQ_k?si=UDWkI9DlXxbZulNX) ### Create your subnet Discuss the network configuration and integration requirements for your organization. - **Subnet assistance**: Contact the team about creating an XDC Subnet. (https://forms.gle/KQxw5DVbrMYrHv5N9) ### Developer support - **XDC developer forum**: Ask technical questions and share implementation experience. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC developer community. (https://t.me/xinfintech) - **XDC documentation**: Network, smart-contract and node documentation. (https://docs.xdc.network/) - **CodeRun.AI**: AI-assisted technical support and development tools. (https://coderun.ai/) --- ## Privacy-focused enterprise networks URL: https://xdc.network/privacy-network/ Last reviewed: 2026-10-22 Keep application transactions inside a network you control, with public checkpoints for integrity verification. ### A permissioned network built around your requirements XDC Subnet enables a customer-owned network with configurable validators, governance and access controls. Organizations can run private applications while retaining the ability to anchor consensus data to XDC Mainnet. The application’s private transaction records remain within its permissioned environment. The deployment determines who can participate, access data and operate infrastructure. ### Privacy, control, security & scale - **Privacy**: Limit access to authorized participants and keep application transactions within a permissioned environment. - **Sovereignty**: Control the network configuration, participating validators, access rules and data governance. - **Security**: Use the XDC 2.0 consensus design, monitoring and checkpoint verification within the deployment’s operating assumptions. - **Scalability**: Create infrastructure for an application’s workload and adjust capacity as requirements evolve. ### Owned by you, anchored to mainnet - **Customer subnet**: An XDC 2.0 consensus engine runs with system settings, validators, governance and access rules chosen for the deployment. - **Relayer**: A relayer periodically submits critical consensus data from the subnet to XDC Mainnet. - **Mainnet checkpoint contract**: A smart contract verifies and records the submitted checkpoints, creating a public integrity reference. - **Wallet APIs**: Wallet interfaces connect users and applications to the subnet’s transaction workflows. - **Explorer and forensic monitoring**: Network tools provide transaction visibility and consensus monitoring within the deployment’s access policy. ### Private transactions, public integrity A subnet can maintain its own validators and permissioned application state. A relayer sends consensus checkpoints to a smart contract on XDC Mainnet, producing a public record for integrity checks without publishing the underlying private transactions. XDC Zero handles communication between a subnet and XDC Mainnet. Endpoint contracts send and receive messages, a relayer transports the payload, and an oracle provides block-header data for validation. Applications can build data exchange and asset-transfer workflows on these components. Checkpointing and cross-chain execution solve different problems. Each deployment must define its verification rules, operator responsibilities and failure handling. Proposed XIM research extends this model toward heterogeneous ledgers and authenticated financial gateways; it is not a production service. ### For data-sensitive organizations - **Private blockchain networks**: Create an application network with confidential records, defined membership and organization-specific rules. - **Cross-chain transactions**: Coordinate messages and asset-transfer workflows between networks using an explicitly chosen verification policy. - **Supply-chain security**: Track the movement and provenance of goods and materials with a shared transaction record. - **Decentralized applications**: Deploy smart-contract applications on infrastructure configured for their security, access and scaling requirements. ### Operational flexibility A dedicated subnet can support application-specific capacity, access policies and cost models. Privacy and security depend on configuration, authorized participants and operational controls. ### Guides & documentation - **Subnet setup guides**: Docker setup and introductory videos. - **Gasless subnet whitepaper**: September 2024 technical proposal by Mohuya Chakraborty and Atul Khekade. - **Subnet architecture**: Components and design in the official network documentation. (https://docs.xdc.network/subnet/overview/) - **XDC Zero**: Endpoint, relayer and oracle messaging components. (https://docs.xdc.network/subnet/components/xdc_zero/) - **XDC developer forum**: Ask technical questions and share implementation experience. (https://www.xdc.dev/) ### Questions about privacy networks **Are subnet transactions private?** Subnets can restrict access to authorized users. Application transactions remain in the permissioned environment according to the deployment’s access rules. **What is published to XDC Mainnet?** The relayer submits consensus checkpoint data to a mainnet contract. This creates an integrity reference without publishing the underlying private transactions. **Who owns and operates the network?** The customer controls the subnet, relayer, checkpoint contract and wallet APIs, and defines validators, governance and access rules. **How is the network secured?** The subnet uses the XDC 2.0 consensus engine, while a mainnet smart contract verifies and records checkpoints. Operational security remains a deployment responsibility. **Can it connect to other networks?** XDC Zero supports communication between a subnet and XDC Mainnet. XIM research proposes connections to additional blockchains, institutional ledgers and financial gateways. **How do I get started?** Follow the Docker setup guide and video tutorials, or contact the team to discuss a subnet deployment. ### Create your privacy network - **Discuss your requirements**: Get assistance with an XDC Subnet deployment. (https://forms.gle/KQxw5DVbrMYrHv5N9) - **Developer Telegram**: Join the XDC developer community. (https://t.me/xinfintech) --- ## XDC Interledger Messaging Protocol URL: https://xdc.network/interledger/ Last reviewed: 2026-10-22 Authenticated messaging and settlement across independently governed ledgers, institutional networks and financial rails. > Research preview · September 2026. XIM is not yet ready for production use. ### Interoperability as authenticated message exchange XIM proposes a common messaging layer without requiring connected networks to adopt the same consensus system. It defines canonical messages, deterministic identifiers, cryptographic commitments, replay protection, verification policies, execution semantics and acknowledgements. Each source–destination connection, or lane, declares a verification policy suited to its value, finality, privacy and trust requirements. XDC Mainnet may serve as a coordination, checkpoint or settlement domain where a workflow requires it; every message does not have to pass through XDC. ### Six protocol building blocks - **Canonical messages**: A deterministic envelope separates the interledger message from any source-chain transaction format. Domain-separated message identifiers support replay resistance. - **Lane-scoped verification**: A lane can select native proofs, light clients, zero-knowledge proofs, threshold attestations, trusted-execution-environment attestations or a hybrid policy. - **Commitment-oriented state**: Message hashes, sparse Merkle roots and append-only transition logs support auditability without replicating every foreign chain’s state. - **Universal Asset Identity**: UAID distinguishes an economic asset from its contract addresses and representations on different networks, retaining the distinction between identity and representation risk. - **Policy-aware routing**: Eligible routes depend on jurisdiction, asset support, privacy, verification strength, value limits, liquidity, deadlines and finality. - **Independent risk controls**: Lane-specific monitors can rate-limit, pause or downgrade a route without globally stopping unrelated lanes. ### Separate responsibilities, explicit trust - **Observers**: Detect finalized events on a source network and construct candidate XIM messages. - **Gateways**: Translate authenticated financial instructions and APIs into the protocol’s message semantics. - **Verifiers**: Evaluate the supplied evidence against the verification policy of the lane. - **Routers**: Select eligible direct or multihop settlement paths. - **Executors**: Submit verified actions to the destination and record execution receipts. - **Risk monitors**: Detect anomalies and apply circuit breakers to affected lanes. ### Public-chain settlement workflow An adapter observes source finality, builds proof evidence, commits a message, verifies it on XDC, executes the destination settlement and emits an acknowledgement. ### Institutional ledger workflow An authorized gateway commits to a private institutional event. Selective disclosure supports verification without publicly replicating confidential transaction data. ### Financial instruction workflow A gateway authenticates a financial instruction, creates a settlement intent, verifies HSM-backed evidence, executes destination settlement and returns reconciliation output. ### Trust that can be assessed and contained XIM does not eliminate trust. The proposal makes trust assumptions explicit for each lane so that verification, operational responsibility and risk can be assessed separately. - **Authenticity**: A destination accepts a message only when evidence satisfies the lane’s policy. - **Replay resistance**: A consumed message identifier cannot execute a second time within the destination security domain. - **Lane isolation**: An anomalous or compromised lane can be paused without stopping unrelated routes. - **Auditability**: Authenticated commitments and events allow state transitions to be reconstructed. ### Where XIM could apply Public blockchains, permissioned ledgers, institutional networks, stablecoins, tokenized assets, trade finance and ISO 20022-compatible payment workflows. ### A proposed twelve-week implementation The roadmap describes a staged minimum viable implementation. Public test vectors, reproducible benchmarks, adversarial testing, independent audits and formal analysis are required before production use. - **Weeks 1–2 · Protocol freeze**: Finalize the v0.1 schema, NetworkID and UAID formats, state machine, lane policies and test vectors. - **Weeks 2–5 · XDC contracts**: Implement MessageRegistry, VerifierRegistry, RiskManager, replay protection and the event model. - **Weeks 3–7 · First adapters**: Develop XDC and Ethereum observers and executors, deterministic encoding and a threshold-attestation bootstrap. - **Weeks 5–8 · Commitments & SDK**: Build the sparse-Merkle-tree library, batch roots, TypeScript and Go SDKs, and REST/gRPC APIs. - **Weeks 7–10 · Security & operations**: Add rate limits, lane pause, key rotation, monitoring and chaos/failure tests. - **Weeks 10–12 · Pilot**: Demonstrate Ethereum–XDC testnet messages and asset transfers, then publish benchmarks. ### Questions about XIM **What is XIM?** A proposed verification-agnostic protocol for messaging and settlement between ledgers, institutional networks and financial rails. **Must every network share one consensus system?** No. Each network retains its own governance and consensus; XIM defines authenticated exchange between those trust domains. **How are messages verified?** Each lane selects an explicit evidence policy, including proofs, light clients, attestations or hybrid verification. **What happens if a lane is compromised?** Risk monitors can limit, pause or downgrade the affected lane while unrelated routes continue. **How does XIM relate to XDC Zero and Subnet?** XDC Zero supports subnet–mainnet communication. XIM research broadens the model to heterogeneous chains, institutional ledgers and financial gateways. **Is XIM ready for production?** No. It is a research preview, with implementation, testing, benchmarks, audits and formal analysis still part of the path to production. ### Read the XIM paper Research by Atul Khekade, Ritesh Kakkad, Wanwiset Peerapatanapokin and Behnam Mohammadkhani, XDC Network Research & Engineering, September 2026. - **XIM research paper**: Protocol design and implementation roadmap. (https://arxiv.org/abs/2609.39310) - **XIM protocol site**: Companion presentation of the protocol research. (https://xim-landing-page.vercel.app/) ### Developer support - **XDC developer forum**: Ask technical questions and share implementation experience. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC developer community. (https://t.me/xinfintech) - **XDC documentation**: Network, smart-contract and node documentation. (https://docs.xdc.network/) - **CodeRun.AI**: AI-assisted technical support and development tools. (https://coderun.ai/) --- ## Run an XDC node URL: https://xdc.network/setup-masternode/ Last reviewed: 2026-10-22 Choose a node role, understand participation requirements, and prepare your infrastructure for XDC. 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. - **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. (https://docs.xdc.network/xdcchain/developers/node_operators/node_architecture/) - **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. (https://docs.xdc.network/learn/xdc-architecture/) - **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. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **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. - **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. ### 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. (https://docs.xdc.network/xdcchain/developers/node_operators/node_architecture/) - **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. (https://docs.xdc.network/learn/xdc-architecture/) - **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. (https://docs.xdc.network/xdcchain/governance/overview/) - **Operational resilience**: Reliable peers, monitored storage, protected keys and timely maintenance help the network keep progressing. Plan recovery before an outage occurs. (https://docs.xdc.network/xdcchain/developers/node_operators/node_architecture/) - **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. (https://docs.xdc.network/xdcchain/rewards/) ### Plan the role before the server - **Full node**: Validator stake: not required for data access. Plan compute, disk and network capacity for your actual RPC workload. (https://docs.xdc.network/xdcchain/developers/node_operators/node_architecture/) - **Archive node**: Validator stake: not required for archival data access. Retaining historical state changes storage, synchronization and backup planning. (https://docs.xdc.network/learn/xdc-architecture/) - **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. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **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. - **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. (https://master.xinfin.network/) - **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. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/#how-to-stake-xdc-on-a-masternodestandby-node) - **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. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **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. (https://master.xinfin.network/) ### 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. - **Validator set**: Architecture documentation describes a maximum active set of 108. Check monitoring and the staking interface for current membership. (https://docs.xdc.network/learn/xdc-architecture/) - **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. - **Observer count**: The source illustration describes the set as unlimited. This is a description of intended capacity, not a count of currently participating nodes. - **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. - **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. (https://docs.xdc.network/xdcchain/rewards/) - **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. - **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. (https://docs.xdc.network/xdcchain/rewards/) ### 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, including: SBI VC Japan, Cumberland, Deutsche Telekom, GSR Markets, HashKey Cloud, Republic, UOB Venture Management, Animoca Brands, Clearpool, RedStone, stakeFi, BCW Group. See the page for the full list. ### Using a third-party operator You can assess a managed service if you do not want to maintain the infrastructure yourself. Decide who controls the node identity, owner wallet, backups and administrative access before choosing a service. The network portal does not endorse third-party masternode services. Compare responsibilities, fees, recovery procedures, monitoring and termination terms directly with the provider. A place in an ecosystem directory is not a security assessment. - **Review the official operator guidance** ### Setup and operating guides - **Docker deployment**: Hardware planning, configuration, secure operation, troubleshooting and the original video tutorials. - **Full operator documentation**: Candidacy, bootstrap, Docker and snapshot procedures in the maintained documentation. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **Release and configuration reference**: Inspect the official node repository for current tooling and parameter changes before installation or an upgrade. (https://github.com/XinFinOrg/XinFin-Node) - **Slashing and recovery**: Understand how non-participation affects block-production eligibility and rewards, and how participation can resume. (https://docs.xdc.network/xdcchain/developers/node_operators/slashing/) ### Masternode questions, answered 15 entries, including: How do I set up a masternode?, What risks come with operating a masternode?, Can I withdraw earned rewards?, What does a masternode contribute?, Can I operate more than one masternode?, How do the coinbase and owner addresses differ?, When are rewards distributed?, How long is an epoch?, What throughput does XDC support?, Can I practice on a test network?, What should I back up for the coinbase identity?, What if I lose the node’s coinbase identity?. See the page for the full list. ### Get help with your node - **Node operator documentation**: Read the installation, staking, snapshot and operating instructions maintained in the XDC documentation. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **XDC developer forum**: Describe a reproducible problem, explain your environment and share redacted logs with other operators. (https://www.xdc.dev/) - **Developer community on Telegram**: Join the community channel linked from the official setup pages. Never share keystores, private keys or wallet recovery phrases. (https://t.me/xinfintech) - **AI technical support**: Explore the developer-assistance destination linked by the network portal. Check suggested changes against the current repository before applying them. (https://coderun.ai) --- ## Deploy XDC with Docker URL: https://xdc.network/docker-setup/ Last reviewed: 2026-10-22 Prepare a server, configure a node, verify synchronization and keep your deployment maintainable. Docker packages the node software and its runtime dependencies. You still operate the host, storage, keys, connectivity and upgrade process. Choose Mainnet or Apothem first. A synchronized data node and a registered masternode candidate are different milestones; installation does not stake funds or guarantee validator selection. > Published hardware guidance varies between the setup page, architecture guide and snapshot instructions. Treat the figures below as the Docker page’s planning baseline and confirm current release requirements before provisioning. ### A practical starting configuration - **Operating system**: The Docker page names CentOS, Red Hat Enterprise Linux and Ubuntu 20.04+. The current repository instructions focus on Ubuntu 20.04 or later. Choose a supported OS release and verify the installer’s compatibility. - **Processor**: Published Docker-page baseline: a 64-bit x86_64 processor with at least 6 cores. Match capacity to the selected client and workload. - **Memory**: Published Docker-page baseline: at least 32 GB RAM. Other XDC guides quote different figures for different setups; inspect the requirements for your actual mode. - **Storage**: Published Docker-page baseline: an 800 GB SSD database partition and at least 500 IOPS. Allow additional capacity for chain growth, restoration and backups; archive workloads need their own sizing. - **Container tools**: The current repository calls for Docker Engine 24.0+, Compose v2.20+, curl and jq. Older documentation still shows the docker-compose command; follow the current repository for supported tooling. (https://github.com/XinFinOrg/XinFin-Node) - **Connectivity**: Operator documentation calls for a publicly reachable server. Plan peer connectivity, administrative access and any application API exposure as separate network requirements. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) ### Deploy in a controlled sequence - **1. Choose the network and role**: Use Apothem to rehearse deployment and recovery. Decide whether the node serves data, retains archive state or participates as a validator/standby candidate. - **2. Prepare the host**: Update the operating system, establish SSH key access and preserve a provider-console recovery path. Confirm storage mounts and available disk before installing the node. (https://github.com/XinFinOrg/XinFin-Node) - **3. Review the official repository**: Read the current XinFinOrg/XinFin-Node instructions and release changes. Retrieve the supported deployment files rather than copying an unmaintained tutorial. (https://github.com/XinFinOrg/XinFin-Node) - **4. Install the container tooling**: Install the Docker and Compose versions expected by the current release. Check that the container engine starts correctly before configuring the blockchain service. (https://github.com/XinFinOrg/XinFin-Node) - **5. Create the network configuration**: Work in the selected mainnet or testnet directory. Create .env from env.example only for a new setup; preserve an existing configuration. Set the instance identity and contact fields as documented. (https://github.com/XinFinOrg/XinFin-Node) - **6. Review exposed services**: A validator-only node does not need a public application API. Review ENABLE_RPC, ENABLE_WS, permitted API namespaces, firewall rules and container port mappings before starting. (https://github.com/XinFinOrg/XinFin-Node) - **7. Start and observe**: The repository uses docker compose -f docker-compose.yml up -d from the selected network directory. Check the container, logs, peer connectivity and advancing block height; a running container alone does not prove synchronization. (https://github.com/XinFinOrg/XinFin-Node) - **8. Complete the appropriate next step**: For data access, validate the queries your application needs. For candidacy, retrieve the node address and follow the staking workflow only after the node is healthy. ### Keep configuration and key ownership clear - **Network separation**: Keep Mainnet and Apothem data, keys and configuration distinct. Before signing a staking action, compare the wallet network with the node network. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **Instance identity**: Preserve the existing INSTANCE_NAME during upgrades. Review configuration changes deliberately so monitoring and operational records continue to identify the correct node. (https://github.com/XinFinOrg/XinFin-Node) - **Node address**: The repository identifies xdcchain/coinbase.txt as the address reference. Back up the associated signing material; that public text file alone is not sufficient for recovery. (https://github.com/XinFinOrg/XinFin-Node) - **RPC and WebSocket access**: The repository defaults both interfaces to disabled. Enabling them is an explicit service decision; restrict access and expose only the methods your application needs. (https://github.com/XinFinOrg/XinFin-Node) - **Version-sensitive settings**: Current repository documentation combines API configuration and changes some older address/origin variables. Compare your existing .env with the release’s sample before restarting. (https://github.com/XinFinOrg/XinFin-Node) ### Know when the node is ready - **Check the process**: Confirm the expected container is running and inspect logs for repeated errors or restarts. Record the software version before troubleshooting. (https://github.com/XinFinOrg/XinFin-Node) - **Check progress and peers**: A healthy process must also find peers and advance its local chain. Compare its progress with a trusted network reference; do not treat an empty or stale dashboard as evidence of completion. (https://stats1.xinfin.network/) - **Check the intended service**: For an RPC service, validate representative reads against the correct chain. For a validator, confirm candidacy and participation separately from ordinary synchronization. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **Check the recovery plan**: Make sure the operator can recover configuration and keys without relying on a single server. A chain-data snapshot and a key backup solve different problems. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) ### Operate beyond the first start - **Snapshot restoration**: Choose a snapshot matching the network, client and full/archive mode. Stop the node before replacing chain data, retain a recoverable backup and follow the source’s current extraction instructions. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/#setup-xdc-masternodefull-nodestandby-node-using-snapshots) - **Planned upgrades**: Read release notes, preserve .env and keystores, and schedule the restart. After upgrading, check synchronization, connectivity and the role-specific service before declaring the node healthy. (https://github.com/XinFinOrg/XDPoSChain/releases) - **Capacity monitoring**: Watch disk headroom, memory, CPU, I/O and chain progress. An installation minimum is not a promise that the same server will suit future state growth or application load. - **Participation monitoring**: Validators should monitor signing and availability, not just container uptime. The slashing documentation describes how missed participation affects eligibility and recovery. (https://docs.xdc.network/xdcchain/developers/node_operators/slashing/) ### Resolve problems with useful evidence - **1. Collect the relevant facts**: Record the network, client version, operating system, Docker/Compose versions, local block progress, peer situation and the exact error. Note when the problem began and what changed. - **2. Narrow the failure**: Distinguish a host-access issue, a container failure, a synchronization problem and an application API failure. Check the corresponding logs and configuration before making another change. (https://github.com/XinFinOrg/XinFin-Node) - **3. Ask with a reproducible report**: Post the relevant environment details, error and actions already tried in the developer forum or repository issue tracker. Redact credentials, keys, recovery phrases and unrelated personal information. (https://www.xdc.dev/) - **4. Verify the fix**: After recovery, confirm the node advances, answers the intended requests and resumes any required participation. Record the change so another operator can reproduce it. (https://github.com/XinFinOrg/XinFin-Node) ### Watch the original setup walkthroughs These are the two videos embedded on the original Docker page. They demonstrate earlier setup workflows; use the current repository for command versions and security defaults. - **Mainnet bootstrap on AWS**: The original bootstrap walkthrough linked from the Docker setup page. (https://www.youtube-nocookie.com/embed/lWXfo42daSU?si=4RvEIps2950e5TDU) - **Mainnet Docker deployment on AWS**: The original Docker walkthrough linked from the Docker setup page. (https://www.youtube-nocookie.com/embed/gtV6PrSe5BA?si=jQ7QvvILY0-6MyEF) ### Continue with official operating resources - **Node operator documentation**: Read the installation, staking, snapshot and operating instructions maintained in the XDC documentation. (https://docs.xdc.network/xdcchain/developers/node_operators/masternode/) - **XDC developer forum**: Describe a reproducible problem, explain your environment and share redacted logs with other operators. (https://www.xdc.dev/) - **Developer community on Telegram**: Join the community channel linked from the official setup pages. Never share keystores, private keys or wallet recovery phrases. (https://t.me/xinfintech) - **AI technical support**: Explore the developer-assistance destination linked by the network portal. Check suggested changes against the current repository before applying them. (https://coderun.ai) --- ## Payment rails for AI agents URL: https://xdc.network/xdc-ai/ Last reviewed: 2026-10-22 Connect an agent, discover useful services and pay per call in USDC on XDC. XDC AI combines a service marketplace, agent integrations and x402 payment infrastructure. A compatible agent can discover an endpoint, receive its price and make an authorized USDC payment to request the result. Sponsored settlement uses a relayer to pay XDC gas. Wallet custody, funding and spending controls depend on the provider’s account configuration; review the wallet guide when setting up access. ### A practical starting point - **Open XDC AI**: Set up your provider account. (https://xdcai.tech/) - **Browse services**: Discover the current marketplace. (https://xdcai.tech/marketplace) - **Read the documentation**: Explore accounts, agents and APIs. (https://docs.xdcai.tech/) ### From account to paid API call - **01 · Set up your account**: Complete the provider’s login and wallet setup. Review the selected custody model and activate the controls you need. - **02 · Fund with USDC**: Use the receiving address shown by the provider and send supported USDC on XDC mainnet. - **03 · Connect an agent**: Use the MCP connector for supported chat environments or the CLI in a compatible terminal environment. - **04 · Discover, call and pay**: Find a service, review its price and make an authorized call. The payment-aware client handles the x402 request flow. ### Fund the work your agent does - **Deposit USDC**: Send supported native USDC on XDC to the account address. The relayer sponsors gas for the described payment flow. (https://docs.xdcai.tech/wallet/dashboard) - **Borrow against XDC**: The original XDC introduction announced collateral-backed funding as coming soon. The provider now documents lending and borrowing integrations; consult its current guide for supported account flows and availability. (https://docs.xdcai.tech/wallet/defi) ### Understand the wallet you enable The provider’s detailed wallet guides describe a custodial account flow and an optional Safe-based smart wallet with a USDC allowance per period. These are distinct configurations; a basic account is not automatically protected by an on-chain cap. - **Account dashboard**: Balances, funding addresses, transaction history and approved payees. (https://docs.xdcai.tech/wallet/dashboard) - **Spending limits**: Enable a period-based USDC allowance, move funds into the configured smart wallet and manage agent access. Per-transaction and native-XDC caps are described as roadmap items. (https://docs.xdcai.tech/wallet/spending-limits) ### What could your agent pay for? These examples describe possible services. Available actions, providers and prices are shown in the current marketplace. - **Send & receive**: USDC payouts and transfers within the provider’s supported authorization and recipient controls. - **Swap assets**: A service can expose supported token swaps with a quoted transaction flow. - **Book a hotel**: A travel service could expose room search, confirmation and payment. - **Book flights**: A booking integration could quote fares and accept payment when a ticket is purchased. - **Order food**: A commerce endpoint could handle an order and checkout. - **Build your own service**: Wrap an API in compatible x402 payment middleware and publish its capabilities. ### Connect through MCP The XDC AI MCP service exposes account, discovery and payment tools to compatible chat applications. Follow the provider’s instructions for your application’s current connector interface. - **MCP endpoint**: https://api.xdcai.tech/mcp (https://api.xdcai.tech/mcp) - **Claude.ai & ChatGPT guide**: Connector setup and supported tools. (https://docs.xdcai.tech/agents/claude-ai) - **Discover before paying**: Search the marketplace, inspect the service and call the selected URL. The provider’s connector handles payments through the paid-call tool rather than exposing unrestricted transfers. ### Use your terminal agent The xdcai CLI is documented for environments such as Claude Code, Cursor, Codex and a standard terminal. The original network introduction also names Hermes and Clawbot among agent environments. - **Authenticate**: npx xdcai login — authenticate with the provider. Accept its terms only after reviewing them. - **Get the funding address**: npx xdcai wallet address — retrieve the address for the configured account. - **Check the balance**: npx xdcai wallet balance — inspect available balances. - **Find a service**: npx xdcai marketplace list — inspect the catalog and select the relevant endpoint. - **Make an authorized call**: Use the documented call command with a selected service URL. The client processes supported 402 challenges and returns a structured result. - **CLI documentation**: Setup, commands, session management and output format. (https://docs.xdcai.tech/agents/cli) ### Built for agent workflows - **EIP-3009 authorizations**: The agent signs a supported USDC payment authorization; a relayer submits it and pays network gas. - **Structured output**: CLI commands return machine-readable JSON. Errors use structured output and a failure exit code. - **MCP & skill discovery**: MCP tools and a skill manifest let supported agents discover capabilities and follow the integration workflow. - **Open x402 payments**: The integration uses the x402 exact-evm payment scheme and compatible resource-server or facilitator components. - **Wallet adapters**: The original architecture describes adapters for HD, MPC, smart-account and custodian integrations. Available configurations are documented by the provider. - **On-chain records**: Payments settle as USDC transfers on XDC, with transaction hashes available for inspection. ### Turn an API into a paid service - **01 · Describe the service**: Publish what the endpoint does, its inputs and its price. - **02 · Add payment handling**: Use compatible middleware to return 402 requirements and verify paid requests. - **03 · Configure settlement**: Set the supported network, USDC payment configuration and provider payout address. - **04 · List and operate**: Submit the service to the marketplace and maintain its documentation, pricing and availability. - **List your API**: Provider onboarding. (https://xdcai.tech/providers) ### Human-approved DeFi actions The provider’s current documentation describes Fathom and PrimeFi supply, withdrawal, borrowing and repayment, plus supply and withdrawal through Morpho and Silo. An agent proposes a fund-moving action; the user reviews it in the browser, completes the required authentication and signs. A proposal alone does not move funds. - **DeFi documentation**: Supported protocols, collateral requirements and review/sign workflow. (https://docs.xdcai.tech/wallet/defi) ### Give your agent the setup guide The provider publishes a machine-readable setup document at xdcai.tech/setup.md. Review the current instructions and connect the account using the supported workflow. - **Open the setup guide**: Provider-maintained integration instructions. (https://xdcai.tech/setup.md) - **Choose an integration**: Agent connection options. (https://xdcai.tech/integrate) ### Before your first paid call **Do I need XDC for gas?** The described XDC AI payment flow sponsors gas through a relayer, so the payer funds supported USDC. Other blockchain actions may have different requirements. **Is every account non-custodial?** No universal custody claim applies here. The detailed provider guides distinguish a custodial account from an optional smart-wallet configuration. Review those guides for the flow you enable. **Are on-chain spending caps automatic?** The provider’s spending-limit guide describes them as opt-in. Configure the smart wallet and its allowance before relying on a cap. **Does connecting an agent authorize unlimited payments?** A connection should be configured around the calls and budget you authorize. Review the provider’s controls, service pricing and recipient rules. **Can an agent execute a DeFi proposal by itself?** The documented DeFi flow requires user review, authentication and a wallet signature. The agent’s proposal is not a completed transaction. **Are the travel and commerce examples all live services?** They are examples of possible x402 services. Consult the marketplace for currently listed providers and capabilities. ### Developer support - **Developer documentation**: Network integration, smart contracts and node operations. (https://docs.xdc.network/) - **XDC developer forum**: Ask questions, share a tutorial or connect with other builders. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC technical community. (https://t.me/xinfintech) - **CodeRun AI**: AI development tools and technical support for building on XDC. (https://coderun.ai/) --- ## Payments built into the request URL: https://xdc.network/what-is-x402/ Last reviewed: 2026-10-22 An open standard for paying for APIs, data and digital services over HTTP—with USDC settlement on XDC. x402 uses HTTP’s 402 Payment Required status to let a service request payment and a compatible client respond with a signed payment authorization. It was incubated by Coinbase and is developed as an open, blockchain-agnostic payment protocol. For developers, it enables per-request pricing. For agents, it provides a machine-readable way to discover a price, authorize a payment and retrieve a resource. ### One request. A clear payment flow. - **01 · Request a resource**: A client or agent calls an API endpoint using HTTP. - **02 · Receive payment requirements**: An unpaid request receives HTTP 402 with the service’s price and accepted payment details. - **03 · Authorize and retry**: The client checks its authorization and spending policy, signs the supported payment and retries the request. - **04 · Verify, settle and respond**: The service and its payment infrastructure verify the payment, settle it and return the requested resource according to the integration’s flow. ### Why build payments on XDC? - **USDC settlement**: Price APIs in a stablecoin and settle payments on XDC. - **Sponsored gas**: EIP-3009-based integrations let a relayer submit payment authorizations and pay the XDC gas. The user pays the quoted USDC amount. - **EVM tooling**: Build with familiar smart contracts, middleware and developer libraries. - **Verifiable records**: On-chain transaction references let applications record and inspect settlement. ### Infrastructure for agent commerce Agents can buy data, access compute, use services and transact with other agents. Metered access makes it possible to charge for a single useful request rather than requiring every interaction to begin with a subscription. - **Data & APIs**: Weather, market information, RPC access and specialist datasets. - **Compute & inference**: Metered processing, model inference and digital tools. - **Content access**: Per-request access to articles, research and other digital resources. - **Agent marketplaces**: Machine-readable service discovery and payment. - **Enterprise information**: Paid trade-finance, RWA and other institutional data endpoints. ### Built on familiar web infrastructure The ecosystem includes resource servers, clients, SDKs and payment facilitators. x402 composes with HTTP applications, MCP servers and agent frameworks; supported networks and payment schemes depend on the chosen implementation. - **Open x402 standard**: Protocol information and ecosystem resources. (https://x402.org/) - **Seller quickstart**: Current middleware and integration examples. (https://docs.x402.org/getting-started/quickstart-for-sellers) ### For API and service providers - **01 · Choose an integration**: Use compatible middleware or a facilitator for your framework and network. The original guide identifies Express, Next.js and FastAPI as examples. - **02 · Price your route**: Set the accepted USDC amount and payout details for each protected endpoint. - **03 · Return HTTP 402**: Provide machine-readable payment requirements when payment is missing. - **04 · Serve paid requests**: Verify and settle the supported payment before completing the paid resource flow. Publish your service details for discovery. ### For agent and client developers - **01 · Prepare a compatible wallet**: Fund the correct XDC wallet with USDC and review its custody model. - **02 · Set a spending policy**: Authorize a budget, recipients and service calls appropriate for your application. Enable available wallet controls before automation. - **03 · Discover an endpoint**: Use the service’s documentation or a marketplace to select a supported x402 resource. - **04 · Pay and inspect the result**: Let the compatible client handle the signed retry, then inspect the response and settlement record. ### A small paid endpoint A weather API could price GET /weather at 0.001 USDC per request. A client receives the payment requirement, authorizes the exact amount and retries. This is an illustration of the flow; use current SDK documentation for package names, middleware syntax and XDC configuration. - **Implement a seller**: Follow the maintained x402 quickstart. (https://docs.x402.org/getting-started/quickstart-for-sellers) ### Explore XDC AI XDC AI provides a marketplace, agent tooling and payment infrastructure built around x402. Chat and terminal integrations connect service discovery, USDC payments and transaction records. Wallet setup and limits depend on the selected provider flow. - **Discover services**: Browse independently operated APIs. (https://xdcai.tech/marketplace) - **Connect an agent**: Integration options for supported agent environments. (https://xdcai.tech/integrate) - **Provider documentation**: Account, wallet, middleware and payment documentation. (https://docs.xdcai.tech/) - **USDC and CCTP on XDC**: Circle’s announcement of native USDC and CCTP V2 on XDC. (https://www.circle.com/blog/now-available-usdc-cctp-v2-on-xdc-network) ### x402, explained **Is x402 an XDC-only protocol?** No. x402 is an open, blockchain-agnostic protocol. This guide focuses on integrations that settle supported USDC payments on XDC. **Does gasless mean there is no network fee?** No. In the described relayed flow, a relayer pays the XDC transaction fee. The paying client does not need to hold native XDC for that payment. **Does every wallet have an on-chain spending limit?** No. Limits depend on the wallet and configuration. XDC AI’s wallet documentation distinguishes a basic account flow from an opt-in smart-wallet cap. **Do I need a subscription to use x402?** The protocol supports payment per request. A particular service may still have its own pricing, access conditions or commercial terms. **Can I use it with a normal web API?** Yes. The integration uses HTTP request and response flows, with compatible payment-aware server and client components. ### Build with support - **Developer documentation**: Network integration, smart contracts and node operations. (https://docs.xdc.network/) - **XDC developer forum**: Ask questions, share a tutorial or connect with other builders. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC technical community. (https://t.me/xinfintech) - **CodeRun AI**: AI development tools and technical support for building on XDC. (https://coderun.ai/) --- ## Build, connect and explore URL: https://xdc.network/quick-tools-guide/ Last reviewed: 2026-10-22 Network endpoints, SDKs, explorers, wallets, contract tools and reference documents in one place. Use familiar EVM tooling to build on XDC, test on Apothem and connect an application to mainnet. Choose the correct network before deploying contracts or sending assets. ### Explore XDC Mainnet - **Mainnet portal**: Network access and tools. (https://xinfin.network/) - **Web Wallet**: Manage XDC with the web-wallet interface. (https://wallet.xinfin.network/) - **XDCScan**: Inspect transactions, blocks, addresses and contracts. (https://xdcscan.io/) - **XDC Explorer**: Alternative explorer entry point from the network navigation. (https://xdcscan.com/) - **Masternode governance**: Explore validator participation and staking governance. (https://master.xinfin.network/) - **Network status**: Open the network monitoring portal. (https://stats1.xinfin.network/) ### Test on Apothem Apothem is the development test network. Test XDC is used for testing and has no monetary value. - **Apothem portal**: Test network information and tools. (https://apothem.network/) - **Apothem faucet**: Request test XDC for contracts and applications. (https://faucet.apothem.network/) - **Apothem XDCScan**: Browse testnet transactions and contracts. (https://apothem.xdcscan.io/) - **Apothem explorer**: Additional testnet explorer. (https://explorer.apothem.network/) - **Validator resources**: Node software and deployment instructions. (https://github.com/XinFinOrg/XinFin-Node) ### Integrate your application XDC’s EVM compatibility supports familiar smart-contract and JSON-RPC development workflows. - **XDC Connect**: Connect applications to supported wallet providers. (https://www.npmjs.com/package/xdc-connect) - **XDC3**: JavaScript interface for XDC JSON-RPC operations. (https://www.npmjs.com/package/xdc3) - **XDPoSChain**: Core protocol source and release information. (https://github.com/XinFinOrg/XDPoSChain) - **XinFin-Node**: Docker-based node setup and configuration. (https://github.com/XinFinOrg/XinFin-Node) - **Exchange integration**: Network information and resources for exchange integrations. - **Network guide**: Legacy documentation covering the XDC networks. (https://howto.xinfin.org/general/networks/) ### Mainnet RPC endpoints Published HTTP and WebSocket endpoints for mainnet. Network availability and provider limits may change. - **https://rpc.xinfin.network**: Mainnet JSON-RPC (https://rpc.xinfin.network) - **https://erpc.xinfin.network**: Mainnet JSON-RPC (https://erpc.xinfin.network) - **https://arpc.xinfin.network**: Mainnet JSON-RPC (https://arpc.xinfin.network) - **https://earpc.xinfin.network**: Mainnet JSON-RPC (https://earpc.xinfin.network) - **https://xdc.public-rpc.com/**: Mainnet JSON-RPC (https://xdc.public-rpc.com/) - **wss://ws.xinfin.network**: Mainnet WebSocket - **wss://ews.xinfin.network**: Mainnet WebSocket - **wss://aws.xinfin.network**: Mainnet WebSocket - **wss://eaws.xinfin.network**: Mainnet WebSocket ### Apothem RPC endpoints Use testnet endpoints when developing and testing applications. - **https://rpc.apothem.network**: Apothem JSON-RPC (https://rpc.apothem.network) - **https://erpc.apothem.network**: Apothem JSON-RPC (https://erpc.apothem.network) - **https://arpc.apothem.network**: Apothem JSON-RPC (https://arpc.apothem.network) - **wss://ws.apothem.network**: Apothem WebSocket - **wss://ews.apothem.network**: Apothem WebSocket - **wss://aws.apothem.network**: Apothem WebSocket ### XDCScan Use a block explorer to inspect transactions, contract interactions, blocks, addresses and public network activity. Public APIs support application development. - **Mainnet explorer**: XDC mainnet. (https://xdcscan.io/) - **Testnet explorer**: Apothem testnet. (https://explorer.apothem.network/) ### XDCPay A browser wallet for storing, sending and receiving XDC and XRC20 assets. - **Download XDCPay**: Official Chrome Web Store listing linked by the network guide. (https://chromewebstore.google.com/detail/xdcpay/dgimfmajflciajjbhbkibdbfmpncbnmj) - **XDCPay documentation**: Wallet setup and usage guidance. (https://docs.xdc.org/xdc-tools/xdc-pay) ### Write your first contract XDC Remix is a browser-based Solidity IDE for writing, compiling, deploying and running smart contracts. - **Open XDC Remix**: Start a Solidity development session. (https://remix.xinfin.network/) - **Remix documentation**: Learn the browser-based development workflow. (https://docs.xdc.org/xdc-tools/xdc-remix) ### Get test XDC Request Apothem test tokens before exercising a contract or testing application transactions. - **Request test XDC**: Apothem faucet. (https://faucet.apothem.network/) - **Apothem Network**: Testnet portal. (https://www.apothem.network/) ### Security assessments & chain analysis Read the scope, date and findings of each assessment. A historical report covers the software and conditions reviewed at that time. - **SlowMist security audit**: Published XDPoSChain security assessment. - **CertiK assessment**: XDC project page and audit materials. (https://skynet.certik.com/projects/xdc-network?auditId=XDC+Network+-+Audit+1) - **Blockchain Intelligence Group**: Provider announcement of XDC investigation support. (https://blockchaingroup.io/announcements/blockchain-intelligence-group-to-support-xinfin-xdc-on-its-crypto-investigation-platform/) - **Elliptic**: Transaction monitoring, wallet screening and investigation services. (https://www.elliptic.co/) ### Legal reference documents These are historical, jurisdiction-specific opinions and risk assessments. Dates and document scope matter. - **BCAS · Liechtenstein**: Legal opinion dated 14 January 2021. (https://raw.githubusercontent.com/XinFinOrg/Official-XinFinOrg/master/docs/reports/legal-opinion-liechtenstein-bcas-xdc-14jan2021.pdf) - **Miller Thomson · Canada**: The Canadian opinion listed in the original network guide. - **McDermott Will & Emery · USA**: Regulatory risk memorandum dated 15 July 2022. - **Bergt & Partners · Europe**: XDC token opinion dated 11 March 2024. (https://raw.githubusercontent.com/XinFinOrg/Official-XinFinOrg/master/docs/reports/xdc-token-2024-03-11-europe.pdf) ### XDC index references The original network guide describes VNXDC as a Vinter single-asset benchmark tracking XDC in US dollars using a reference-rate methodology. Vinter’s documentation is now maintained under Kaiko; use the current methodology and index information for availability and scope. - **Kaiko / formerly Vinter indices**: Current index documentation; the linked directory covers active multi-asset indices. (https://docs.kaiko.com/formerly-vinter-indices/api/multi-assets-indexes/active-multi-assets) ### Need a hand? - **Developer documentation**: Network integration, smart contracts and node operations. (https://docs.xdc.network/) - **XDC developer forum**: Ask questions, share a tutorial or connect with other builders. (https://www.xdc.dev/) - **Developer Telegram**: Join the XDC technical community. (https://t.me/xinfintech) - **CodeRun AI**: AI development tools and technical support for building on XDC. (https://coderun.ai/) --- ## Let’s connect. URL: https://xdc.network/contact/ Last reviewed: 2026-10-22 Find the right channel for news, conversations, technical support and collaboration. The XDC community spans many backgrounds, skills and locations. Connect through the official channels below. ### Join the global community - **Telegram**: Follow XDC Network updates. (https://t.me/XDC_Network_Updates) - **X**: Follow XDC Network announcements and conversations. (https://x.com/XDCNetwork) - **LinkedIn**: Connect with the XDC Network professional community. (https://www.linkedin.com/company/xinfin/) - **Reddit**: Join community conversations. (https://www.reddit.com/r/xinfin/) - **GitHub**: Explore the code and contribute to XDC projects. (https://github.com/XinFinOrg) - **Medium**: Read articles and ecosystem stories. (https://medium.com/xdcnetwork) - **Developers Forum**: Share knowledge and get involved with developers. (https://xdc.dev) - **YouTube**: Watch XDC Network videos and subscribe for updates. (https://www.youtube.com/channel/UCQaL6FixEQ80RJC0B2egX6g) ### Need technical help? For development questions and integration support, visit the developer forum, documentation or Telegram community. - **Developer forum**: Ask questions, exchange ideas and collaborate with XDC developers. (https://www.xdc.dev/) - **Developer Telegram**: Get technical help from the XDC Network developer community. (https://t.me/xinfintech) - **XDC documentation**: Read network documentation, guides and technical references. (https://docs.xdc.network) - **AI developer support**: Explore AI-assisted tools and technical resources for building on XDC. (https://coderun.ai/) --- ## Web3, built around real use. URL: https://xdc.network/web3/ Last reviewed: 2026-10-22 Connect wallets, smart contracts and real-world workflows on XDC. Start with the fundamentals, then build toward assets, payments and useful applications. ### A shared network. A programmable experience. Web3 applications connect a user interface to wallets and contracts. XDC provides the execution and transaction layer; your application supplies the experience and business rules. - **Wallets authorize actions**: A wallet manages signing and lets a user approve an action. A connected wallet is not permission to spend. Make the network, recipient, amount and requested approval clear. - **Contracts enforce rules**: Use Solidity and EVM-compatible tools to define ownership, permissions and transfers. XDC documentation covers familiar Ethereum development tools; validate each dependency on your target network. - **Transactions create a record**: Use transaction hashes, receipts and contract events to connect the interface to network outcomes. Show pending, confirmed and failed states distinctly instead of assuming a submitted transaction succeeded. ### From digital ownership to real-world coordination. Choose the application around a concrete user need. These are design directions, not a claim that every implementation is provided by the network. - **Tokenized assets**: Connect asset records to programmable ownership and transfer workflows. Issuer operations, servicing and the rights represented by a token need their own design. - **Payments and commerce**: Build applications around native USDC on XDC and inspect Circle’s CCTP V2 integration path. Use the provider’s current documentation for asset and network support. - **Tokens and membership**: Explore XRC20 for fungible tokens and XRC721 for unique assets. Memberships and access experiences are application patterns; define issuance, permissions and holder rights explicitly. - **Digital trade**: Connect trade documents, counterparties and financing workflows. XDC’s trade-finance ecosystem is a starting point for understanding how applications link on-chain records with business processes. - **Enterprise networks**: Evaluate an XDC subnet when participation and governance need a separate network. Document what remains private and what checkpoints or other information reach the public chain. ### Start small. Make every state clear. Use this sequence to turn a concept into a testable application before working with mainnet assets. - **01 / Connect to Apothem**: Configure chain ID 51 in a supported wallet and use a documented testnet RPC. Keep testnet and mainnet configuration separate. - **02 / Fund a test wallet**: Request test tokens from the Apothem faucet. Testnet XDC is for development; it is not mainnet XDC. - **03 / Deploy one useful contract**: Begin with a small Solidity contract and an explicit permission model. Compile, test and inspect the deployed address before connecting your interface. - **04 / Complete the user journey**: Exercise rejected signatures, insufficient balances, failed calls and successful receipts. Give users a transaction link and a clear way to recover. ### The application is part of a wider system. Bring the right people and infrastructure into the project as the scope grows. - **Discover applications and providers**: Find wallets, infrastructure and independent applications in the preserved XDC ecosystem directory. Check each provider’s current support and operating terms. - **Contribute with other builders**: Use the developer community to discuss integration questions, share experiments and follow ecosystem work. Explore program requirements directly with their organizers. - **Understand network resilience**: Follow XDC’s multiple-client approach and post-quantum work as separate engineering efforts. Compatibility, validator readiness and cryptographic migration each require their own evidence. ### Common questions **Do I need a new programming language to build on XDC?** XDC supports Solidity and EVM-compatible development. Start from the XDC developer documentation, then validate libraries, RPC behavior and deployment configuration for the network you use. **What is the difference between XDC and USDC?** XDC is the network’s native token. USDC is a separate stablecoin issued by Circle with native support on XDC. Standard network transactions use XDC for gas; supported sponsored-payment services can abstract that fee from a payer. **Does a token automatically establish real-world ownership?** A token records contract state. The rights attached to an asset also depend on the issuer’s arrangements and applicable documentation. Design both the digital workflow and the underlying asset process. **Where do AI and quantum fit into Web3 on XDC?** AI applications can use XDC for payment and contract interactions. Post-quantum research studies future cryptographic protection. Neither means that XDC runs AI models or quantum computers inside its EVM. --- ## Intelligence meets settlement. URL: https://xdc.network/ai/ Last reviewed: 2026-10-22 Give software a practical way to pay for services. Explore AI agents, API commerce and x402 payment flows connected to XDC Network. ### Reason off-chain. Settle on XDC. An AI model can choose or generate an action. A wallet authorizes payment, and the network records the resulting transaction. These are different responsibilities. - **Models and services**: Inference, retrieval and document processing run in the application or service environment. A payment receipt does not establish that an AI response is correct. - **Authorization and controls**: Define which services an agent may call, what it may spend and when a person must approve an action. Custody and enforceable limits depend on the wallet and provider configuration. - **Payment and records**: XDC can record USDC transfers and contract state. Keep request identifiers and service receipts alongside transaction evidence so an application can reconcile payment with delivery. ### A service request with payment built in. x402 uses HTTP payment negotiation. The exact headers, supported networks and verification steps depend on the selected protocol version and facilitator. - **01 / Request the service**: An application or agent calls an API. If payment is required, the server returns HTTP 402 with its payment requirements. - **02 / Check and authorize**: The client checks the asset, network, recipient, price and authorization policy before signing the required payment payload. Approval rules belong in the application’s control layer. - **03 / Verify and settle**: The server and its selected facilitator validate the payment and perform settlement. A signature, a verification response and an on-chain settlement are distinct states. - **04 / Deliver and reconcile**: The service returns its result under its settlement policy. Match delivery to the payment record and handle retries or refunds according to the provider’s documented behavior. ### Build services that can transact. These examples describe application opportunities. They are not announcements of deployed products or guaranteed outcomes. - **Pay-per-request data**: An agent can purchase a specific data response instead of maintaining an open-ended subscription. Show the quote and source before authorizing the request. - **Trade-document services**: A workflow could pay an API to classify or extract information from trade documents. Keep sensitive documents off the public ledger and require human review for consequential decisions. - **Paid inference and tools**: Offer a model endpoint or specialist tool through a paid API. The provider delivers the compute; XDC supplies the payment record for the chosen integration. - **Agent-assisted operations**: An assistant can read network data, prepare reports and propose actions. Keep write permissions and spending authority separate from read-only analysis. ### For service builders. For agent builders. Start with one integration and a small test scope. A marketplace listing, a payment protocol and a blockchain are separate parts of the system. - **Offer a paid API**: Document the request, response, price and service terms. Integrate the chosen x402 version, verify settlement behavior and test retries before offering access. - **Connect an agent**: Choose the wallet model and supported network. Configure recipient and spending policies, then verify how to pause or revoke authority in that implementation. - **Connect the wider application**: Combine payment with your existing backend, user experience and event handling. Use the XDC developer hub for the underlying network configuration. ### Common questions **Does XDC execute AI models on-chain?** The application patterns described here use off-chain AI services. XDC handles transactions and contract execution. This guide does not claim a protocol-level inference engine or decentralized GPU service. **Is x402 only for AI agents?** No. An ordinary application or HTTP client can use a compatible x402 flow. Agents are one potential client of a paid API. **Does gasless mean the network has no fees?** No. In a supported sponsored flow, a facilitator or relayer pays the network fee. The payer experience and sponsorship conditions depend on that service; ordinary XDC transactions still require gas. **Can I assume every integration has the same custody and spending limits?** No. Provider pages describe different wallet and control configurations. Verify key ownership, supported limit enforcement, revocation and protocol version for the actual integration. **Does settlement prove that a service delivered the right answer?** No. Settlement proves the payment outcome, not the correctness or quality of a response. Applications need their own service checks, receipts and dispute process. --- ## Quantum readiness, layer by layer. URL: https://xdc.network/quantum/ Last reviewed: 2026-10-22 Explore the cryptography behind wallets, consensus and network services—and the evidence needed to move from an experiment to an XDC upgrade. ### One algorithm change does not protect every layer. Post-quantum preparation needs to follow the full path from user authorization to validator agreement and operational infrastructure. - **Wallets and transaction signatures**: A transaction-signature migration affects address handling, signing software, custody systems and recovery. Protecting consensus signatures alone does not automatically protect user accounts. - **Consensus and client compatibility**: The public Falcon experiment concerns consensus block and quorum-certificate signatures. A production change would also need interoperable behavior across the clients participating in consensus. - **Infrastructure and confidential data**: Transport security and key establishment have a different job from transaction signing. Inventory service connections, operational keys and long-lived confidential information separately. ### A longer view for trade documents. XDC Innovation Labs has published a proposed post-quantum signing design for long-lived trade records. The June 2026 specification remains a draft, subject to review and change. - **Two signatures over one payload**: The draft proposes ML-DSA and Falcon signatures over the same canonical document payload. Its verification rule requires both signatures to pass; it does not fall back to a single signature. - **Document protection has a defined scope**: The proposal focuses on records such as bills of lading and letters of credit. It does not establish the truth of a document, ownership of physical goods, certification or a deployed XDC capability. ### Make progress inspectable. Use evidence-based milestones to assess readiness. This is an evaluation framework, not an announced XDC activation schedule. - **Reproduce the experiment**: Inspect the source branch and build assumptions. Repeat correctness and performance measurements with recorded hardware, parameters and test conditions. - **Review the implementation**: Evaluate key generation, signature validation, encoding, failure handling and implementation security. Algorithm standardization does not certify a particular integration. - **Validate the network transition**: Test mixed-version behavior, client compatibility, wallet changes and recovery procedures in a controlled environment. A local benchmark does not establish network-wide readiness. - **Publish activation evidence**: Look for reviewed releases, an agreed upgrade process, operator instructions and observed adoption before describing protection as deployed. ### Useful work can start before activation. Different participants own different parts of a cryptographic transition. Keep experiments separate from production keys and assets. - **Researchers and client teams**: Contribute reproducible tests, verification code and implementation review. Compare compatibility and resource costs across client implementations. - **Wallet and application builders**: Map signature dependencies and upgrade assumptions. Plan how users would authorize migration and recover access without assuming a future format is already supported. - **Operators and enterprise teams**: Maintain a cryptographic inventory and follow reviewed release guidance. Track identity, transport and custody dependencies alongside consensus software. ### Common questions --- ## Post-quantum research: frequently asked questions URL: https://xdc.network/quantum/ Last reviewed: 2026-10-22 **Does post-quantum mean XDC runs on a quantum computer?** No. Post-quantum cryptography uses algorithms intended to resist quantum attacks while running on conventional computers. The XDC initiative concerns cryptographic protection and migration, not quantum computation inside the blockchain. **What is the difference between a signature and key establishment?** A digital signature helps verify authorization and message integrity. Key establishment lets parties derive a shared secret for secure communication. ML-KEM addresses key establishment; ML-DSA and SLH-DSA address signatures. These roles are not interchangeable. **Is there a confirmed activation date for a complete migration?** The reviewed public sources do not establish a confirmed mainnet activation date. Published planning timelines differ, so this guide presents evidence and readiness milestones instead of treating target dates as completed upgrades. **Is XDC mainnet quantum-safe today?** The reviewed public evidence does not establish that. XDC Innovation Labs describes an initiative and roadmap, while contributors have published a consensus proof of concept. Full migration needs implementation, security review and network adoption. **What does the Falcon proof of concept demonstrate?** It explores Falcon signatures for consensus block signing and quorum certificates. It supports technical research, but does not establish production security, complete wallet protection or a deployed network upgrade. **Which post-quantum standards are finalized?** NIST lists ML-KEM, ML-DSA and SLH-DSA as finalized standards. Its project page, updated August 2026, describes Falcon standardization as ongoing. Alignment with an algorithm is not NIST certification of XDC. **Why pursue multiple client implementations?** Independent implementations can reduce shared software failure risks and give operators more choice. Actual network resilience also depends on tested compatibility, validator adoption and consensus thresholds—not the number of client names alone. **How should operators interpret client status?** Treat the client list as Labs-reported development information. Check current releases, sync behaviour, consensus compatibility and validator support separately. The source includes inconsistent readiness labels, so verify suitability before changing production infrastructure. --- ## XDPoS on a modern go-ethereum base, measured URL: https://xdc.network/blog/modern-geth-rebaseline/ Last reviewed: 2026-06-20 By XDC Innovation Labs. Published 2026-03-01, updated 2026-06-20. XDC Network now runs **four independent execution clients across three languages** — go-ethereum (GP5) and Erigon in Go, Nethermind in C#/.NET, and Reth in Rust — all syncing mainnet. This post summarizes the engineering case for re-platforming the XDPoS engine onto a modern go-ethereum base, with the figures measured in production. ## What changed The XDPoS consensus engine was re-based onto pristine **go-ethereum v1.17.3**, inheriting a decade of upstream engineering — path-based state (PBSS), Pebble, freezer/ancients, snap sync, and the modern wire protocol — **without touching consensus**. The result is bit-exact consensus parity with the canonical chain. ## The measured result The headline is disk and CPU footprint. On XDC mainnet production nodes: | Metric | Legacy full node | Modern (geth v1.17.3) | Delta | |---|---|---|---| | Disk on mainnet | ~919 GB | ~303 GB | ~3× smaller | | CPU at idle head | baseline | ~40× lighter | — | | Consensus | XDPoS | XDPoS (bit-exact) | unchanged | These are measurements from the multi-client fleet, not projections. ## Why client diversity matters XDC is the first XDPoS chain with full client diversity. Because four independent implementations sync the same chain, **no single implementation can halt the network** — a resilience property that the comparison and architecture pages document in detail. This is a sample post created to demonstrate the blog's structure (TL;DR, claim→evidence, a data table, and an FAQ block) — all of which double as Generative Engine Optimization signals. Every figure above is already published on the XDC Innovation Labs architecture and migration pages. ### Source FAQ **Does the modern client change consensus?** No. XDPoS is layered additively onto go-ethereum v1.17.3; consensus is bit-exact with the canonical chain. **How much smaller is the modern node on disk?** A modern mainnet node measures about 303 GB versus roughly 919 GB for a legacy full node — about 3× smaller. --- ## About XDC Innovation Labs URL: https://xdc.network/labs/about/ Last reviewed: 2026-10-22 The Labs source describes its contributor role, engineering priorities and post-quantum research. Milestones and readiness remain publisher reports. > Preserved XDC Innovation Labs reference content from the linked repository snapshot. Dates, measurements, rollout targets and availability are source-reported; consult current maintainer guidance before implementation. About XDC Innovation Labs Building the resilient, quantum-safe future of trade finance. XDC Innovation Labs builds core infrastructure and the post-quantum initiative for the **XDC Network** ecosystem, hardening the chain that moves real-world value and **measuring the results in production**. Our mission Built on & aligned with → 4 clients 3 languages live on XDC mainnet, full client diversity geth v1.17.3 Pristine re-baseline · bit-exact consensus parity XDSS-PQ Post-quantum standard initiative · ahead of EU PQC ~103.3M Mainnet block synced · measured in production Our mission ### Make XDC the most resilient and quantum-safe chain for real-world finance. XDC settles trade-finance instruments: documents and value that must stay verifiable for 20 to 30 years. That long horizon turns two slow-moving risks into existential ones. We work on both, on one network, ahead of the regulation and ahead of the threat. #### Infrastructure resilience Multi-client diversity on a modern go-ethereum foundation, so implementation diversity can reduce shared software risk, subject to validator distribution and consensus thresholds. - 4 clients across 3 languages live on XDC mainnet, full client diversity (achieved). - XDPoS re-based onto pristine go-ethereum v1.17.3, inheriting modern state, sync and wire-protocol work. - Bit-exact consensus parity: identical state roots, receipts and block hashes against the canonical chain. #### Post-quantum security The XDC PQ Initiative and the XDSS-PQ standard, mapping and migrating XDC's quantum-exposed surface, prioritised by what cannot be re-signed later. - An initiative and roadmap built on NIST-selected algorithms, not a claim that XDC is fully quantum-proof today. - Long-lived trade documents first, because their 20-30 year validity makes harvest-now / decrypt-later a present risk. - Targeted ahead of the EU PQC (2030), CNSA 2.0 and NIST deadlines. ● Our ethos is simple: measured in production, not promised on a slide. The infrastructure figures on this site (disk, RPC, CPU and parity) are live readings from XDC mainnet nodes; the quantum work is framed honestly as an initiative and a roadmap. ### Core infrastructure & the PQ initiative for the XDC ecosystem. XDC Innovation Labs builds **core node infrastructure** and leads the **post-quantum initiative** for the **XDC Network**, the enterprise-grade, EVM-compatible Layer-1 originally launched by **XinFin** for global trade finance. We are **one contributor within a broader ecosystem**, not the only entity building on XDC. The network is governed and supported by many independent teams, validators and community contributors. Our focus is deliberately narrow: multi-client resilience and quantum-safe cryptography. Where we publish standards, such as XDSS-PQ, we develop them as **open, NIST-aligned references** so the wider ecosystem and institutional adopters can build on them. #### What we work on **Multi-client infrastructure**go-ethereum (GP5), Erigon, Nethermind & Reth diversity **Modern-geth re-baseline**XDPoS on pristine go-ethereum v1.17.3, with parity harness **Post-quantum initiative**XDSS-PQ standard & phased PQ migration roadmap **Measurement & tooling**live node telemetry, consensus-parity verification [Multi-client architecture The 4-client diversity story →](https://xdc.network/labs/network-architecture/) [geth v1.17.3 re-baseline What it inherits · how XDPoS layers on →](https://xdc.network/labs/modern-geth-migration/) [The quantum initiative Threat model & XDSS-PQ standard →](https://xdc.network/labs/quantum/) ### What we build on, and the standards we align to. The references below are intentionally conservative: the network we build on, the open-source clients that give XDC its diversity, and the public cryptographic standards our PQ work aligns to. No co-authorship, endorsement or formal partnership is implied beyond what is stated. #### Built on Network ##### XDC Network The enterprise-grade, EVM-compatible Layer-1 (XDPoS consensus) we build core infrastructure and the PQ initiative for. [xdc.network →](https://xdc.network) Client · Go ##### go-ethereum (GP5) The XDPoS execution client re-based onto pristine go-ethereum v1.17.3, our reference for bit-exact consensus parity. [GitHub →](https://github.com/XDCIndia) Clients · multi-language ##### Erigon · Nethermind · Reth The independent clients (Go, C#/.NET and Rust) that together give XDC mainnet full client diversity across implementations. Erigon · Go Nethermind · .NET Reth · Rust #### Standards we align to PQ cryptography ##### NIST FIPS 203 / 204 / 205 / 206 The NIST post-quantum standards that XDSS-PQ and our PQ roadmap are designed to align with: ML-KEM, ML-DSA, SLH-DSA and FN-DSA (Falcon, draft). FIPS 203 · ML-KEM FIPS 204 · ML-DSA FIPS 205 · SLH-DSA FIPS 206 · Falcon Trade-document law ##### MLETR The UNCITRAL Model Law on Electronic Transferable Records, the legal frame for electronic trade documents that XDSS-PQ is designed to align with. Electronic transferable records Regulatory context ##### EU PQC · CNSA 2.0 Our PQ roadmap is positioned ahead of the EU PQC migration (2030) and CNSA 2.0 timelines that affect regulated finance, as context we target, not certifications we hold. [PQ migration roadmap →](https://xdc.network/labs/quantum-roadmap/) "Built on" denotes software and networks we use; "align to" denotes public standards we design toward. These are not endorsements, partnerships, or certifications. ### From founding to a quantum-safe roadmap. A dated line of the lab's modernization and post-quantum work: what's done, and what's planned. Each milestone is documented elsewhere on this site. - 2024**XDC Innovation Labs founded**To harden XDC Network on two fronts: infrastructure and post-quantum security. - Achieved**Multi-client diversity: 4 clients, 3 languages**First XDPoS chain with full client diversity, all live on mainnet. [Architecture →](https://xdc.network/labs/network-architecture/) - Achieved**go-ethereum v1.17.3 re-baseline**XDPoS layered onto modern geth (PBSS, Pebble, freezer, snap sync), bit-exact parity. [The migration →](https://xdc.network/labs/modern-geth-migration/) - Published**XDSS-PQ post-quantum standard**Open signature standard on NIST-selected algorithms (ML-DSA + Falcon). [Read the spec →](https://xdc.network/labs/xdss-pq-spec/) - Q2-Q3 2026**Phase 0: cryptographic audit & foundation (active)**Surface audit + risk matrix underway; hybrid-first design. [PQ roadmap →](https://xdc.network/labs/quantum-roadmap/) - 2030**EU PQC readiness target**The planned migration deadline regulated trade finance must meet. ### Work with the team hardening trade finance. Meet the people behind the work, see the roles we're hiring for, or get in touch about the multi-client and post-quantum initiatives. [Meet the team →](https://xdc.network/labs/team/) [Careers](https://xdc.network/labs/careers/) [Get in touch](mailto:pq@xdcindia.com?subject=XDC%20Innovation%20Labs) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Labs insights and engineering notes URL: https://xdc.network/labs/blog/ Last reviewed: 2026-10-22 Browse the Labs publication index covering client engineering, the modern-geth migration and post-quantum research, with source dates and attribution. > Preserved XDC Innovation Labs reference content from the linked repository snapshot. Dates, measurements, rollout targets and availability are source-reported; consult current maintainer guidance before implementation. Blog · XDC Innovation Labs Insights & updates. Highlights from our research and engineering — multi-client infrastructure, the modern go-ethereum re-baseline, and the post-quantum work behind XDSS-PQ. Each entry below links to the full write-up on this site. Read the highlights [Research index →](https://xdc.network/labs/quantum-research/) Highlights from our research & engineering ### What we've published. This isn't a stream of announcements — it's an honest index of the deep-dives already on this site. Every card links to the full page it summarises. Featured — latest Infrastructure Mar 2026 #### XDPoS on pristine go-ethereum v1.17.3 — measured How we re-based the XDPoS engine onto current go-ethereum and what it inherits — path-based state, Pebble, freezer, snap sync — with bit-exact consensus parity. The single most impactful infrastructure change in the XDC multi-client effort. Read the deep-dive → 3× Smaller on disk 303 GB Modern node 25/25 Claims verified Trade financeJun 2026 #### Quantum-safe trade finance: will an on-chain document survive Q-Day? Trade documents must stay legally valid for 20–30 years — longer than most Q-Day estimates. Why that makes harvest-now-decrypt-later a present risk, and how XDSS-PQ answers it. Read the analysis → ComparisonJun 2026 #### Quantum-resistant blockchains compared (2026) An honest matrix of QRL, Algorand, QANplatform and XDC's XDSS-PQ — algorithm, EVM-compatibility, live-vs-roadmap status and focus, with sources. Read the comparison → InfrastructureFeb 2026 #### XDC achieves full multi-client diversity Four independent clients across three languages — go-ethereum (GP5), Erigon, Nethermind and Reth — live on mainnet, so client diversity can reduce shared implementation risk, subject to validator distribution and consensus thresholds. Read the architecture → Post-quantumJan 2026 #### Introducing the XDC PQ Initiative & XDSS-PQ Why we're mapping and migrating XDC's quantum-exposed surface now, and the post-quantum signature standard (XDSS-PQ) built on NIST-selected algorithms. Read the initiative → Post-quantumDec 2025 #### Q-Day is a probability, not a date Why "when will quantum break ECDSA?" is best treated as a risk distribution — and what that means for 20–30 year trade documents you can't re-sign later. Read the framing → ResearchOct 2025 #### Quantum threats to XDC — a technical deep-dive A walk through XDC's quantum-exposed surface — signatures, validator keys, bridges and P2P — and the harvest-now-decrypt-later threat model. Read the research → ResearchAug 2025 #### Reading the 2025 Gidney result on RSA-2048 Our take on Craig Gidney's 2025 estimate that breaking RSA-2048 may need far fewer qubits than once thought — and why it tightens the timeline for migration. Read the analysis → Dates reflect when each topic was written up for this site. These entries summarise and index existing pages and published research — follow each link for the full detail and sources. ### Go deeper into the work. Explore the engineering and the post-quantum initiative behind XDC Innovation Labs — or get in touch with the team. [Explore the work →](https://xdc.network/labs/network-architecture/) [Get in touch](mailto:pq@xdcindia.com?subject=XDC%20Innovation%20Labs) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC Innovation Labs brand resources URL: https://xdc.network/labs/brand/ Last reviewed: 2026-10-22 The Labs source provides logo variants, colors, typography and usage guidance for its identity. These materials belong to the source publisher. > Preserved XDC Innovation Labs reference content from the linked repository snapshot. Dates, measurements, rollout targets and availability are source-reported; consult current maintainer guidance before implementation. Brand & press kit XDC Innovation Labs — brand assets. Logos, colors and type for press, partners and integrators. Please use the marks as provided — don't recolor, distort, or recreate them. ### Logo SVG (preferred, scalable) and PNG. Use the dark-background mark on dark surfaces and the light mark on light surfaces. [Download SVG (dark)](https://xdc.network/labs-assets/xdc-logo-dark.svg) [Download SVG (light)](https://xdc.network/labs-assets/xdc-logo-light.svg) [Icon — SVG](https://xdc.network/labs-assets/xdc-icon.svg) [Icon — PNG](https://xdc.network/labs-assets/xdc-icon.png) ### Color The core palette (dark theme). XDC blue is the primary brand color; quantum cyan marks the post-quantum work. Void #01040F XDC Blue #1D4ED8 Blue 2 #2563EB Accent #3B82F6 Sky #93C5FD Cyan 1 #0891B2 Quantum Cyan #06B6D4 Cyan 3 #22D3EE ### Typography Two open-source typefaces, both loaded site-wide. DM Sans Display & body — headings, prose, UI JetBrains Mono Mono — labels, code, figures, eyebrows ### Usage - Refer to us as **XDC Innovation Labs** (not "XDC Labs" or "XInFin Labs"). - Keep clear space around the logo equal to the height of the icon mark. - Don't recolor, rotate, stretch, add effects to, or recreate the marks. - Place the logo only on sufficiently contrasting backgrounds (use the matching dark/light variant). - XDC Innovation Labs builds on the XDC Network; it is not the XDC Network itself — please don't imply otherwise. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Labs roles and expressions of interest URL: https://xdc.network/labs/careers/ Last reviewed: 2026-10-22 The Labs source outlines illustrative engineering roles and a contact route. This reference does not confirm current vacancies or hiring availability. > These are illustrative role areas and an expression-of-interest route. They do not establish that a specific vacancy is currently open. Careers · XDC Innovation Labs Work with us. We're hardening XDC Network on two fronts — **multi-client infrastructure** and **post-quantum security** — for the next thirty years of global trade finance. If you like systems work that ships and gets measured in production, you'll feel at home here. Why join See roles → 4 live clients on mainnet go-ethereum (GP5) · Erigon · Nethermind · Reth 3× smaller on disk modern-geth node vs legacy full node — measured Remote · worldwide fully distributed team async-first · deep work · outcomes over hours How we hire Step 1 Read the code first See how we actually work before writing a single word. [github.com/XDCIndia](https://github.com/XDCIndia) Step 2 Send a 1-paragraph pitch No ATS. Every message goes straight to a human. [pq@xdcindia.com](mailto:pq@xdcindia.com) Step 3 Work together in the open Ship to mainnet, measure it, publish the numbers. Remote, async, outcomes over hours. Why join ### Real mission. Measured impact. Open source. We're a small engineering-led team working on problems that matter for regulated, real-world finance on-chain — and we work in the open. 01 #### A mission that matters Two slow-moving, existential risks — infrastructure debt and the quantum threat — converging on 20–30 year trade documents. The work has weight, and a clear reason to exist. 02 ##### Measured, not promised We ship to XDC mainnet and measure it: four clients live, a modern-geth node 3× smaller on disk and ~40× lighter on CPU, bit-exact consensus parity. Your work shows up in production numbers. 03 ##### Open source by default Our client and tooling work lives in public repositories. Read the code, see how we work, and contribute before you ever apply — [github.com/XDCIndia](https://github.com/XDCIndia). 04 ##### Remote & async We're remote-first and asynchronous. We optimise for deep work, clear written communication, and outcomes over hours-at-a-desk. 05 ##### Hard, current problems Path-based state, snap sync, multi-client diversity, NIST post-quantum signatures (ML-DSA / Falcon), hybrid signing. Modern protocol engineering, not maintenance of legacy forks. 06 ##### Ahead of the deadline DORA, CNSA 2.0, the EU PQC roadmap (2030) and NIST deprecation (2035) are all coming. We're building for them now — your work is early, not reactive. Open roles ### Roles we're typically hiring for These are the kinds of people we usually want to talk to. We don't run an applicant-tracking system — every application goes straight to a human. ⚠These listings are **illustrative** — they describe the profiles we typically hire for, not a live, guaranteed-open requisition list. If something fits, reach out anyway; we open roles as the work demands. Post-Quantum Cryptography Researcher CryptographyRemoteResearch + impl Work on the XDSS-PQ standard: NIST ML-DSA (FIPS 204) and Falcon (FIPS 206), hybrid signing, and migrating XDC's quantum-exposed surface. Comfortable reading specs and turning them into code. [Apply →](mailto:pq@xdcindia.com?subject=Application%20%E2%80%94%20Post-Quantum%20Cryptography%20Researcher) Protocol Engineer (Go) GoRemotego-ethereum / XDPoS Maintain and extend the XDPoS engine on a modern go-ethereum base (v1.17.3) — consensus, state, sync — while preserving bit-exact parity with the canonical chain. [Apply →](mailto:pq@xdcindia.com?subject=Application%20%E2%80%94%20Protocol%20Engineer%20(Go)) Rust Client Engineer RustRemoteClient diversity Contribute to XDC's client-diversity story on the Rust side (Reth-family work) — execution, sync and tooling — as part of a multi-client mainnet. [Apply →](mailto:pq@xdcindia.com?subject=Application%20%E2%80%94%20Rust%20Client%20Engineer) Multi-Client Infrastructure Engineer InfraRemoteNodes / observability Run and measure a fleet of heterogeneous clients (go-ethereum/GP5, Erigon, Nethermind, Reth) on XDC mainnet — deployment, observability, snap sync and the measurement harness behind our published numbers. [Apply →](mailto:pq@xdcindia.com?subject=Application%20%E2%80%94%20Multi-Client%20Infrastructure%20Engineer) Developer Advocate DevRelRemoteDocs / community Help developers build on XDC: documentation, examples, technical writing and community engagement around our infrastructure and post-quantum work. [Apply →](mailto:pq@xdcindia.com?subject=Application%20%E2%80%94%20Developer%20Advocate) #### Don't see your role? Get in touch. We hire for talent and fit more than for a fixed job description. If you're strong in protocol engineering, cryptography, infrastructure or developer experience and you care about this mission, tell us what you'd want to work on. [Email us → pq@xdcindia.com](mailto:pq@xdcindia.com?subject=Open%20application%20%E2%80%94%20XDC%20Innovation%20Labs) [See our code →](https://github.com/XDCIndia) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Developer resources from XDC Innovation Labs URL: https://xdc.network/labs/developers/ Last reviewed: 2026-10-22 The Labs guide collects XDC documentation, client repositories, testnet resources and setup references. Confirm current compatibility before implementation. > These guides cover familiar EVM workflows on XDC. Confirm compiler targets, supported opcodes, RPC methods and network-specific behavior before deployment. Test on Apothem first. Setup and comparison links are operational references; they do not guarantee current client readiness or full compatibility with every Ethereum feature. Build on XDC Everything you need tobuild on XDC Network. XDC is a 100% EVM-compatible chain: your existing Solidity contracts, tooling and wallets work unchanged. Start on the Apothem testnet, deploy with the tools you already know, and run a node in one command. Deploy your first contract → [Get testnet XDC →](https://faucet.apothem.network/) Developer resources ### Docs, testnet, client source and node tooling. #### Documentation Developer guides, RPC reference, contract deployment, and integration docs for the XDC Network. [Read the docs →](https://docs.xdc.network) docs.xdc.network #### Apothem testnet & faucet Free testnet XDC to deploy and test against, with a testnet explorer and RPC endpoint. Chain ID 51. [Get testnet XDC →](https://faucet.apothem.network/) faucet.apothem.network · apothem.network #### Client source code The XDPoS client (Go) and the Besu fork, open source on GitHub. Build, audit, or contribute. [XinFinOrg/XDPoSChain →](https://github.com/XinFinOrg/XDPoSChain) + github.com/XDCIndia/besu-xdc #### Run a node One command installs a sha256-verified geth binary, restores a snapshot, and syncs to mainnet in minutes. [One-command setup →](https://xdc.network/labs/run/) xdc.network/run #### Live RPC compare Run JSON-RPC parity checks between the legacy and modern XDC clients live, in your browser. [Open the comparison →](https://xdc.network/labs/geth-compare/) xdc.network/geth-compare #### Node software & snapshots Pre-built binaries, the XDPoSChain Docker image, reproducible source builds, and chaindata snapshots. [Downloads →](https://xdc.network/labs/downloads/) xdc.network/downloads #### Developer forum Community-written guides and articles from XDC builders: RPC, integrations, and deployment walkthroughs. [Browse xdc.dev →](https://www.xdc.dev) xdc.dev #### Network & tools Explorers, public RPC endpoints, testnet, and live network status: the operational surface of XDC. [Network & tools →](https://xdc.network/labs/network/) xdc.network/network #### Security & disclosure Open-source clients, multi-client resilience, the in-progress crypto audit, and how to report a vulnerability responsibly. [Security posture →](https://xdc.network/labs/security/) xdc.network/security All links above point to live, public XDC resources. XDC Innovation Labs maintains the multi-client infrastructure behind them; see the [architecture](https://xdc.network/labs/network-architecture/) and [modern-geth migration](https://xdc.network/labs/modern-geth-migration/). Deploy your first contract ### Standard Ethereum tooling. No forks, no rewrites. XDC is 100% EVM-compatible (chain IDs 50 mainnet / 51 Apothem). Point the tools you already use at the XDC RPC: your Solidity, ABIs and scripts work unchanged. Hardhat ``` // hardhat.config.js — networks xdc: { url: "https://rpc.xinfin.network", chainId: 50 }, apothem: { url: "https://rpc.apothem.network", chainId: 51 } ``` npx hardhat run scripts/deploy.js --network apothem Foundry ``` # foundry.toml — [rpc_endpoints] xdc = "https://rpc.xinfin.network" apothem = "https://rpc.apothem.network" ``` forge create --rpc-url apothem --chain 51 \ src/MyContract.sol:MyContract Remix Add XDC to your wallet on the [Network page](https://xdc.network/labs/network/), then in Remix pick **Injected Provider** and deploy: your wallet signs against XDC. No plugin needed. Need test XDC first? Grab it from the [Apothem faucet](https://faucet.apothem.network/) (chain ID 51). Coming from Ethereum? ### It behaves like Ethereum. Here are the only deltas. XDC runs the same EVM bytecode and Solidity, served over standard JSON-RPC by geth-based clients (that's what the [modern-geth migration](https://xdc.network/labs/modern-geth-migration/) is). There are no XDC-specific opcodes or gas rules to learn. The differences are exactly three: Chain IDs Mainnet 50 (0x32), Apothem testnet 51 (0x33). Set these in your config; everything else is standard EVM. Address prefix XDC addresses are shown with an `xdc` prefix instead of `0x`, a display convention only. The same 20-byte address works identically with `0x` at the RPC and in tooling. Fees & blocks ~2-second blocks and sub-cent gas. See the live gas price on the [homepage](https://xdc.network/labs/overview/) rather than a hardcoded figure. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC client downloads and verification reference URL: https://xdc.network/labs/downloads/ Last reviewed: 2026-10-22 The Labs snapshot lists client artifacts, source builds, snapshots and verification steps. Version labels and system requirements need current maintainer checks. > Version labels and sizing below come from the source snapshot, not a current release check. Verify the chosen artifact and published digest before deployment. Checksums establish file integrity against a trusted value, not a security audit. Example Docker port mappings expose RPC; apply the official node security guidance for your deployment. [XDC Innovation Labs](https://xdc.network/labs/overview/) / Downloads Node software · Run XDC mainnet & Apothem testnet Download XDC node software Run the canonical **XDPoSChain v2.7.0** production client via Docker, reproducible source builds, and chaindata snapshots — everything to run a full or validator node on XDC mainnet or Apothem testnet, sha256-verified. Run with Docker Build from source [Release notes →](https://github.com/XinFinOrg/XDPoSChain/releases) Docker Source Snapshots Verify Fastest path ### One command, or pick your install New operators can bootstrap a node in a single command. Everyone else: grab a binary, pull the Docker image, or build from source below. ⓘ System requirements click to expand curl Only prerequisite (1-command) Linux / macOS amd64 or arm64 Go 1.21+ · C compiler Source builds only ~16 GB disk Snapshot + headroom curl -fsSL https://xdc.network/install.sh | bash 🐳 #### Docker (production) The canonical **XDPoSChain v2.7.0** client, pinned by content-addressable digest. Docker commands ⌥ #### Build from source Reproducible Go builds from the tagged XDPoSChain source — full control, any platform. Source build Docker · production client ### XDPoSChain v2.7.0 canonical The production consensus client, published to Docker Hub as `xinfinorg/xdposchain`. Pin by version tag for convenience, or by `sha256:` digest for reproducibility. docker pull xinfinorg/xdposchain:v2.7.0 docker run -d --name xdc \ -p 8545:8545 -p 30303:30303 \ -v xdc-data:/work \ xinfinorg/xdposchain:v2.7.0 Exposes JSON-RPC on `8545` and P2P on `30303`, persisting chaindata to the `xdc-data` volume. For a validator/masternode setup and environment flags, see the [documentation](https://docs.xdc.network). Build from source ### Compile XDPoSChain Clone the tagged source and build with the Go toolchain. Produces the `XDC` binary in `./build/bin/`. git clone --branch v2.7.0 https://github.com/XinFinOrg/XDPoSChain.git cd XDPoSChain make XDC Requires Go 1.21+ and a C compiler. The Go toolchain produces deterministic binaries from identical inputs — compare your `sha256sum ./build/bin/XDC` against the published image (see verification ↓). Chaindata snapshots ### Sync in hours, not days Skip the full historical sync by importing a recent chaindata snapshot, then let your node catch up to the tip. Mainnet and Apothem testnet snapshots (full & archive) are published and refreshed regularly. Mainnet snapfull · PBSS network ID 50 · zstd-compressed Apothem full & archive testnet · network ID 51 ~2 s block time at tip XDPoS 2.0 · deterministic finality [📦 Browse all snapshots →](https://xdc.network/snapshots/) [Run a node](https://xdc.network/labs/run/) Verification ### Verify before you run Every artifact is verifiable. Checksums catch download corruption; matching an independently authenticated source or image digest is one supply-chain verification step, not a guarantee. ✓ #### Cross-verify the production client Confirm the `XDC` binary inside the Docker image matches its content-addressable digest: docker pull xinfinorg/xdposchain@sha256: docker run --rm xinfinorg/xdposchain:v2.7.0 sha256sum /usr/local/bin/XDC For a locally-built binary, diff your `sha256sum ./build/bin/XDC` against the image's reported hash. Identical inputs (Go version, source tag, build flags) yield identical output. Next steps ### After you download Three natural next steps once you have the binary or image. ▶ #### Run with Docker Step-by-step guide — Docker, bare-metal, and managed options. Platform matrix, FAQ and one-command installer. [Run guide →](https://xdc.network/labs/run/) ⚈ #### geth RPC compare Run live JSON-RPC parity checks between your new node and the reference endpoint to confirm correct sync. [RPC compare →](https://xdc.network/labs/geth-compare/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC client comparison reference URL: https://xdc.network/labs/geth-compare/ Last reviewed: 2026-10-22 Read the Labs comparison methodology and historical measurements, then optionally run a limited RPC check. Endpoint responses do not establish consensus parity. > Historical figures and example PASS results are preserved as source claims, not results from this session. Live checks compare a limited set of RPC responses and do not prove full consensus parity or production readiness. Requests leave your browser for the chosen endpoints; avoid credentials in URLs and verify chain identity before comparing state. [XDC Innovation Labs](https://xdc.network/labs/overview/) / [Modern Geth Migration](https://xdc.network/labs/modern-geth-migration/) / Live Comparison Live · runs JSON-RPC in your browser Three XDC clients, side by side Live RPC, snapshot-size and consensus-parity results across three independent XDC clients: the legacy XDPoSChain client (rpc.xinfin.network · v2.6.8, a 2018 Geth ~1.8.3 fork), the modern re-baseline (new.xdcrpc.com · Geth v1.17.3-stable), and the Erigon client (02.xdcrpc.com/erigonrpc · Erigon 3.x). Calls run from your browser, latency is measured per-method, parity is checked against expected values. Verified bit-exact, in-sync at block #103.4M (2026-06-03). Endpoints Live RPC Snapshot size Expected results Consensus parity Performance At a glance · static · measured May 2026 · production XDC mainnet node (block ~103.3M) 3×smaller DB919 GB → 303 GB full node 19×live state~430 GB → ~22 GB (PBSS) ~15×faster sync5–8 days → ~6–10 h (snap) 10–15×RPC latencycold-cache eth_getBalance 0resync ritualsonline PBSS prune — never resync Step 1 · Endpoints ### Point the test runner at three RPC nodes Defaults below run against XDC mainnet public RPC for the legacy client, the modern v1.17.3 re-baseline (branch reset/integration-1.17.3) and the 02.xdcrpc.com/erigonrpc Erigon node. Swap any of them for an internal or test endpoint. Your inputs are saved locally to localStorage only — nothing leaves the browser. Legacy endpoint ~Geth 1.8.3 · XDPoSChain `https://rpc.xinfin.network` Modern endpoint Geth v1.17.3 · re-baseline `https://new.xdcrpc.com/` Erigon endpoint Erigon 3.x · archive-grade `https://02.xdcrpc.com/erigonrpc` WS: — WS: — WS: — Transport mode `` HTTP `` WebSocket `` Auto-refresh every 10s Status: idle · last run — i #### About these calls Each method is invoked over HTTPS POST as a JSON-RPC 2.0 request directly from your browser. Latency is wall-clock time measured with performance.now(). Parity status is computed against a known-good expected value (chain ID, base fee) or by cross-comparing the endpoints against the modern node (genesis hash, block hash, state root, balance). The legacy and modern defaults (rpc.xinfin.network, new.xdcrpc.com) return access-control-allow-origin: * via Cloudflare, so calls succeed from any origin — including file://. If a column reports a network error on every row, the most likely cause is missing CORS headers on that endpoint — enable them at the edge (Cloudflare response-header rule adding access-control-allow-origin: *) or on the node itself (--http.corsdomain "*", and for Erigon --rpc.accessList / a CORS-enabled reverse proxy). ⚡ Erigon CORS error? Fix it in 60 seconds › If every Erigon row shows a network error, the endpoint at `02.xdcrpc.com/erigonrpc` is missing `Access-Control-Allow-Origin` headers. Two fixes — choose the one that matches your setup: Option A — Cloudflare response-header rule `Set: Access-Control-Allow-Origin → * (Cloudflare Dashboard → Rules → Transform Rules → Response Headers)` Option B — Erigon node flag (if you control the node) `--http.corsdomain "*"` Step 2 · Live JSON-RPC ### Side-by-side, measured in real time Identical request payloads against all three endpoints, cross-checked against the modern node. Status column: PASS matches expected, FAIL diverges, DIFF intentional (e.g. client version), N/A unsupported on that client. #### Legacy · ~Geth 1.8.3 https://rpc.xinfin.network idle Avg latency: — ms Pass: — / — #### Modern · Geth v1.17.3 https://new.xdcrpc.com/ idle Avg latency: — ms Pass: — / — #### Erigon · 3.x https://02.xdcrpc.com/erigonrpc idle Avg latency: — ms Pass: — / — — / — Methods in parity — Block-height delta — ms Avg latency (modern) — ms Avg latency (Erigon) — ms Avg latency (legacy) Snapshot & database size ### Where the bytes live — legacy hash scheme vs PBSS Measured on XDC mainnet production nodes synced to head (~block 103.3M, syncing=false, 24 peers, May 2026). Both nodes are full nodes serving identical JSON-RPC; only the underlying storage engine differs. #### Legacy XDPoSChain v2.6.8 hash scheme · LevelDB 919 GB& growing Ancients (freezer .ldb files)**~415 GB** 45% · compressible · cold Live state trie (hash-keyed)**~430 GB** 47% · UNBOUNDED · no online prune Receipts / logs / misc**~74 GB** 8% Growth rate ~14 GB / week. The trie keeps every historical node it ever wrote; the only way to reclaim space is to stop the node and resync. ##### Modern Geth v1.17.3 fork PBSS · Pebble 303 GBstable, online-pruned Ancients (freezer .ranges)**281 GB** 93% · era-file offloadable Live state (PBSS, path-keyed)**~22 GB** 7% · BOUNDED · self-pruning Snapshot layer (flat)**~5 GB** 2% · O(1) reads Live-state portion stays flat at ~22 GB. No resync ritual. Snap-sync brings a fresh node from genesis to head in hours rather than days. Disk subsystem | Legacy (1.8.3) | Modern (1.17.3) | Δ | Mechanism | **Full-node total** | 919 GB | 303 GB | −3.0× | PBSS + Pebble + era-file ancients | Live state trie | ~430 GB & rising | ~22 GB stable | −19× | Path-based keys + online pruning | Ancients / freezer | ~415 GB | 281 GB | −32% | Better range encoding, snappy | Initial sync (fresh disk) | ~5–8 days (full) | ~6–10 h (snap) | ~15× | Snap sync + range proofs + healing | Resync to reclaim space | Required every ~2 mo | Never (online prune) | eliminated | PBSS state-history window | Archive node | ~2.5 TB · slow reads | ~1.6 TB · O(1) reads | −36% + faster | PBSS archive + flat snapshot | Cold-cache RPC read (eth_getBalance) | ~40–120 ms | ~3–8 ms | ~10–15× | Snapshot flat-layer lookup | Memory footprint (steady state) | ~8–16 GB | ~3–6 GB | −2× to −3× | Pebble cache + bounded PBSS | Snapshot taken on a single production node; absolute numbers vary with peer churn, indexing config and freezer cutoff. Ratios are the engineering-stable claim. Step 3 · Expected results ### What each test should return, and why For every JSON-RPC method below the comparison is well-defined. Where the legacy client can't answer (method added after 2018), the row is N/A. Where the response is supposed to differ between clients (e.g. client version string), the row is DIFF. Everything else must be PASS — the chain is the same chain. JSON-RPC method | Legacy (XDPoSChain v2.6.8) | Modern (Geth v1.17.3) | Rule · not yet run | **eth_chainId** | 0x32 (50) ✓ | 0x32 (50) ✓ | PASS · const match | **net_version** | "50" ✓ | "50" ✓ | PASS · const match | **eth_blockNumber** | #103,427,225 | #103,427,225 | PASS · Δ = 0 blocks | **eth_getBlockByNumber(0x0)** | 0x4a9d…d6b1 | 0x4a9d…d6b1 | PASS · genesis bit-exact | **eth_getBlockByNumber(0x1)** | hash 0x2c48…ad4f stateRoot 0x49be…55ae | hash 0x2c48…ad4f stateRoot 0x49be…55ae | PASS · cross-chain bit-exact | **eth_getBalance(0x…0088)** | 0x877f0a6e8dd7273ab680000 | 0x877f0a6e8dd7273ab680000 | PASS · state parity | **eth_feeHistory** | baseFee 0x2e90edd00 (12.5 gwei) | baseFee 0x2e90edd00 (12.5 gwei) | PASS · XDC fixed base fee | **net_peerCount** | 31 peers | 29 peers | PASS · both healthy | **eth_syncing** | false | false | PASS · both at head | **net_listening** | true | true | PASS | **txpool_status** | {pending,queued} | {pending,queued} | PASS · shape parity | **web3_clientVersion** | XDC/v2.6.8-stable/linux-amd64/go1.23.12 | Geth/v1.17.3-stable-02ebae0d/linux-amd64/go1.24.0 | DIFF · intentional | **eth_gasPrice** | ~13.75 gwei (suggested, dynamic) | ~15.00 gwei (suggested, dynamic) | DIFF · oracle estimate | **eth_protocolVersion** | 0x64 (XDPoS proto 100) | deprecated in 1.17 | DIFF · expected | **eth_getProof** | N/A · -32601 | Merkle proof returned | MODERN · EIP-1186 | **debug_dbAncients** | N/A · -32601 | 103,318,253 (freezer cutoff) | MODERN · freezer/era-files | ✓ #### Real-world verdict ( not yet run ) Both endpoints are in perfect sync at block #103,427,225. Every consensus-touching field — genesis hash, block-1 hash, block-1 stateRoot, system-contract balance, base fee — is bit-identical. The modern node additionally serves eth_getProof and debug_dbAncients (the freezer-cutoff sentinel exposes that 103.3M of 103.4M blocks live in flat ancient files, leaving only the recent tail in the bounded PBSS live state). Consensus-parity gate ### Bit-exact, fork-aware, harness-enforced Live RPC parity is the visible surface; the migration's release gate is bit-exact agreement on the consensus-critical bytes for every block on both networks. The harness replays mainnet blocks through both clients and asserts the three roots match — across normal blocks and every fork-activation boundary. Test | Range | Assertion | Latest run | **State root parity** | blocks 1 → head | stateRoot ≡ canonical | 103,288,114 / 103,288,114 PASS | **Receipts root parity** | blocks 1 → head | receiptsRoot ≡ canonical | 103,288,114 / 103,288,114 PASS | **Block hash parity** | blocks 1 → head | hash ≡ canonical | 103,288,114 / 103,288,114 PASS | **XDPoS v1 → v2 switch** | epoch boundary | consensus rule swap, hashes preserved | PASS | **Berlin / London / Shanghai forks** | activation blocks | EIP-2929 / 1559 / 3855 rules active | PASS | **Masternode rotation** | every epoch | validator set ≡ canonical | PASS | **TRC21 fee routing** | 200 sample txs | issuer pays gas, balances ≡ | 200 / 200 PASS | **Reward distribution (90/10)** | 10 random epochs | block reward split ≡ canonical | 10 / 10 PASS | **Genesis hash** | block 0 | 0x645a…d9c0 (mainnet) | PASS | ✓ #### Zero consensus divergence on integration branch Branch reset/integration-1.17.3 has replayed XDC mainnet to head with zero parity failures across all three roots. The modern binary serving the live endpoint above produces byte-identical blocks to the canonical XDPoSChain client. Performance — measured ### What changes when the storage engine actually catches up RPC latency, sync time, archive footprint and memory — measured on production-shape hardware (8 vCPU / 32 GB / NVMe), serving the same canonical XDC mainnet. RPC latency (cold cache) eth_getBalance82 ms → 6 ms eth_getStorageAt110 ms → 9 ms eth_call (sload)95 ms → 7 ms eth_getLogs (1k)3.4 s → 410 ms ~10–15× lower latency from PBSS flat snapshot Sync (genesis → head, fresh NVMe) Legacy (fast sync)~5–8 days Modern (snap sync)~6–10 hours Disk read amplification~22× → ~3× Bandwidth (sync)~890 GB → ~260 GB Range proofs eliminate per-node round-trips Steady-state resources Disk (full)919 GB → 303 GB Disk (archive)~2.5 TB → ~1.6 TB Memory8–16 GB → 3–6 GB Resync ritualevery ~2 mo → never PBSS + Pebble — modern engine, modern footprint [← Back to the migration write-up](https://xdc.network/labs/modern-geth-migration/) [See the multi-client result →](https://xdc.network/labs/network-architecture/) [View source · go-ethereum fork →](https://github.com/XinFinOrg/XDPoSChain) ### Complete source method reference The source comparison defines these 18 read-only requests. The checker above intentionally reports a smaller connectivity sample. Method availability, latest-block differences and protected namespaces do not by themselves establish correctness or consensus parity. Method / source label | Parameters | Source test class | Expected value or compared field | web3_clientVersion | [] | diff | | eth_chainId | [] | const | 0x32 | net_version | [] | const | 50 | net_peerCount | [] | nonzero | | net_listening | [] | truthy | | eth_syncing | [] | falsy | | eth_blockNumber | [] | block | | eth_gasPrice (suggested) | [] | diff | | eth_protocolVersion | [] | diff | | eth_getBlockByNumber(0x0) · genesis | ["0x0", false] | genesis | | eth_getBlockByNumber(0x1) · stateRoot | ["0x1", false] | cross | hash | eth_getBalance(0x…88) | ["0x0000000000000000000000000000000000000088", "latest"] | cross | | txpool_status | [] | shape | | eth_feeHistory · baseFee 12.5 gwei | ["0x4", "latest", [25, 50, 75]] | basefee | | eth_getProof (EIP-1186) | ["0x0000000000000000000000000000000000000088", [], "latest"] | modern_only | | debug_dbAncients (freezer) | [] | modern_only | | eth_getLogs(block 0x1, all topics) | [{"fromBlock": "0x1", "toBlock": "0x1"}] | logs_cross | | eth_getTransactionByHash (block 50M tx) | ["0x1202fe3fe3b62a631f05d783df74b59f6176750d074560c8727cb4c8d3664339"] | tx_cross | | #### Interpretation and source limitations The source row labelled stateRoot actually compares the block hash. Latest balances can refer to different blocks. A successful response is not an independent correctness proof. Debug methods are reference-only and are not required for the new public checker. Source classification | Meaning | const | Compare response with hardcoded source expected value. | diff | Expected to vary by client or oracle; source labels DIFF. | nonzero | Positive peer count indicates endpoint peers, not chain security. | truthy | Source expects true. | falsy | Source expects false. | block | Display observed height; source marks PASS without chain agreement check. | genesis | Compare with source hardcoded genesis hash. | cross | Compare the selected field or serialized value with another endpoint. | shape | Check only required response keys. | basefee | Compare first feeHistory base fee with source hardcoded value. | modern_only | Any successful result is labeled PASS by source; no substantive validation. | logs_cross | Compare entire JSON log arrays. | tx_cross | Compare transaction hash, blockHash and from fields. | Original comparison configuration ``` { "legacy": "https://rpc.xinfin.network", "modern": "https://new.xdcrpc.com/", "erigon": "https://02.xdcrpc.com/erigonrpc", "mode": "http", "expected": { "chainIdHex": "0x32", "netVersion": "50", "baseFeeHex": "0x2e90edd00", "genesisHash": "0x4a9d748bd78a8d0385b67788c2435dcdb914f98a96250b68863a1f8b7642d6b1" }, "sampleAddress": "0x0000000000000000000000000000000000000088", "qualification": "Source configuration only; no endpoint connection or current chain validation was performed." } ``` ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Plan an XDC node hosting budget URL: https://xdc.network/labs/hosting-calculator/ Last reviewed: 2026-10-22 Explore the Labs source cost model and edit planning assumptions. Historical provider examples are not current quotations or complete deployment budgets. > These are source-snapshot assumptions, not live provider quotes. The estimate uses an 8 vCPU / 32 GB machine with 2 TB for full nodes or 6 TB for archives. Region, egress, backups, support, taxes and discounts can change the total. Edit assumptions and confirm current provider pricing before budgeting. [XDC Innovation Labs](https://xdc.network/labs/overview/)/Hosting cost calculator Tool · live estimate What does it cost to host an XDC node? Live monthly-cost estimate across **six cloud providers** — full vs archive node, on-demand vs 1-year reserved. List prices, not live quotes. Pair with the [system requirements](https://xdc.network/labs/run/) on the Downloads page and verify your install against the [Live Compare](https://xdc.network/labs/geth-compare/) tool. ### Methodology Costs are computed from each provider's **published list pricing** for a single 8 vCPU / 32 GB virtual machine, plus a per-GB monthly rate for fast SSD or NVMe-class block storage. Real bills will differ by region, commit term, network egress, snapshots, support tier, and credits. - **Box shape** 8 vCPU · 32 GB RAM — the public-RPC recommended shape from the [Downloads requirements](https://xdc.network/labs/run/) table. - **Full node** 2 TB storage — modern Geth v1.17.3 PBSS full node sits at ~303 GB today, with headroom for growth. - **Archive node** 6 TB storage — PBSS archive is ~1.6 TB today, again with headroom. Legacy hash-scheme archives run larger. - **Reserved** 1-year reserved instance discount applied to compute only. Vultr and DigitalOcean have no reserved tier, so on-demand and reserved are identical for those two. - **Storage** Provider's per-GB monthly block-storage rate. No snapshot, backup, or egress costs included. - **Network egress**Not modelled. A typical full node consumes ~3–8 TB/mo of outbound traffic; most providers include a free tier (e.g. AWS 100 GB, GCP 200 GB, Oracle 10 TB) and bill overage at $0.01–0.09/GB. ### Want a self-hosted estimate? If you're running on bare-metal or a colocated box, the dominant cost is the NVMe drive and the box's amortized monthly figure. A **2 TB enterprise NVMe** is ~$300 one-time + electricity; a **6 TB** set runs ~$1,000 one-time. A 16-vCPU / 64 GB used-server amortized over 36 months at home or in a colo is typically **$60–150/mo all-in** — below every cloud option for archive workloads, with the trade-off of operational responsibility. ### Complete source cost assumptions Historical USD monthly examples for an 8-vCPU / 32-GB planning profile. No provider region, SKU or pricing verification date is supplied. Full-node storage is 2,000 GB; archive storage is 6,000 GB. Provider | Compute / month | Storage / GB-month | Reserved compute discount | Azure | 280.0 | 0.13 | 40% | AWS | 294.0 | 0.08 | 40% | Google Cloud | 283.0 | 0.1 | 45% | Vultr | 160.0 | 0.1 | 0% | DigitalOcean | 252.0 | 0.1 | 0% | Oracle Cloud | 108.0 | 0.0255 | 40% | Source formula: total = compute * (reserved ? 1 - reservedDiscount : 1) + storageGB * storagePerGB Original exclusions: egress, snapshots, backups, support, taxes, credits, regional differences. The planner above lets you add explicit egress costs. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC Innovation Labs: engineering and research URL: https://xdc.network/labs/overview/ Last reviewed: 2026-10-22 Explore the Labs repository overview of client modernization and post-quantum work. Performance, deployment and readiness statements are source-reported. > This is the Labs repository overview. Performance, client-readiness and quantum-readiness statements are publisher reports. Read the current client restrictions and research status before using them for an operational decision. XDC Innovation Labs, resilient and quantum-safe by design Future-proofing thechain that moves global trade. Two clocks are ticking on global trade finance: **infrastructure debt** and the **quantum threat**. XDC de-risks both, measured in production. [See live proof →](https://xdc.network/labs/geth-compare/) [View architecture →](https://xdc.network/labs/network-architecture/) 4 clients 3 languages live on XDC mainnet, full client diversity 3× smaller Modern-geth node disk vs legacy full node, measured ~40× Less CPU at the head, idle steady-state, measured XDSS-PQ Post-quantum standard, ahead of EU PQC deadlines A new block every **~2 seconds**. XDPoS 2.0 with ~2-block deterministic BFT finality connecting… - - - - - - latest block — - XDC~2s - Ethereum~12s - Bitcoin~10 min ~2 s blocks, ~2,000 TPS capacity, deterministic BFT finality Make XDC the most resilient and quantum-safe Layer-1 for regulated, real-world finance, ahead of the regulation and ahead of the threat. Two pillars, one network ** Infrastructure resilience**Multi-client diversity on a modern go-ethereum foundation. ** Post-quantum security**XDSS-PQ, ahead of the regulatory deadlines. [See the architecture →](https://xdc.network/labs/network-architecture/) The problem ### Two clocks are ticking. Most chains hear neither. XDC settles trade-finance instruments, documents and value that must stay verifiable for 20 to 30 years. That long horizon turns two slow-moving risks into existential ones. #### Clock 1 - Infrastructure debt Single-client networks are one bug away from a halt. Legacy node software carries years of accreted state-storage and sync debt: bloated disks, slow RPC, heavy hardware. Every year on old foundations raises the cost and the risk of running the network. Compounding, every block #### Clock 2 - The quantum threat A cryptographically-relevant quantum computer breaks the ECDSA signatures protecting keys, bridges and signed documents. Adversaries harvest encrypted data now to decrypt later, so 30-year trade documents signed today are already exposed. Harvest-now, decrypt-later ### A multi-client network, on a modern foundation. Shipping now XDC is the first XDPoS chain with full client diversity: four independent implementations across three languages, live on mainnet. In parallel, we re-based the XDPoS engine onto pristine go-ethereum v1.17.3 (branch reset/integration-1.17.3), inheriting a decade of upstream engineering, with bit-exact consensus parity. Client diversity #### 4 clients, 3 languages go-ethereum (GP5), Erigon, Nethermind and Reth, Go, C#/.NET and Rust, all live on XDC mainnet. Client diversity can reduce shared implementation risk; resilience also depends on validator distribution and consensus thresholds. Modern foundation ##### geth v1.17.3 re-baseline XDPoS layered additively onto current go-ethereum: path-based state (PBSS), Pebble, freezer/ancients, snap sync and the modern wire protocol, without touching consensus. Consensus parity requires verification ##### Bit-exact parity Block production, RLP encoding, hashes, rewards and masternode economics are unchanged. A parity harness verifies identical state roots, receipts and block hashes against canonical chain. #### Measured, modern-geth node vs legacy full node Live readings from XDC mainnet production nodes, synced to head. 303 GB Modern-geth node disk vs 919 GB legacy ~2-6× RPC latency improvement eth_getBlockByNumber, IPC ~40× Lower CPU at idle head Steady-state, synced Bit-exact Consensus parity State, receipts, block hash [Multi-client architecture The 4-client diversity story →](https://xdc.network/labs/network-architecture/) [geth v1.17.3 branch What it inherits, how XDPoS layers on →](https://xdc.network/labs/modern-geth-migration/) ### Quantum-safe before the deadline, not after the break. XDSS-PQ v1.0 The XDC PQ Initiative introduces XDSS-PQ, a post-quantum signature and key standard built on NIST-selected algorithms. We are mapping and migrating XDC's full quantum-exposed surface, prioritised by what cannot be re-signed later: long-lived trade documents. #### The exposed surface ##### Trade document signatures ECDSA, secp256k1, 20-30yr lifespan Critical Validator masternode keysECDSA, secp256k1, 108 validator keys High Bridge & DAO governanceECDSA multisig, cross-chain, indefinite High P2P node communicationsECDH, TLS 1.2-1.3, HNDL active now Active #### The regulatory clock is already running In force **DORA - EU**Financial entities must demonstrate robust cryptographic controls, the regulatory baseline for the trade-finance use XDC targets. Mandated **CNSA 2.0 - NSA**All new National Security Systems must be PQC-compliant on a fixed timeline. 2030 → **EU PQC Roadmap**Full PQC migration for EU critical infrastructure, the bar regulated trade-finance must meet. 2035 **NIST deprecation**ECDSA and all quantum-vulnerable algorithms deprecated from NIST standards. [For institutions Why regulated trade finance needs this →](https://xdc.network/labs/institutions/) [The quantum initiative Full threat model & XDSS-PQ standard →](https://xdc.network/labs/quantum/) [PQ migration roadmap Phased transition plan →](https://xdc.network/labs/quantum-roadmap/) ### Live on XDC mainnet. Key numbers for the chain powering global trade finance. Gas price is pulled live from the XDC mainnet RPC every five seconds; the rest are fixed network facts. live — gas price fractions of a cent per transfer ~2 s block time XDPoS 2.0 consensus ~2,000 TPS throughput capacity < 2 blocks finality deterministic BFT finality 50 chain ID mainnet 4 execution clients live on mainnet today live — validators XDPoS 2.0 masternodes ### We don't promise. We measure in production. 4 / 3 Clients / languages Live on XDC mainnet 303 GB Modern node on disk Synced to head, vs 919 GB legacy ~103.3M Mainnet block synced syncing = false, 24 peers Bit-exact Consensus parity State, receipts & block hash ● Measured live on XDC mainnet production nodes, not estimates ### A clear line of sight across both pillars. 2026 H1 - now - 4 clients live on mainnet - geth v1.17.3 re-baseline measured - PQ Initiative v1.0 + XDSS-PQ draft 2026 H2 - Modern-geth fleet rollout - Mainnet parity harness in CI - PQ pilot - trade-doc signatures 2027 H1 - Multi-client validator support - Hybrid quantum-safe validator & bridge keys - Third-party security audits 2027 H2 - Within 1 minor of upstream geth - XDSS-PQ v1 in production - Regulated-finance GA - ahead of EU PQC H1-2026 milestones are shipped or measured; later milestones are the active plan. ### The window and the work rarely line up. Right now they do. 01 #### The window is open Regulation (DORA, CNSA 2.0, EU PQC) and infrastructure debt are converging on the same deadline. Whoever solves both first owns regulated, real-world finance on-chain. 02 ##### The niche makes it existential XDC's 20-30 year trade documents turn "someday" risks into today's problem, and turn solving them into a durable, defensible moat that generic L1s can't claim. 03 ##### The proof is already in production Four clients live. A modern node measured 3× smaller and ~40× lighter on CPU, bit-exact. This is an execution team that ships and measures, not one that promises. ### Build, run, and explore XDC. Four ways to participate in the most resilient, quantum-safe trade-finance chain, from running infrastructure to shipping contracts to reading the source. #### Run a node Full node or masternode: snapshots, the one-command installer, and systemd templates. [Run a node →](https://xdc.network/labs/run/) #### Build on XDC EVM-compatible. Ship your Solidity contracts and tooling with ~2-second finality. [Read the docs →](https://docs.xdc.network) #### Explore the code Four open-source clients in three languages. Audit, contribute, or run your own. [View on GitHub →](https://github.com/XinFinOrg) #### Post-quantum research XDSS-PQ, the quantum-safe signature standard hardening XDC for the next thirty years. [Learn about XDSS-PQ →](https://xdc.network/labs/quantum/) Frequently asked ### Questions, answered. How fast is XDC Network's block time? XDC Network runs the XDPoS 2.0 consensus engine with a ~2-second block time and fast, deterministic BFT finality (about two blocks). Its current throughput capacity is approximately 2,000 TPS. How many node clients run on XDC mainnet? Four independent execution clients across three languages — go-ethereum (GP5) and Erigon in Go, Nethermind in C#/.NET, and Reth in Rust — all sync XDC mainnet. XDC is the first XDPoS chain with full client diversity, so client diversity can reduce correlated software failures, subject to validator distribution and consensus thresholds. What is XDSS-PQ? XDSS-PQ is XDC's post-quantum signature and key standard, built on NIST-selected algorithms. It is being introduced ahead of regulatory deadlines including DORA, CNSA 2.0 and the EU PQC roadmap, prioritizing long-lived trade-finance documents that must stay verifiable for 20–30 years. How much lighter is the modern XDC node? On XDC mainnet production nodes, the modern go-ethereum v1.17.3 re-baseline measures about 303 GB on disk versus roughly 919 GB for a legacy full node (about 3× smaller), with around 40× lower CPU at idle head — measured in production with bit-exact consensus parity. Is XDC Network quantum-safe today? XDC is actively migrating to post-quantum security through the XDSS-PQ standard rather than claiming it is finished. The quantum-exposed surface — trade-document signatures, validator and bridge keys, and node communications — is being mapped and migrated, prioritized by what cannot be re-signed later. ### Building the resilient, quantum-safe future of trade finance. XDC Innovation Labs is hardening XDC on two fronts: multi-client infrastructure and post-quantum security. Explore the engineering, or get in touch. [Get in touch](mailto:pq@xdcindia.com?subject=XDC%20Innovation%20Labs) [Explore the work →](https://xdc.network/labs/network-architecture/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## The Labs institutional infrastructure case URL: https://xdc.network/labs/institutions/ Last reviewed: 2026-10-22 The Labs source discusses resilience, trade-document integrity and post-quantum planning for institutions. Its regulatory and readiness claims require separate evidence. > Preserved XDC Innovation Labs reference content from the linked repository snapshot. Dates, measurements, rollout targets and availability are source-reported; consult current maintainer guidance before implementation. For institutions Built for the institutions that move global trade. Regulated trade finance faces two clocks: operational resilience and long-lived document security. XDC hardens the network, measured in production. XDSS-PQ sig The regulatory clock is already running ### A timeline regulated finance can plan against. These are mandates and deprecation dates that apply to the regulated entities XDC serves, not XDC claims. The point of the post-quantum work is to be ready ahead of them. In force **DORA - EU**Financial entities must demonstrate robust cryptographic controls and operational resilience. Jan 2027 **CNSA 2.0 - NSA**New National Security Systems must be on post-quantum cryptography on a fixed timeline. 2030 **EU PQC roadmap**Full PQC migration target for EU critical infrastructure. 2035 **NIST deprecation**ECDSA and other quantum-vulnerable algorithms deprecated from NIST standards (IR 8547). Why it matters now ### 30-year documents cannot wait for Q-Day. Trade documents signed today may be cited in litigation in the 2050s. Harvest-now, decrypt-later means the migration deadline is the planning deadline, not Q-Day. #### Operational resilience by design XDC mainnet runs **four independent execution clients across three languages** (go-ethereum/GP5, Erigon, Nethermind, Reth). A defect in any one leaves the others serving the chain, the multi-client resilience DORA expects of critical financial infrastructure. First XDPoS chain with full client diversity. [See the architecture →](https://xdc.network/labs/network-architecture/) #### Post-quantum standard (XDSS-PQ) An open signature standard built on **NIST-selected algorithms** (dual ML-DSA + Falcon) for long-lived trade-document integrity, introduced ahead of DORA, CNSA 2.0 and the EU PQC roadmap rather than claimed as finished. [Explore the initiative →](https://xdc.network/labs/quantum/) #### Verifiable, not promised The modernization is measured in production with bit-exact consensus parity, and the live RPC comparison lets anyone verify client behavior in their browser. Read the spec and the evidence. Do not take our word for it. [Read the XDSS-PQ spec →](https://xdc.network/labs/xdss-pq-spec/) [Get in touch](https://xdc.network/labs/overview/#contact) [View roadmap →](https://xdc.network/labs/quantum-roadmap/) Every figure on this page is drawn from XDC Innovation Labs' published architecture, quantum and spec pages, consolidated here for institutional readers. No partner, customer or adoption claims are made. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## The Labs modern-geth migration account URL: https://xdc.network/labs/modern-geth-migration/ Last reviewed: 2026-10-22 The Labs source describes rebasing XDPoS onto go-ethereum v1.17.3. Storage measurements, compatibility and consensus-parity results are publisher reports. > This is a migration proposal and historical engineering account. Upstream Geth features do not automatically establish XDC support. Disk, sync and performance figures describe the source’s measurements; a tagged production release and reproducible parity evidence remain separate release gates. [XDC Innovation Labs](https://xdc.network/labs/overview/) / Modern Geth Migration Engineering Analysis · Fact-Checked From Geth 1.8.3 → 1.17.3 Seven years of go-ethereum engineering rebuilt the parts XDC's legacy client never adopted. This is the case for re-platforming XDPoS onto a modern base — the pain points today, what each upstream release fixed, and the consensus that stays bit-for-bit unchanged. A modern, maintainable execution base is the prerequisite for safely carrying post-quantum cryptography — this re-baseline is the foundation under XDC's [quantum-first EVM chain](https://xdc.network/labs/quantum/) initiative (XDSS-PQ, by 2030). The Gap Pain Points 7-Year Timeline Pain → Fix Disk Economics What's Preserved Evidence The Ask [▶ Live Compare ↗](https://xdc.network/labs/geth-compare/) The Setup ### XDC's legacy client is a 2018 Geth fork XDPoSChain (the canonical XDC client, v2.7.0) is a hard fork of go-ethereum ~1.8.3. It selectively backported the toolchain and EVM rules — but kept 2018-era state storage, sync, and networking. Upstream geth spent the next seven years rebuilding exactly those layers. ~7 yrs Behind upstream Geth 1.8.3 (2018) → 1.17.3 eth/63 → 70 Wire-protocol gap 7 versions of evolution hash → PBSS State storage Unbounded → bounded 25 / 25 Claims verified Primary sources, 0 refuted ! #### This is the engineering "why" behind the multi-client effort The [Architecture page](https://xdc.network/labs/network-architecture/) shows the live result — 4 independent clients on mainnet. This page is the deep rationale: precisely what modern geth delivers, sourced and verified, and how it maps to XDC operator pain today. Current Pain Points ### What the 2018 base costs operators Seven compounding costs fall directly out of the legacy storage, sync, and networking architecture — higher infrastructure spend, slower and more fragile node operations, and accelerating maintenance risk. P1 · STORAGE #### Full nodes grow without bound ~919 GB and rising. The hash-scheme trie accumulates dead nodes and there's no online pruning (no snapshot → no prune-state), so operators must periodically resync to reclaim space. Hits: every node operator, masternodes, RPC providers P2 · SYNC ##### Initial sync takes days Fast-sync only — state is fetched node-by-node by hash, millions of latency-bound round-trips. New masternode / RPC bring-up and recovery are painfully slow. Hits: onboarding, disaster recovery P3 · ARCHIVE ##### Archive nodes are ~2.5 TB & slow The hash-scheme archive keeps every trie node ever written; reads walk the trie. Costly and high-latency for explorers, indexers, and analytics. Hits: explorers, indexers, RPC providers P4 · NETWORKING ##### Fragile, aging peering eth/62–63 with no ForkID and no request IDs. The node can't cheaply reject wrong-fork peers and needs custom bridging to talk to modern clients. Hits: reliability, engineering maintenance P5 · DRIFT ##### ~7 years of maintenance drift The base predates every modern subsystem. Security backports are hard, new EIPs can't land cleanly, and developer mindshare is low — risk compounds the longer the gap persists. Hits: security posture, ecosystem velocity P6 · FEATURES ##### No modern data / history features No EIP-4844 blobs, no era-file / EIP-4444 history expiry. No path to offload history or offer modern data availability. Hits: future scalability, archive footprint × ##### P7 · Execution internals stuck in 2018 Single-threaded code paths — no trie prefetcher, no parallel state hashing, LevelDB only. Lower throughput headroom under load than any modern client. The 7-Year Timeline ### What geth shipped, 1.8.3 → 1.17.3 Every version below is the first stable release that shipped the feature, verified against upstream git history and Ethereum Foundation release blogs. None of it exists in the XDC 2.7.0 base. v1.9.0 Jul 2019 #### Freezer / ancients + ForkID (eth/64) Cold blocks/receipts split into append-only flat files (~90k-block cutoff); EIP-2124 ForkID rejects incompatible peers at handshake. Missing v1.9.13 Feb 2020 ##### State snapshot (flat layer) O(1) account/storage reads and the foundation for snap sync. Missing v1.10.0 Mar 2021 ##### Snap sync + offline pruning + eth/66 request IDs Range-proof state download (snap default v1.10.4); request IDs match responses to requests. Missing v1.10.19 2022 ##### eth/67 — drops GetNodeData The prerequisite for PBSS: a node serving raw trie nodes by hash can't move to path-based keys. Missing v1.10.22 Sep 2022 ##### The Merge (PoS) + Engine API Internal PoW sealing retired (fully removed v1.14.0). XDC keeps XDPoS — adopts the cleanup, not the CL split. N/A (XDPoS) v1.11.0 Feb 2023 ##### Pebble DB + eth/68 Actively-maintained DB engine (default v1.12.0) replacing the one-person LevelDB project. Missing v1.13.0 Sep 2023 ##### Path-based state storage (PBSS) Online pruning by default — bounded full-node state. Default for new full nodes in v1.14.0. The headline fix. Missing v1.13.12 Feb 2024 ##### Era files (EIP-4444 path) Exportable, compressible history — lets nodes offload ancient history. Missing v1.16.0 → v1.17.3 2025–26 ##### eth/69 → eth/70 History-range advertisement (history-expiry-aware peering) and the latest wire protocol. Missing Pain → Fix ### Each pain point maps to a shipped capability The migration isn't speculative — every remedy is a feature already battle-tested on Ethereum mainnet, and now measured live on XDC mainnet. This is the heart of the case. Pain | Remedy (upstream capability) | First shipped | Outcome | P1 node bloat + resync | PBSS + online pruning | v1.13.0 / v1.14.0 | Full node stops growing; no resync | P2 days-long sync | Flat snapshot + snap sync | v1.9.13 / v1.10.0 | Fresh node to head in hours | P3 huge slow archive | PBSS archive + era files | v1.13.0 / v1.13.12 | Smaller, flat O(1) reads | P4 fragile peering | ForkID + request IDs | v1.9.0 / v1.10.0 | Robust peering; no bridge hacks | P5 maintenance drift | Within 1 minor of upstream | ongoing | Security fixes + EIPs land; mindshare | P6 no modern features | blobpool / 4844, era / 4444 | v1.12.1 / v1.13.12 | Optionality for blobs + history offload | P7 slow internals | Trie prefetch, parallel hashing, Pebble | v1.10–v1.11 | Throughput headroom | Two paths forward [Node operators Estimate your node cost See realistic hardware and hosting figures for a modern XDC node — sized from the 303 GB measured disk figure. Open the calculator →](https://xdc.network/labs/hosting-calculator/) [Engineers & contributors Run the live RPC comparison Live JSON-RPC methods tested against three clients — legacy, geth v1.17.3, and Erigon. See the parity gap in real time. Open geth-compare →](https://xdc.network/labs/geth-compare/) Disk Economics ### Why hash-scheme nodes grow — and PBSS bounds them The single biggest operator win, now measured. A hash-scheme node accumulates dead trie nodes with no online pruning; the modern PBSS node keys nodes by path with a bounded, self-pruning history window — so the live-state portion stops growing. 919 GB Legacy full node and rising — needs resync 303 GB Modern node — measured 281 GB freezer + ~22 GB live PBSS ~3× Smaller on disk synced to head · ~block 103.3M bounded PBSS live state online-pruned, no resync Where the bytes live — legacy hash scheme vs modern PBSS Legacy (hash scheme) — ~919 GB full node Ancients (frozen) immutable · compressible Live state (trie) GROWS unbounded · dead nodes pile up → Modern (PBSS, path scheme) — 303 GB, measured Freezer (281 GB) same + era-file offload Live state (~22 GB) BOUNDED · pruned online ✓ PBSS removes the prune-and-resync ritual — the live-state portion stays flat at ~22 GB * Modern node 303 GB (281 GB freezer + ~22 GB live PBSS) is measured on an XDC mainnet production node synced to head (~block 103.3M, syncing = false, 24 peers). Legacy ~919 GB full / ~2.5 TB archive are the corresponding hash-scheme figures; geth's own docs cite a hash-scheme full node growing >650 GB at +14 GB/week (illustrating the mechanism). What's Preserved ### Consensus-neutral by construction This is an engine-room swap, not a constitutional change. For any block, a migrated node must produce an identical post-state root, receipts root, and block hash to canonical XDC — a hard, harness-enforced constraint. ✓ #### Nothing at the consensus layer changes The migration adopts modern execution, storage, and sync underneath an unchanged XDPoS. Bit-exact parity is the release gate. KEEP 01 ##### XDPoS consensus v1 (round-robin) and v2 (HotStuff-style BFT), QC/TC, epochs, masternode selection — unchanged. KEEP 02 ##### Internal block production Masternodes seal blocks via XDC's own engine path. We do not adopt geth's external-CL / Engine-API model. KEEP 03 ##### Block & header RLP / hashes Validators / Validator / Penalties fields, byte-exact encoding, genesis hashes — unchanged. KEEP 04 ##### Economics Fixed 12.5 gwei base fee (no burn), TRC21 fee routing, rewards (90/10), penalties — unchanged. KEEP 05 ##### Chain identity Chain IDs 50/51, genesis, fork schedule, system contracts 0x88/0x89/0x90 — unchanged. GATE 06 ##### Parity harness Every consensus-touching change validated bit-exact vs canonical XDC — across normal blocks and fork boundaries. Evidence Base ### Fact-checked against primary sources The technical claims on this page were verified by a deep-research pass — fan-out search, then adversarial 3-vote verification (a claim needed a majority of refutes to be killed). 24 Sources fetched across 6 search angles 107 → 25 Claims → verified top claims adversarially checked 25 / 0 Confirmed / killed zero refuted primary Source quality EIPs · devp2p spec · EF blogs Verified claim | Source | Freezer split: 79 GB ancients vs 60 GB LevelDB at block 7.77M | EF blog v1.9.0 · geth docs | PBSS officially shipped v1.13.0, default for new full nodes v1.14.0 | EF blog v1.13.0 · v1.11.0 notes | Hash-scheme node >650 GB, +14 GB/week; PBSS prunes online | geth dbpruning docs | Snap sync: leaves + range proofs + healing; default v1.10.4 | geth sync-modes · devp2p snap | eth/67 dropping GetNodeData was the prerequisite for PBSS | EIP-4938 · EF blog v1.13.0 | ForkID (eth/64) rejects incompatible peers before block exchange | EIP-2124 / EIP-2364 | Full citations and the code-ship-vs-feature-ship reconciliation are maintained in the project's EVIDENCE-BASE doc. The Recommendation ### Complete the migration to production The work is already underway and de-risked: XDPoS has been re-based onto a pristine go-ethereum v1.17.3 base (branch reset/integration-1.17.3) and verified syncing mainnet to head with zero consensus divergence. The proposal is to finish it to a tagged production release, with the parity harness as the mandatory gate. 01 #### Approve completion Finish the modern-geth line to a tagged production release with an operator migration path. 02 ##### Parity harness as gate Bit-exact state-root / receipts-root / block-hash parity on every consensus-touching change. 03 ##### Resource mainnet + RPC parity Validate mainnet across fork boundaries; close the documented RPC parity gaps. [Explore the XDC client code on GitHub →](https://github.com/XinFinOrg/XDPoSChain) [▶ Run the live RPC comparison →](https://xdc.network/labs/geth-compare/) [See the live multi-client result →](https://xdc.network/labs/network-architecture/) GP5 Go — go-ethereum [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Erigon Go — Erigon v3 [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Nethermind .NET 8 — C# [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Reth Rust 2021 [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC multiple-client architecture reference URL: https://xdc.network/labs/network-architecture/ Last reviewed: 2026-10-22 Explore the Labs account of GP5, Erigon, Nethermind and Reth. Synchronization, consensus participation and production readiness are distinct milestones. > This page preserves Labs-reported architecture and historical measurements. Client sync, block production and production readiness are different milestones. The installer currently labels Erigon and Nethermind Beta, and XOne, Reth and Besu Experimental. Check the network restrictions in the run guide before selecting a client. [XDC Innovation Labs](https://xdc.network/labs/overview/) / Network Architecture Infrastructure · Foundation for a quantum-first chain Multi-Client Architecture✓ Achieved XDC Network runs **4 independent execution clients in 3 languages** — all syncing mainnet. The first XDPoS chain to achieve true multi-client diversity, delivering fault tolerance, performance diversity, and long-term network resilience. Explore the architecture [Live node monitoring →](https://stats.xdcindia.com/) Architecture Risk Mitigation Live Status Comparison Advantages Client Repos Section A — Current architecture ### Multi-client architecture ✓ achieved XDC Network now runs 4 independent execution clients across 6 servers — the first XDPoS chain to achieve true multi-client diversity. All 4 clients are syncing mainnet, eliminating the single point of failure that existed with the legacy Geth 1.8.3 fork. ✓ #### Client diversity achieved 4 independent clients in 3 languages (Go, Rust, C#) are all syncing XDC mainnet. A consensus bug in one client no longer affects the entire network — the remaining clients continue producing blocks while the bug is patched. 4 Live Clients GP5, Erigon, Nethermind, Reth 3 Languages Go, Rust, C# ~103.3M Mainnet Head Reference client at chain tip 6 Servers Multi-client fleet deployed Current network topology — 4 independent clients syncing mainnet across 6 servers XDPoS Consensus Layer (v1 + v2 BFT) Shared consensus specification — all 4 clients implement identical rules GP5 Go — Reference Client ~103.3M ✔ Reth-XDC Rust — First Rust XDPoS At tip ✔ Nethermind-XDC C# / .NET At tip ✔ Erigon-XDC Go — MDBX Storage Syncing · 11.5M ↻ All 4 clients independently verifying XDPoS consensus — no single point of failure [📊 Live node monitoring →](https://stats.xdcindia.com/) [📦 Download snapshots](https://xdc.network/snapshots/) Risk mitigation ### Risks now mitigated With 4 independent clients live on mainnet, the single-client risks that previously threatened network liveness are now mitigated through client diversity. Failure type | Previous risk | Current mitigation | Status | Consensus bug | 100% of validators stall — network halts | Only nodes running affected client are impacted; 3 other clients continue producing blocks | Mitigated | RPC regression | All DApps and integrations broken simultaneously | Operators switch RPC traffic to unaffected client; Reth, GP5, NM, Erigon all serve JSON-RPC | Mitigated | Memory/resource leak | No alternative client to fall back to | Operators restart affected client while others handle load; different memory profiles per client | Mitigated | P2P protocol exploit | Network-wide DDoS via single implementation | 4 independent P2P stacks; exploit in one doesn't affect others | Mitigated | Language runtime CVE | Go CVE affects 100% of nodes | 3 languages (Go, Rust, C#) — a Go CVE leaves Reth and Nethermind unaffected | Mitigated | Supply chain attack | Single dependency tree compromises all nodes | 4 independent dependency trees across 3 ecosystems (Go modules, Cargo, NuGet) | Mitigated | ✓ #### Modern protocol support achieved XDC clients now support eth/62, eth/63, eth/66–68, eth/100, and xdpos/100 wire protocols. Reth-XDC alone supports 7 protocol versions. The 2018 Geth fork protocol limitation is no longer the network bottleneck. Section B — Achieved architecture ### Multi-client design ✓ deployed XDPoS consensus has been successfully ported to four independent execution clients in three different programming languages — all syncing XDC mainnet. Validator operators choose their preferred client; the consensus layer is consistent across all implementations. Deployed multi-client topology — XDPoS consensus layer running across 4 independent live implementations XDPoS Consensus Layer (v1 + v2 BFT) Shared consensus specification — all clients implement identical rules GP5 Go — Reference ~103.3M ✔ Erigon Go — MDBX Syncing · 11.5M ↻ Nethermind C# / .NET At tip ✔ Reth Rust — First At tip ✔ Besu Java Planned 01 #### Blast radius reduction ✅ A consensus bug in one client affects only validators running that client. The other 3 independent clients continue producing blocks, maintaining network liveness. Now proven live — 4 clients running in parallel on mainnet. 02 ##### Performance diversity ✅ Reth delivers high-throughput parallel execution. Erigon provides a sub-300 GB archive via MDBX. GP5 and Nethermind provide Go and C# reference paths. All live on mainnet. 03 ##### Snap sync available ✅ Snapshots published at [xdc.network/snapshots](https://xdc.network/snapshots/). New operators sync in hours. Multi-TB full-replay requirement eliminated — lowering the barrier to validator infrastructure. 04 ##### Language diversity ✅ Three implementation languages deployed: Go (GP5, Erigon), Rust (Reth), C# (Nethermind). A Go runtime CVE leaves Reth and Nethermind unaffected. First XDPoS chain with 3-language client diversity. 05 ##### Modern protocol support ✅ All 4 clients support eth/66–68, eth/100, xdpos/100 wire protocols. Reth-XDC alone supports 7 protocol versions — enabling compatibility with the full Ethereum developer tooling ecosystem. 06 ##### Key technical breakthroughs Erigon: M2 validator ASCII decode fix. GP5: binary search ancestor caching. Reth: ECIES bridge via Erigon (reverse direction). NM: static-nodes mesh for peer stability. Live progress ### Client implementation status ✓ live Current sync status across all XDC execution clients. All 4 primary clients are live on mainnet. Live monitoring at [stats.xdcindia.com](https://stats.xdcindia.com/). Client | Base version | Language | Network | Status | Blocks synced | Key achievement | GP5 Go-Ethereum XDC | go-ethereum 1.14 modern branch: [v1.17.3](https://xdc.network/labs/modern-geth-migration/) | Go 1.22 | Mainnet + Apothem | Live | ~103.3M (head) | Snap sync, eth/66–68, rebased from Geth 1.8 → 1.14; v1.17.3 modernization branch in progress | Nethermind Nethermind XDC | Nethermind latest | .NET 8 | Mainnet + Apothem | Live | At tip | At tip — static-nodes mesh fix resolved peer stability; C# XDPoS fully operational | Erigon Erigon XDC | Erigon v3 | Go 1.22 | Mainnet | Syncing | ~11.5M (mid-sync) | Past V2 switch (block 80.37M); M2 validator ASCII decode fix applied; MDBX storage | Reth Reth XDC | Reth v1.x | Rust 2021 | Mainnet | Live | At tip | First Rust XDPoS client — at tip; ECIES bridge via Erigon (reverse direction) solved P2P | Besu Besu XDC | Hyperledger Besu | Java 21 | Mainnet | Planned | — | Architecture analysis complete; porting roadmap defined | 4 Clients Live GP5, Reth, NM, Erigon — all on mainnet 3 At Chain Tip GP5, Reth, Nethermind at head ~103.3M Mainnet Head Reference client at tip 6 Servers Deployed Multi-client fleet running Architecture comparison ### Legacy vs multi-client A direct comparison of capabilities between the legacy single-client architecture and the live multi-client implementation now running on XDC mainnet. Capability | Legacy (v2.6.8) | GP5 | Erigon XDC | Nethermind XDC | Reth XDC | Base version | Geth 1.8.3 (2018) | go-eth 1.14 | Erigon v3 | NM latest | Reth v1 | Language | Go | Go | Go | .NET / C# | Rust | Snap sync | No | Yes | Yes | Yes | Yes | Archive storage | ~919 GB | ~303 GB | ~300 GB | ~1 TB * | ~800 GB * | Wire protocol | eth/62, 63, 100 | eth/63–68 | eth/63–68 | eth/63–68 | eth/63–68 | XDPoS v1 | Yes | Yes | Yes | Yes | In progress | XDPoS v2 (BFT) | Yes | Yes | Yes | In progress | In progress | JSON-RPC API | Yes | Yes | Yes | Yes | Yes | Parallel execution | No | Roadmap | Yes | Yes | Yes | Engine API (CL-ready) | No | Yes | Yes | Yes | Yes | Validator support | Yes | Yes | Yes | In progress | Planned | * Source attribution — archive storage figures **XDC mainnet — measured directly:** GP5 (~303 GB) and Erigon (~300 GB) reflect actual XDC chain readings from the multi-client fleet. **ETH-mainnet-equivalent estimates:** Nethermind (~1 TB) and Reth (~800 GB) are sourced from each client's own documentation for a comparable Ethereum full-archive node. XDC chain state is smaller — these figures are upper bounds, not XDC measurements. Why switch? ### Client advantages vs XDC 2.6.8 Performance and architectural gains each client delivers over the current XDC 2.6.8 single-client infrastructure. Figures marked est. are ETH-mainnet-equivalent estimates from client documentation and community benchmarks, not direct XDC measurements. GP5 Go - ▲**~28× faster sync (est.)** — ~85 blk/s vs ~3 blk/s; resync in hours, not weeks - ▲**Snap sync** — new nodes join in hours, not weeks of full replay - ▲**PBSS online pruning** — no archive growth, prune without stopping the node Best for: Drop-in replacement for XDC 2.6.8 Erigon v3 Go - ▲**~300 GB archive** — flat MDBX storage on XDC mainnet vs ~919 GB legacy full node - ▲**~10× lower RPC latency (est.)** — flat B+ tree reads vs trie + LevelDB traversal - ▲**Higher RPC density (est.)** — ~2 GB RAM/instance vs 8–16 GB with v2.6.8 Best for: Archive nodes & high-throughput RPC operators Nethermind C# - ▲**JIT-compiled EVM** — RyuJIT optimization accelerates heavy smart-contract execution - ▲**Independent CVE surface** — .NET runtime isolates from Go CVEs; different blast radius - ▲**Parallel tx processing** — .NET TPL distributes EVM workload across CPU cores Best for: Enterprise & .NET environments Reth Rust - ▲**Zero GC pauses** — Rust ownership model eliminates runtime GC; no missed blocks under load - ▲**Low RPC latency (est.)** — Tokio async + zero-copy MDBX reads at peak concurrency - ▲**Highest RPC density (est.)** — ~2–6 GB RAM; most instances per server of all clients Best for: High-load RPC & latency-critical APIs Besu Java - ▲**Enterprise support via Consensys** — SLA, security audits, long-term maintenance - ▲**JVM ZGC** — sub-10 ms GC pauses; no stop-the-world events - ▲**Largest ecosystem** — widely deployed in enterprise & regulated finance Best for: Enterprise & regulated financial institutions (planned) Open source ### Client repositories All XDC Innovation Labs client implementations are fully open source under the XDCIndia GitHub organization. Contributions, issues, and forks are welcome. GP5 Go — go-ethereum 1.14 [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Erigon Go — Erigon v3 [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Nethermind .NET 8 — C# [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Reth Rust 2021 edition [View on GitHub](https://github.com/XinFinOrg/XDPoSChain) Besu Java 21 / Hyperledger [besu-xdc](https://github.com/XDCIndia/besu-xdc) #### Run your own XDC node in 60 seconds operator path ``` curl -fsSL https://xdc.network/install.sh | bash ``` Full platform guide and FAQ at [/run](https://xdc.network/labs/run/) — Docker, bare-metal, and managed options covered. 🔐 The two pillars connect #### Client diversity is the foundation for a quantum-first migration. Multi-client diversity is more than fault tolerance — it is the resilient base that lets XDC roll out its upcoming **XDSS-PQ post-quantum migration** one client at a time. Each implementation can adopt post-quantum signatures independently, verified against **bit-exact consensus parity**, so the chain hardens against the quantum threat **without ever halting the network**. Post-quantum readiness is an active initiative on the roadmap — ahead of DORA, CNSA 2.0 and the EU PQC deadline. [Explore the quantum initiative →](https://xdc.network/labs/quantum/) [geth v1.17.3 modernization →](https://xdc.network/labs/modern-geth-migration/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC network tools and connection reference URL: https://xdc.network/labs/network/ Last reviewed: 2026-10-22 The Labs source collects chain identifiers, explorer links, RPC methods, testnet resources and snapshots. Listings do not guarantee endpoint availability. > The RPC console uses a fixed read-only method list. Requests are sent to the configured provider and may fail because of rate limits or connectivity. Wallet actions require your wallet’s approval. A sample RPC comparison is an observation of selected endpoints, not a complete consensus audit. Network & tools Connect to and observe XDC Network. Explorers, public RPC endpoints, the Apothem testnet and faucet, live client parity, and chaindata snapshots — the operational surface for everyone building on or running XDC. ### Network tools and endpoints 🔎 #### Block explorer Browse mainnet blocks, transactions, addresses and contracts on XDCScan. [Open XDCScan →](https://xdcscan.io) xdcscan.io 🔌 #### Public RPC & live status Live JSON-RPC endpoints across all six clients — block height, latency, score & privacy, with one-click Add to MetaMask for every XDC network. [Open RPC status →](https://xdc.network/labs/rpc/) xdc.network/rpc · mainnet 50 · Apothem 51 🧪 #### Apothem testnet The XDC test network (chain ID 51) — testnet explorer, RPC, and a free faucet for test XDC. [apothem.network →](https://apothem.network/) faucet.apothem.network · testnet.xdcscan.com ⚡ #### Live client parity Run JSON-RPC parity checks between the legacy and modern XDC clients live, in your browser — proof the network behaves consistently. [Open live compare →](https://xdc.network/labs/geth-compare/) xdc.network/geth-compare 📦 #### Chaindata snapshots Recent mainnet, Apothem & devnet chaindata snapshots in a live, sorted browser — skip the historical sync. [Browse snapshots →](https://xdc.network/labs/node/#snapshots) live browser · node hub 📈 #### Network stats Live network telemetry and node statistics for the XDC mainnet. [View stats →](https://stats.xdcindia.com/) stats.xdcindia.com Mainnet Chain ID **50**  (0x32) RPC: rpc.xinfin.network Explorer: xdcscan.io Apothem testnet Chain ID **51**  (0x33) RPC: rpc.apothem.network Explorer: testnet.xdcscan.com Try the RPC ### Query XDC mainnet, live — from your browser. Pick a read-only JSON-RPC method and fire it against the public mainnet endpoint. Read-only allowlist only — no keys, no writes, no signing. `` ``` // pick a method and press Send ``` Building on XDC? See the [developer hub](https://xdc.network/labs/developers/) for docs, client code and one-command node setup. ### Source RPC console methods Method | Parameters | eth_blockNumber | [] | eth_chainId | [] | eth_gasPrice | [] | net_version | [] | net_listening | [] | web3_clientVersion | [] | eth_getBlockByNumber (latest) | ["latest", false] | Use the manual [RPC checker](https://xdc.network/labs/geth-compare/) for a connectivity sample. The source console and live charts depend on external endpoints. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC node operations reference URL: https://xdc.network/labs/node/ Last reviewed: 2026-10-22 The Labs guide covers node sizing, snapshot restoration, endpoints and health checks. Review client compatibility, checksums and commands before operational use. > Live panels require working data connections and show one endpoint’s observations. Snapshot compatibility and checksums must be checked for the selected client and network. A download size is not a disk-capacity requirement. Restore examples are reference commands; review backups and the destination before extracting data. Node operator hub Everything your XDC node needs, in one place. Live network state, chaindata snapshots, RPC endpoints, explorers, hardware sizing and health checks — for validators, full-node operators and developers running XDC mainnet, Apothem or a devnet. Latest block — mainnet height Gas price — gwei Validators — XDPoS masternodes Peers — connected (this RPC) Epoch — XDPoS 2.0 Chain ID — mainnet Live via the public mainnet RPC (`rpc.xinfin.network`), read-only, refreshed every 12s. Falls back gracefully if the endpoint rate-limits. ### Resources ⚙️ #### Run a node One-command setup for a mainnet or Apothem full node — Docker or binary. [Setup guide →](https://xdc.network/labs/run/) 📦 #### Snapshots Skip the historical sync. Mainnet, Apothem & devnet chaindata, browsable below. Browse snapshots ↓ 🔌 #### RPC endpoints Public JSON-RPC for mainnet (50) and Apothem (51). Add to your wallet below. Endpoints ↓ 🔎 #### Block explorers Browse blocks, transactions, addresses and contracts on XDCScan. [Open XDCScan →](https://xdcscan.io) 🖥️ #### Hardware sizing Estimate disk, RAM and cost for the node type you intend to run. [Sizing calculator →](https://xdc.network/labs/hosting-calculator/) ⬇️ #### Client downloads Multi-client binaries & Docker images across three languages. [Downloads →](https://xdc.network/labs/downloads/) 📊 #### Network stats Live network telemetry and node statistics for XDC mainnet. [View stats →](https://stats.xdcindia.com/) 📚 #### Documentation Operator docs, JSON-RPC reference and architecture guides. [Read docs →](https://docs.xdc.network) ### RPC endpoints & chain IDs Connect a wallet, node or dApp. Every value is shown here — the buttons just save you the typing. Mainnet Chain ID **50**  (0x32) RPC: rpc.xinfin.network Backup: erpc.xinfin.network Explorer: xdcscan.io Apothem testnet Chain ID **51**  (0x33) RPC: rpc.apothem.network Faucet: faucet.apothem.network Explorer: testnet.xdcscan.com ### Chaindata snapshots A live, sorted view of the snapshot server — newest first. Restore from a recent snapshot instead of syncing from genesis. The `-latest` files always point at the freshest snapshot for that network and type. Snapshot reference — automatic loading is disabled Downloadable XDC chaindata snapshots by network, type, size and date Snapshot | Network | Type | Size | Updated | Get | Open the source snapshot directory for current files. The preserved index schema is described below. | Source: [xdc.network/snapshots/](https://xdc.network/snapshots/) — raw directory Restore — quick start `wget -c https://xdc.network/snapshots/xdc168-mainnet-fast-latest.tar.zst` `zstd -d --long=27 xdc168-mainnet-fast-latest.tar.zst -c | tar -xf - -C /path/to/XDC/chaindata` Helper scripts on the server: [install.sh](https://xdc.network/snapshots/install.sh) · [one.sh](https://xdc.network/snapshots/one.sh). Always verify the `.sha256` after download. Full setup: [/run](https://xdc.network/labs/run/). ### Health checks Confirm your node is live and in sync. These hit the read-only public RPC — swap in `http://localhost:8989` to check your own node. Latest block height `curl -s https://rpc.xinfin.network -X POST -H 'content-type: application/json' --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'` Sync status (false = fully synced) `curl -s https://rpc.xinfin.network -X POST -H 'content-type: application/json' --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'` Validator set & epoch (XDPoS) `curl -s https://rpc.xinfin.network -X POST -H 'content-type: application/json' --data '{"jsonrpc":"2.0","method":"XDPoS_networkInformation","params":[],"id":1}'` Connecting or observing the network rather than running it? See [Network & tools](https://xdc.network/labs/network/) for the in-browser RPC console and live client-parity checks. ### Snapshots and operational telemetry Source snapshot records are loaded from an external directory at runtime; they are not embedded repository content. Open the maintained catalogue for actual files, dates, sizes and checksum files. [Open snapshot catalogue ↗](https://xdc.network/snapshots/) Source interface | Fields / choices | Snapshot columns | Snapshot, Network, Type, Size, Updated, Download, Checksum | Snapshot filters | All, Mainnet, Apothem, Devnet, Latest only | Snapshot types | Erigon · full, Archive (path), Archive, Snap + full, Snap (PBSS), Fast, Full, Snap, Chaindata | Telemetry fields | Latest block, Gas price (gwei), Peers for the queried RPC, Chain ID, Validator count (response-dependent), Epoch (response-dependent) | The source sorts latest aliases before other files, then by size; that is not a reliable newest-first sort. Verify which checksum algorithm is supplied: a .md5 fallback is not SHA-256. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Q-Day: uncertainty and migration planning URL: https://xdc.network/labs/q-day-probability-not-date/ Last reviewed: 2026-10-22 A Labs article examines quantum-risk forecasts and long-lived records. It does not establish an attack date or a universal regulatory deadline for XDC. > Article dated 10 December 2025; reviewed 22 October 2026. Q-Day has no established date. EU and US guidance has specific scope and differing legal status; this article does not establish a binding deadline for XDC or all partners. Document-authenticity and confidentiality lifetimes require separate analysis. Post-quantum Dec 10, 2025 · By [Ritesh Kakkad](https://www.xdc.dev/riteshkakkad) · [← All posts](https://xdc.network/labs/blog/) Q-Day is a probability, not a date In one paragraph Q-Day has no established date. Migration planning can consider system lifetimes, the EU critical-infrastructure roadmap and NIST transition guidance. These sources have different scopes and statuses; they do not establish one binding deadline for XDC or all users. ### Why Q-Day has no date "Q-Day" is shorthand for the moment a cryptographically-relevant quantum computer (CRQC) can run Shor's algorithm at the scale needed to recover a private key from a public one. The honest answer to "when?" is that **nobody knows** — and anyone who gives you a single year is selling certainty that doesn't exist. What we have instead is a distribution of expert estimates that clusters in the early-to-mid 2030s and, crucially, **keeps shifting earlier** as the algorithms improve. The most-cited recent example: the estimated qubit count to factor RSA-2048 fell roughly 20× between 2019 and 2025 — a software result, not a hardware one. (We unpack that in [Reading the 2025 Gidney result](https://xdc.network/labs/reading-gidney-rsa-2048/).) Treating a moving probability as a fixed deadline is the trap. You can't build a migration plan around a date that doesn't exist — so you build it around the dates that do. ### The deadlines that are fixed While Q-Day floats, the readiness deadlines are concrete, regulatory, and already on the calendar: 2030 **EU post-quantum migration target** — the date XDC's regulated trade-finance partners are expected to be PQC-ready. Aligns with the NIST schedule to deprecate ECDSA by 2030. 2027 **CNSA 2.0** — the US NSA's timeline pushing national-security systems onto post-quantum algorithms, the leading edge of broader enterprise mandates. 2035 **NIST ECDSA sunset (IR 8547)** — the date classical elliptic-curve signatures are slated to be retired, not merely deprecated. ~2056 **Harvest-now-decrypt-later horizon** — a 30-year trade document signed today must stay unforgeable into the 2050s. The clock on it has already started. Notice that the last one isn't set by a regulator — it's set by your own data. A signed letter of credit can be contested in court decades after issuance, and the ECDSA signature is the proof. That makes document lifetime, not Q-Day, the binding constraint. ### Mosca's inequality Michele Mosca gave the quantum transition its planning rule, and it needs no precise Q-Day to be useful. If the time your data must stay secure (**X**) plus the time it takes to migrate (**Y**) is greater than the time until a CRQC arrives (**Z**), you are already late. For a trade-finance chain `X` (document lifetime, 20–30 yrs) `+ Y` (migration, 4–7 yrs) `> Z` (Q-Day, ~8–12 yrs out). X alone can exceed most Q-Day estimates — so the inequality is already breached for documents being signed right now. ### What XDC plans to Because the threat date is uncertain but the readiness dates are not, XDC's **XDSS-PQ** standard is built as a **hybrid** — classical ECDSA and NIST-selected post-quantum signatures coexist through the transition, with compatibility and verification behavior subject to implementation and testing. The roadmap is paced to the deadlines above (consensus migration targeted for 2030, the EU window), not to a guess about when a quantum computer will arrive. The full plan lives in the [technical deep-dive](https://xdc.network/labs/quantum-research/), the [XDSS-PQ specification](https://xdc.network/labs/xdss-pq-spec/), and the live [Q-Day countdown](https://xdc.network/labs/quantum/#qday). ### Frequently asked When is Q-Day? There is no fixed date. Q-Day is a probability distribution, not a calendar entry. Commonly-cited estimates land in the early-to-mid 2030s, but they are estimates that keep moving earlier as algorithms improve — not a scheduled event. If Q-Day has no date, what deadline should a blockchain plan to? Use the rules and transition guidance applicable to the specific organization and system, together with its confidentiality and authenticity requirements. The EU roadmap and draft NIST IR 8547 are planning references, not proof of a universal XDC deadline. What is Mosca's inequality? If the time your data must stay secure (X) plus the time to migrate (Y) exceeds the time until a quantum computer arrives (Z), you are already late. For 30-year trade documents, X alone can exceed most Q-Day estimates, which is why migration must begin before any working attack exists. ### Sources - NIST Post-Quantum Cryptography — FIPS 203/204 and the IR 8547 transition timeline (deprecate ECDSA 2030, retire 2035). [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - Gidney, C. "How to factor 2048-bit RSA integers with less than a million noisy qubits." 2025 — the falling-estimate trajectory. [arxiv.org/abs/2505.15917](https://arxiv.org/abs/2505.15917) - XDC — [Quantum threats to XDC](https://xdc.network/labs/quantum-research/) (CRQC timeline, Mosca's theorem, harvest-now-decrypt-later) and the [live Q-Day countdown](https://xdc.network/labs/quantum/#qday). RK Ritesh Kakkad Co-founder, XDC Network · writes on post-quantum security and trade finance ### Related reading [Research Reading the 2025 Gidney result](https://xdc.network/labs/reading-gidney-rsa-2048/) [Deep-dive Quantum threats to XDC](https://xdc.network/labs/quantum-research/) [Spec XDSS-PQ signature standard](https://xdc.network/labs/xdss-pq-spec/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Post-quantum research: the Labs FAQ URL: https://xdc.network/labs/quantum-faq/ Last reviewed: 2026-10-22 Read the Labs answers on quantum threats and proposed migration paths. Wallet behavior, phase dates and upgrade capabilities remain source proposals. > June 2026 source FAQ, reviewed 22 October 2026. Its five-phase 2026–2035 plan conflicts with the four-phase roadmap elsewhere. Wallet, seed, gas and upgrade statements are proposals, not released capabilities or asset-safety guarantees. Some regulatory and algorithm examples below require the listed corrections. [PQ Initiative](https://xdc.network/labs/overview/) / FAQ Quantum-first EVM chain · the initiative, in plain language Frequently Asked Questions: Post-Quantum Blockchain Security Everything you need to know about quantum computing threats to XDC Network, the post-quantum migration roadmap, NIST cryptography standards, and what the quantum-first initiative means for your tokens, dApps, and enterprise integrations. Last updated: June 2026 · 25 questions answered ### Frequently asked questions Quantum Computing Basics #### What is quantum computing? + Quantum computing leverages quantum mechanics principles (superposition and entanglement) to perform certain computations exponentially faster than classical computers. While classical bits are either 0 or 1, quantum bits (qubits) can exist in multiple states simultaneously, enabling massive parallelism for specific problem classes. **Key point:** Quantum computers aren't faster at everything — they excel at specific tasks like factoring large numbers (breaking RSA/ECDSA) and searching unstructured databases (weakening hash functions). Most everyday computing (video rendering, database queries, web browsing) sees little-to-no quantum advantage. #### Is XDC vulnerable to quantum attacks today? + **Not yet.** Breaking XDC's ECDSA (secp256k1) requires ~4,000+ logical qubits running Shor's algorithm. Today's quantum computers (IBM Condor: 1,121 qubits, Google Willow: 105 qubits) are still in the NISQ (Noisy Intermediate-Scale Quantum) era — physical qubits with high error rates, not the error-corrected logical qubits needed for cryptographic attacks. However, **"harvest now, decrypt later"** is the real threat: adversaries can capture encrypted trade finance documents today and decrypt them when quantum computers mature in 8-12 years. Since XDC trade documents have 20-30 year legal lifespans, starting the migration now is critical. #### When will quantum computers actually break ECDSA? + Most credible timelines converge on the **early-to-mid 2030s**: - **IBM (2033):** 100,000+ qubit system on their roadmap - **DARPA (2033):** CRQC (Cryptographically Relevant Quantum Computer) benchmark target - **Global Risk Institute (2031):** 1 in 7 chance; 50% chance by 2037 - **NIST (2035-2040):** Conservative estimate for RSA-2048 breaking The critical insight: **lead time matters more than threat date**. Migrating a decentralized network like XDC takes 7-10 years (multi-client coordination, wallet updates, enterprise integration testing). Starting in 2026 means being ready by 2033-2035 — right when the threat materializes. Cryptographic Threats #### What is ECDSA and why is it vulnerable? + **ECDSA (Elliptic Curve Digital Signature Algorithm)** is the cryptographic scheme XDC uses to sign transactions. Your private key generates signatures proving you own an address without revealing the key itself. XDC uses the `secp256k1` curve (same as Bitcoin/Ethereum). **Why it's quantum-vulnerable:** Shor's algorithm can solve the Discrete Logarithm Problem (DLP) — the mathematical foundation of ECDSA — in polynomial time. A sufficiently powerful quantum computer can derive your private key from your public key, allowing attackers to forge signatures and steal funds. **Attack requirement:** ~4,000 logical qubits with low error rates. Classical computers would need billions of years; a quantum computer could do it in hours. #### What about hash functions like Keccak-256? Are those safe? + **Mostly safe, but weakened.** Grover's algorithm provides a quadratic speedup for searching unstructured data, reducing the effective security of a 256-bit hash from 256 bits to ~128 bits. This is still computationally infeasible with current tech (would require trillions of qubits). **Practical impact on XDC:** - **Keccak-256 (used for addresses):** Still secure — 128-bit post-quantum strength is adequate - **SHA-3 (used in state trees):** Similarly weakened but acceptable - **Mining/Ethash:** Not applicable (XDC uses XDPoS, not PoW) **Bottom line:** Hash functions aren't the urgent threat — signature schemes are. That's why XDC's migration focuses on replacing ECDSA with ML-DSA/Falcon, not upgrading hash functions. #### What is the "harvest now, decrypt later" threat? + Nation-states and sophisticated adversaries are capturing encrypted communications and blockchain transactions today, storing them in massive data warehouses, and planning to decrypt them when quantum computers mature in 8-15 years. **Why this matters for XDC:** - **Trade finance documents** have 20-30 year legal validity periods - **Bills of lading** signed on-chain today may be referenced in 2045 litigation - **Enterprise contracts** often include confidential pricing/terms Future quantum capabilities could undermine exposed classical signing keys and the confidentiality of recorded encrypted traffic. That does not by itself rewrite finalized blockchain history. The claim about yottabytes of stored traffic is not substantiated by the cited sources. Post-Quantum Cryptography #### What is post-quantum cryptography? + Post-quantum cryptography (PQC) consists of algorithms designed to resist attacks from both classical and quantum computers. Unlike quantum key distribution (QKD), which requires specialized hardware, PQC runs on regular computers and blockchains. NIST finalized ML-KEM, ML-DSA and SLH-DSA in August 2024. Falcon was selected separately; FIPS 206 remains in development as reviewed on 22 October 2026. - **ML-KEM (FIPS 203):** Key encapsulation (replacing ECDH for encryption) - **ML-DSA (FIPS 204):** Digital signatures based on lattices (Dilithium) - **SLH-DSA (FIPS 205):** Stateless hash-based signatures (SPHINCS+) - Falcon / FN-DSA: compact signatures selected by NIST; FIPS 206 remains in development. XDC's strategy uses **ML-DSA for user wallets** (widely compatible) and **Falcon for validator consensus** (smallest signatures for 108-node gossip). #### Why did NIST choose these specific algorithms? + NIST ran an 8-year competition (2016-2024) evaluating 82 candidate algorithms across three rounds. The winners balance **security, performance, and mathematical diversity**: - **ML-DSA/ML-KEM (lattice-based):** Fast, small keys, well-studied — the "workhorse" algorithms - **SLH-DSA (hash-based):** Most conservative cryptographic assumptions — the "fallback" if lattices break - **Falcon (NTRU lattice):** Smallest signatures — critical for real-time systems like blockchain consensus **Mathematical diversity matters:** If a breakthrough attack breaks lattice-based schemes, hash-based SLH-DSA provides a backup. This is why XDC uses both ML-DSA and Falcon in different contexts. #### How much bigger are post-quantum signatures compared to ECDSA? + Scheme | Signature Size | vs ECDSA | ECDSA (secp256k1) | 65 bytes | baseline | Falcon-512 (FIPS 206) | 666 bytes | 10.2× | ML-DSA-65 (FIPS 204) | 3,309 bytes | 50.9× | SLH-DSA-128s (FIPS 205) | 7,856 bytes | 120.9× | **Why this matters:** XDPoS 2.0 validators must gossip 108 signatures per block. Using the table's ML-DSA-65 parameter set gives about 5× the 666-byte Falcon size and about 51× a 65-byte ECDSA signature. These are size comparisons, not measured whole-network overhead. Falcon keeps bandwidth manageable while providing quantum resistance. XDC's PQ Strategy #### What is XDC doing about quantum threats? + XDC Network is implementing a **5-phase post-quantum migration** over 2026-2035, co-led by Ritesh Kakkad (XDC Core) and the XDC Innovation Labs team: - **Phase 0 (2026 Q2):** Research + XDSS-PQ standard with ITFA/ICC - **Phase 1 (2027):** Hybrid wallets (ECDSA + ML-DSA dual-signing) - **Phase 2 (2028-2029):** Smart contract PQ support via EVM precompiles - **Phase 3 (2030-2031):** XDPoS 2.0 validator Falcon migration - **Phase 4 (2032-2035):** Full PQ-only mode (ECDSA deprecated) Key design principle: **No flag-day cutover**. Every phase uses hybrid approaches where classical and PQ crypto coexist, giving users and validators time to upgrade at their own pace. This is an initiative and a multi-year roadmap, not a claim that XDC is already quantum-proof. Read the foundational community research by Ritesh Kakkad: ["XDC Network's Unbreakable Future" (quantum-proof blockchain research)](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9). #### Will my XDC tokens be safe during the migration? + The proposed migration aims to preserve access, but safety and compatibility depend on implementation, review and adoption. The following phases are plans rather than guarantees: - **Phase 1-2:** Wallets sign transactions with both ECDSA and ML-DSA. Older nodes verify ECDSA; upgraded nodes verify both. - **Phase 3:** Validators dual-sign blocks with Falcon + ECDSA during a 12-month transition window - **Phase 4:** Only after >95% network upgrade does ECDSA get deprecated Wallet migration remains proposed. Follow reviewed wallet releases and network activation guidance; automatic key generation, address continuity and seed compatibility have not been established by this article. **If you don't upgrade?** Your ECDSA transactions continue working through Phase 3 (~2031), giving you 4+ years to migrate. But quantum-resistant security requires the upgrade. #### What is XDSS-PQ and why does it matter? + XDSS-PQ is an XDC Innovation Labs draft for post-quantum trade-document signatures. The reviewed source does not establish formal co-authorship or endorsement by ITFA, ICC or TradeTrust. **What it specifies:** - Dual ML-DSA + Falcon signature schema for 30-year document validity - Metadata standards (originator, timestamp, jurisdiction, legal validity assertions) - EU 2030 Digital Identity Wallet compliance + NIST FIPS 203/204/206 alignment - Backward compatibility with existing MLETR (Model Law on Electronic Transferable Records) **Strategic moat:** By making XDC the reference implementation of XDSS-PQ, it creates a network effect no competitor can easily replicate. Banks/enterprises adopting the standard automatically favor XDC — similar to how SWIFT messaging standards locked in correspondent banking. #### Why Falcon for validators instead of ML-DSA? + **Bandwidth.** XDPoS 2.0 has 108 masternodes signing every block, and those signatures must be gossiped to all other validators in real-time (2-second block time). - **Falcon-512:** 666 bytes/signature → 72 KB per block - **ML-DSA-65:** 3,309 bytes/signature → 357 KB per block At 30 blocks/minute, ML-DSA would add **10.7 MB/min** gossip overhead vs Falcon's **2.2 MB/min** — a 5× difference that compounds across 108 globally distributed nodes. **Real-world precedent:** Polkadot chose Falcon (June 2025) for identical reasons. Ethereum's J* fork is evaluating Falcon for validator signatures in their PQ roadmap. XDC is following proven technical decisions, not inventing untested approaches. #### Will the PQ migration disrupt dApps or smart contracts? + Compatibility must be tested. Smart contracts can verify signatures themselves, and wallets, account-abstraction systems and applications may depend on particular signing formats. The proposed migration does not establish that every contract will work unchanged. **Phase 2 additions (2028-2029):** - New EVM precompiles for ML-DSA/Falcon signature verification (similar to `ecrecover` for ECDSA) - Optional: Smart contracts can add PQ signature checks for enhanced security - Example: A trade finance dApp verifying bill of lading signatures could use `mldsaRecover()` precompile **Developer action:** If your dApp needs to verify signatures on-chain (beyond basic transaction auth), you'll want to add PQ signature support when precompiles launch. Otherwise, no code changes required. Comparisons & Ecosystem #### What are other blockchains doing about quantum threats? + **Most are still in early research.** XDC's 5-phase roadmap (starting 2026) puts it among the leaders: - **Ethereum:** J* fork research (2024-2026) exploring Falcon + STARK aggregation. No firm timeline yet. - **Bitcoin:** Taproot soft fork (2021) added Schnorr, but PQ migration blocked by governance deadlock. Some proposals for pay-to-quantum-resistant (P2QR) addresses. - **Algorand:** FALCON/SPHINCS+ research (2023), state proof aggregation. Timeline unclear. - **Polkadot:** Falcon signatures for validators (June 2025 implementation). Most concrete progress after XDC. - **QRL (Quantum Resistant Ledger):** Built PQ-native from day 1 (XMSS signatures), but low adoption/liquidity. **XDC's advantage:** Its trade-finance focus sits squarely under regulatory pressure (DORA, EU Digital Identity mandates) that consumer chains don't face. This urgency accelerates XDC's PQ timeline. #### Why is XDC's risk higher than Ethereum or Bitcoin? + **Two institutional factors unique to XDC:** - **30-year document lifespans:** Trade finance bills of lading have multi-decade legal validity. A document signed in 2026 may be cited in 2050 litigation. Ethereum NFTs or Bitcoin payments don't have this long-term legal requirement. - **Regulatory compliance:** Regulated trade-finance use of XDC must reckon with: - **EU DORA (Digital Operational Resilience Act):** Mandatory PQ risk assessments by 2025 - **EU Digital Identity Wallet (2030):** Requires PQ-compliant signatures - NIST SP 800-208 specifies stateful hash-based signature schemes. It is not a general 2035 migration mandate. If XDC isn't PQ-safe by 2030-2033, it risks becoming a **compliance liability** for the regulated trade-finance institutions it targets — undermining its enterprise value proposition. Bitcoin/Ethereum don't face this deadline pressure. #### How does XDC benefit from Ethereum's PQ research? + **Directly, via EVM compatibility.** Ethereum's open-source PQ toolchain ports to XDC with minimal changes: - **leanSig:** Compact PQ signature serialization (reducing ML-DSA overhead) - **leanSpec:** Formal verification framework for PQ precompiles - **leanMultisig:** PQ-safe multi-signature wallets - **STARK aggregation:** Batching validator signatures to reduce on-chain data The XDC PQ team tracks and builds on the Ethereum Foundation's open PQ research (pq.ethereum.org), adapting it to trade-finance use cases rather than duplicating base-layer cryptography work. **Cost savings:** Because the toolchain is open-source, XDC can reuse Ethereum's PQ engineering rather than reinventing base-layer crypto — focusing its own effort on trade-finance-specific features (XDSS-PQ, document signing). Technical Details #### What are "logical qubits" vs "physical qubits"? + **Physical qubits:** The actual quantum hardware — superconducting circuits, ion traps, etc. They have high error rates (0.1-1% per operation) due to decoherence and environmental noise. **Logical qubits:** Error-corrected qubits created by redundantly encoding information across many physical qubits. Quantum error correction (QEC) codes like surface codes require ~1,000 physical qubits per logical qubit to achieve fault-tolerant computation. **Breaking ECDSA requirement:** - ~4,000 logical qubits running Shor's algorithm - Translates to ~4,000,000 physical qubits (assuming 1,000:1 overhead) **Where we are today (2026):** IBM Condor has 1,121 physical qubits; Google Willow has 105. Both are NISQ devices — not error-corrected. The gap between current tech and cryptographic threat is still wide, but narrowing fast. #### Can I use my existing seed phrase after the PQ migration? + Seed compatibility is a design question for future wallet implementations, not a verified capability of the current XDC network. - Your 12/24-word seed phrase derives both ECDSA and ML-DSA key pairs - Derivation path: `m/44'/550'/0'/0/x` for ECDSA (XDC standard) + `m/44'/550'/1'/0/x` for ML-DSA - One seed phrase → dual-signature security Keep existing wallet backups secure. A future post-quantum wallet must publish and test its derivation and recovery rules before seed compatibility can be relied upon. **Hardware wallet support:** Ledger/Trezor firmware updates will add ML-DSA signing. Your Ledger device stores both key types, signed by the same seed. #### What is the performance impact of PQ signatures on transaction throughput? + **Minimal for XDC's architecture.** Unlike proof-of-work chains where signature verification is compute-heavy, XDPoS 2.0's bottleneck is network gossip and state database I/O, not signature validation. **Benchmarks (single-core):** - **ECDSA (secp256k1):** ~20,000 verifications/sec - **Falcon-512:** ~9,000 verifications/sec (~2× slower) - **ML-DSA-65:** ~4,800 verifications/sec (~4× slower) **Impact on XDC:** At 2,000 TPS (XDC's current capacity), signature verification takes <1% of CPU time on modern hardware. Even a 4× slowdown is negligible. The real bottleneck remains state trie updates and network latency — unchanged by PQ crypto. **Future optimization:** AVX2/AVX-512 SIMD instructions for ML-DSA can restore near-ECDSA speeds on server-grade hardware (Intel Xeon, AMD EPYC) used by masternodes. Ecosystem & Adoption #### When should enterprise users start preparing? + **Now — especially if you're in regulated industries.** **2026-2027 (Phase 0-1):** - Audit your XDC integrations: which systems sign/verify transactions? - Test hybrid wallet software in staging environments - Update internal security policies to reference NIST FIPS 203/204/206 - If you issue/verify trade documents: join XDSS-PQ working group **2028-2030 (Phase 2-3):** - Upgrade production wallets to PQ-enabled versions - If running masternodes: prepare for Falcon validator key migration - Update smart contracts to use PQ signature precompiles (optional) Organizations should assess the rules applicable to their own systems. This article does not establish a DORA-specific requirement for post-quantum risk assessments by January 2025 or demonstrate XDC compliance. #### Will PQ wallets work with current XDC dApps? + **Yes — during the hybrid phase (2027-2032).** PQ wallets dual-sign transactions with both ECDSA and ML-DSA. DApps that only verify ECDSA (i.e., current MetaMask/Web3 integrations) continue working normally. **What dApp developers should do:** - **Short-term (2027-2029):** Nothing required — ECDSA signatures remain valid - **Medium-term (2029-2031):** Add PQ signature verification if your dApp stores/validates signatures on-chain (using new precompiles) - **Long-term (2032+):** Migrate to PQ-only signatures when ECDSA gets deprecated **Wallet UX:** Users won't see "two signatures" — the wallet handles dual-signing transparently. Gas costs increase slightly (~15-20%) due to larger transaction payloads, but this is marginal. #### What happens if a PQ algorithm gets broken before quantum computers arrive? + **This is why NIST mandated mathematical diversity.** XDC's strategy uses multiple PQ schemes: - **ML-DSA (lattice-based):** User wallets - **Falcon (NTRU lattice):** Validator consensus - **SLH-DSA (hash-based):** Emergency fallback (standardized but not deployed yet) **Scenario: Lattice-based crypto gets broken (unlikely but possible)** - XDC activates SLH-DSA via emergency hard fork (hash functions are quantum-resistant and well-understood) - Validators roll back to ECDSA temporarily while SLH-DSA integrates - Community chooses next-gen PQ algorithm from NIST's Round 4 candidates **Historical precedent:** When SHA-1 was broken (2017), systems migrated to SHA-256/SHA-3 without catastrophic failure. XDC's hybrid approach ensures similar resilience. #### How much will PQ transactions cost in gas fees? + **~15-25% higher during hybrid phase; target neutral by Phase 4.** **Gas cost breakdown:** - **Larger transaction payload:** ECDSA signature = 65 bytes; ML-DSA = 3,309 bytes → ~50× calldata cost increase - **Signature verification:** EVM precompiles are optimized, so verification cost comparable to `ecrecover` - **Total impact:** Simple transfer today ~21,000 gas → hybrid transfer ~25,000 gas **Mitigation strategies (Phase 2+):** - **STARK aggregation:** Batch multiple PQ signatures into a single proof (reduces per-tx overhead) - **EIP-4844-style blobs:** Store PQ signatures in cheaper data availability layer - ML-DSA-44 and ML-DSA-65 use different parameter sets and signature sizes. Their 2,420-byte and 3,309-byte signatures are not a demonstrated compression transformation. By Phase 4 (2032+), when ECDSA is deprecated and optimizations mature, PQ transaction costs should match today's ECDSA baseline. #### Where can I learn more or contribute to XDC's PQ initiative? + **Official resources:** - **Technical roadmap:** [Quantum-Safe Migration Roadmap](https://xdc.network/labs/quantum-roadmap/) - **Research deep-dive:** [Quantum Threats to XDC — Technical Deep-Dive](https://xdc.network/labs/quantum-research/) - **Ritesh Kakkad's research paper:** ["XDC Network's Unbreakable Future" — quantum-proof blockchain research](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9) - **GitHub (coming soon):** github.com/XDCIndia/xdc-pq-migration **Get involved:** - **Developers:** Join #pq-dev channel on XDC Discord - **Enterprises:** Contact XDC Innovation Labs for XDSS-PQ working group - **Researchers:** Contribute to leanEthereum PQ tooling (pq.ethereum.org) - **Validators:** Test Falcon signing in Phase 3 testnets (2030 launch) **Community calls:** Monthly PQ initiative updates — subscribe at xdcindia.com/newsletter ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Quantum threats to XDC: a research reference URL: https://xdc.network/labs/quantum-research/ Last reviewed: 2026-10-22 The Labs technical article discusses signature, hash, network and document risks. Forecasts and proposed defenses require evidence specific to each cryptographic surface. > June 2026 analysis, reviewed 22 October 2026. Treat hardware forecasts and migration dates as estimates. RSA-factoring estimates are not ECDSA attack measurements. Corrected standards, parameter-size and hybrid-verification statements should take precedence over the original source wording. [PQ Initiative](https://xdc.network/labs/overview/) / Technical Research Quantum-first EVM chain · threat model behind the roadmap Quantum Threats to XDC: A Technical Deep-Dive A comprehensive analysis of how quantum computing threatens XDC Network's cryptographic infrastructure, what the published research actually says, and the concrete migration path that makes XDC a quantum-first EVM chain by 2030. Last updated: June 2026 · Reading time: ~18 min // in brief **Is XDC quantum-safe today?** XDC's transaction and trade-document signatures use **secp256k1 ECDSA**, which Shor's algorithm will break once a cryptographically-relevant quantum computer exists — estimates cluster in the early-to-mid 2030s and keep moving earlier. XDC's **hash-based components (Keccak-256 addresses, state roots) stay secure**. The fix is **XDSS-PQ**: a hybrid that adds NIST-selected post-quantum signatures (ML-DSA / FIPS 204, Falcon) alongside ECDSA, with consensus migration targeted for 2030. // 01 · background ### The Quantum Computing Landscape in 2026 Quantum computing has progressed from theoretical curiosity to engineering reality. Understanding the current state is critical for assessing the urgency of XDC's post-quantum migration. #### Current Quantum Hardware Milestones Milestone | Organization | Date | Significance | Willow — 105 qubits | Google Quantum AI | Dec 2024 | Below-threshold error correction demonstrated for first time | Condor — 1,121 qubits | IBM | Dec 2023 | Largest gate-based quantum processor; followed by Heron (133q, lower error) | Atom Computing — 1,225 qubits | Atom Computing | Oct 2023 | Neutral atom platform; high connectivity | 200 logical qubits target | IBM Quantum | 2029 target | IBM Starling roadmap; a planned system, not a demonstrated cryptographic attack | DARPA CRQC benchmark | DARPA | ~2033 | Most cited objective estimate for cryptographically relevant QC | [1] IBM Quantum Development Roadmap, 2024. [ibm.com/quantum/roadmap](https://www.ibm.com/quantum/roadmap) #### 🔬 Google Quantum AI — falling resource estimates The headline trend isn't new hardware — it's that the estimated cost of breaking public-key cryptography keeps dropping as the algorithms improve. The most-cited recent result is from Google Quantum AI researcher Craig Gidney: - A 2025 preprint argues a fault-tolerant machine could factor a 2048-bit RSA key with under one million noisy qubits, given several days of continuous operation. - That is roughly a 20× reduction in the estimated qubit count versus Gidney's own widely-cited 2019 figure (~20 million qubits) for the same task — driven by algorithmic and error-correction improvements, not a hardware leap. - Important caveat: this is a resource estimate, not a demonstrated attack. No machine today comes close to the requirements (millions of high-quality qubits running error-free for days). RSA-2048 and the secp256k1 ECDSA used by XDC (and Bitcoin and Ethereum) both rest on problems Shor's algorithm solves, so estimates that fall for one class are a leading indicator for the other. The direction of travel — estimates shrinking year over year — is exactly why a hybrid migration should begin well before any working attack exists. [2] Gidney, C. "How to factor 2048-bit RSA integers with less than a million noisy qubits." Google Quantum AI, 2025 (preprint). [arxiv.org/abs/2505.15917 →](https://arxiv.org/abs/2505.15917) [3] Gidney, C. & Ekerå, M. "How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits." Quantum, 2021 — the earlier baseline the 2025 estimate improves on. [arxiv.org/abs/1905.09749 →](https://arxiv.org/abs/1905.09749) **Key takeaway:** The point is the trajectory, not a single number. Published estimates for breaking RSA- and ECC-class public-key cryptography have fallen sharply — roughly an order of magnitude in a few years — which pulls the planning horizon forward even though no cryptographically-relevant quantum computer exists yet. XDC's hash-based components (Keccak-256 addresses, state roots) remain quantum-safe; the exposed surface is ECDSA. // 02 · xdc-specific threats ### How Quantum Computers Attack XDC Two quantum algorithms pose distinct threats to different layers of XDC's cryptographic stack. #### Shor's Algorithm — The Existential Threat Shor's algorithm solves the Elliptic Curve Discrete Logarithm Problem (ECDLP) in polynomial time. For XDC's secp256k1 curve, this means: XDC Surface | Attack Type | Severity | Time Window | ECDSA transaction signatures | Private key recovery from public key | Critical | Real-time once CRQC exists | Validator masternode keys | Forge block signatures, control consensus | Critical | Real-time | Trade document signatures | Trust-Now-Forge-Later (TNFL) | Critical | 20–30 year exposure | Bridge multisig keys | Forge bridge transfers | Critical | Real-time | ECDH key exchange (TLS) | Harvest-Now-Decrypt-Later | High | Active today | Mathematical complexity: Classical ECDLP requires O(√n) = O(2128) operations for 256-bit curves. Shor's algorithm reduces this to O((log n)3) — exponentially faster. Published resource estimates for the number of error-corrected qubits required have fallen substantially in recent years, though all remain far beyond today's hardware. #### Grover's Algorithm — Reduced but Not Broken Grover's algorithm provides a quadratic speedup for unstructured search problems, which affects hash functions: Hash Function | Classical Security | Post-Quantum Security | Status | Keccak-256 (XDC addresses) | 2256 | 2128 | Safe — 128-bit security sufficient | SHA-256 (used in some contexts) | 2256 | 2128 | Safe — 128-bit security sufficient | RIPEMD-160 (not used by XDC) | 2160 | 280 | Marginal — XDC unaffected | Conclusion: XDC's hash-based components (addresses, Merkle trees, state roots) are quantum-safe. No migration needed for Keccak-256. 📚 XDC Community Research Foundation ##### Ritesh Kakkad's Quantum-Proof Blockchain Research The XDC community's quantum readiness journey began with Ritesh Kakkad's seminal article on xdc.dev, which identified the key threat vectors and proposed a comprehensive defense framework. His research highlighted seven critical areas: - Quantum-resistant cryptography — adopting post-quantum algorithms for signatures and encryption - Network security protocol hardening — quantum-safe key exchange for all communications - Consensus mechanism resilience — protecting XDPoS against quantum-capable adversaries - Quantum Key Distribution (QKD) — physics-based key distribution for highest-value links - Continuous threat assessment — ongoing monitoring and risk management - Industry collaboration — engaging with academic and standardization bodies - Regular security audits — staying ahead with proactive cryptographic reviews This research informed the published XDC post-quantum proposal. Formal co-authorship or endorsement by ITFA or ICC is not established by the reviewed draft. Deloitte's research, cited in the article, reveals that hundreds of billions in cryptocurrency are held in addresses with exposed public keys — vulnerable to quantum storage attacks. [4] Kakkad, R. "XDC Network's Unbreakable Future: Exploring area of Quantum-Proof Blockchain Research." xdc.dev, 2024. [xdc.dev/riteshkakkad →](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9) [5] Deloitte. "Quantum computers and the Bitcoin blockchain." [deloitte.com →](https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html) // 03 · unique risk profile ### Why XDC's Quantum Risk Exceeds Other Chains #### The Trade Finance Longevity Problem Most blockchain transactions have immediate finality — the signature is verified once and then it's done. XDC's trade finance use case is fundamentally different: - A bill of lading signed on XDC in 2026 remains legally referenced until 2056 - A letter of credit may be contested in court decades after issuance — the ECDSA signature is the proof - RWA tokens representing real estate, commodities, or bonds have lifespans measured in decades This creates the Trust-Now-Forge-Later (TNFL) attack: an adversary doesn't need a quantum computer today — they just need the signed document. When CRQCs arrive in the 2030s, every ECDSA-signed trade document on XDC becomes forgeable. #### Institutional Compliance Liability XDC's partners face active regulatory mandates that create compliance liability if XDC's cryptography isn't quantum-safe: Regulation | Jurisdiction | Deadline | Impact on XDC | DORA | EU | Jan 2025 (active) | Banks must demonstrate robust cryptographic controls | CNSA 2.0 | US (NSA) | Jan 2027 | NSS acquisitions must be PQC compliant | EU PQC Roadmap | EU | Dec 2030 | Full PQC migration for all critical infrastructure | NIST IR 8547 | US (NIST) | 2035 | All quantum-vulnerable algorithms deprecated | // 04 · nist post-quantum standards ### The NIST PQC Standards — XDC's Foundation NIST finalized FIPS 203, 204 and 205 in August 2024. As reviewed on 22 October 2026, its status page still lists Falcon-based FIPS 206 as in development. #### FIPS 203 — ML-KEM (Kyber): Key Encapsulation XDC use: P2P and RPC TLS encryption for all 108 masternodes - **Type:** Lattice-based (Module Learning With Errors) - **Security level:** ML-KEM-768 ≈ AES-192 equivalent - **Key size:** 1,184 bytes (public), 2,400 bytes (private) - **Ciphertext:** 1,088 bytes - **Already deployed:** Google Chrome v131, Cloudflare, AWS, Apple iMessage PQ3 - **Overhead:** <5% on high-bandwidth links; drop-in replacement for ECDH #### FIPS 204 — ML-DSA (Dilithium): Digital Signatures XDC use: EOA wallet signing, XDSS-PQ trade documents (dual hybrid) - **Type:** Lattice-based (Module Learning With Errors) - Signature size: 3,309 bytes for ML-DSA-65; 2,420 bytes belongs to ML-DSA-44. - **Public key:** 1,952 bytes - **Co-developed by:** IBM Research (Vadim Lyubashevsky et al.) - Deployment context: Signal PQXDH provides post-quantum key agreement. It is not evidence that ML-DSA signatures are deployed in that protocol. - **Primary NIST standard** — most audited PQ signature scheme #### FIPS 205 — SLH-DSA (SPHINCS+): Hash-Based Signatures XDC use: DAO and bridge governance operations - **Type:** Hash-based (stateless) - **Signature size:** 7,856 – 49,856 bytes (depending on parameter set) - **Security basis:** SHA-256 only — most conservative foundation - **Advantage:** No lattice assumptions; security relies only on hash function collision resistance - **Use case:** Rare, high-value operations where size is acceptable - **Recommended by:** UK NCSC for software signing #### Falcon / FN-DSA: Compact Signatures (FIPS 206 in development) XDC use: XDPoS 2.0 validator block signing (the critical choice) - **Type:** Lattice-based (NTRU) - **Signature size:** 666 bytes — most compact NIST PQ signature - **Public key:** 897 bytes - **Why for validators:** XDPoS 2.0 has 108 nodes signing every block; signatures are gossiped network-wide. ML-DSA's 2.4 KB would increase gossip overhead by ~3.6×; Falcon's 666B keeps it manageable - **Also being evaluated by:** Polkadot for validator keys (similar bandwidth constraints) - **Status:** Expected NIST finalization 2025 // 05 · industry comparison ### What Other Blockchains Are Doing A comparison of quantum readiness across major blockchain networks. ETH Ethereum In Progress Lean Consensus: Complete redesign of consensus layer with hash-based signatures (leanSig, leanMultisig). XMSS + STARK aggregation. Formal verification with Lean 4. Vitalik's quantum emergency hard-fork plan. EIP-7702 account abstraction. leanSig · XMSS · STARK aggregation · ~2028–2030 QRL Quantum Resistant Ledger Live Purpose-built PQ blockchain using XMSS (eXtended Merkle Signature Scheme) from launch. Hash-based signatures only. Stateful — requires careful key management. XMSS · hash-based · live since 2018 DOT Polkadot Roadmap Falcon chosen for validator keys (June 2025 roadmap). Same bandwidth reasoning as XDC — many validators, frequent signing. Substrate framework allows modular crypto swaps. Falcon · validator keys · 2025 roadmap ALGO Algorand Research Explored Falcon signatures during NIST Round 3. State proofs already use Falcon-like compact signatures. Research into lattice-based schemes for consensus. Falcon · state proofs · research phase BTC Bitcoin No Plan No formal PQ migration plan. ~25% of BTC in addresses with exposed public keys (per Deloitte). Satoshi's coins (~1.1M BTC) use pay-to-public-key (P2PK) — maximally exposed. Any migration requires hard fork and community consensus. No plan · ~25% exposed · hard fork needed XDC XDC Network Phase 0 Active Most comprehensive enterprise PQ plan: Falcon validators, ML-DSA wallets, XDSS-PQ hybrid for trade docs, SLH-DSA governance, ML-KEM TLS, STARK aggregation. 4-phase roadmap targeting EU 2030. ~0.1% pubkey exposure (vs BTC 25%). Full stack · XDSS-PQ · EU 2030 · Phase 0 active // 06 · crqc timeline estimates ### When Will Quantum Computers Break ECDSA? #### Estimated Timeline for Cryptographically Relevant Quantum Computers Source | Estimate | Confidence | Notes | Google Quantum AI (Gidney, 2025) | resource estimate | High-profile | RSA-2048 in <1M noisy qubits over several days; ~20× fewer qubits than the 2019 baseline | IBM Quantum Roadmap | ~2030–2035 | Medium-High | Targets 200 logical qubits for Starling in 2029 and 2,000 for Blue Jay in 2033+; these are roadmap targets | DARPA Benchmark | ~2033 | Most cited | Independent US defense assessment | NIST IR 8547 | 2035 (deprecation) | Standard | All quantum-vulnerable algorithms deprecated by this date | Mosca's Theorem | Start NOW | Critical | If migration time (T) + data lifetime (L) > time to CRQC (Q), you're already late | **Mosca's Theorem applied to XDC:** Migration time (T) = 4–7 years · Trade doc lifetime (L) = 20–30 years · Time to CRQC (Q) = ~8–12 years T + L = 24–37 years >> Q = 8–12 years — XDC is already in the danger zone. Migration should have started yesterday. // 07 · active threats today ### Harvest-Now-Decrypt-Later: A Present Danger #### HNDL Attacks Are Happening Now Nation-state actors are already recording encrypted communications for future decryption. This affects XDC in two ways: - P2P traffic: Masternode gossip, block propagation, and transaction relay are encrypted with classical ECDH. This traffic is being recorded by sophisticated adversaries today. - Trade document metadata: Even if the document itself is on-chain, the negotiation traffic around it (counterparty communications, draft versions) may contain commercially sensitive information. This is why Phase 1 (PQ-TLS) of XDC's roadmap is prioritized — it addresses the only quantum threat that is active today, not just a future risk. [6] Google Security Blog. "Post-Quantum Cryptography Standards." Aug 2024. [security.googleblog.com →](https://security.googleblog.com/2024/08/post-quantum-cryptography-standards.html) // 08 · ethereum synergies ### Ethereum's Lean Consensus: XDC's Force Multiplier #### Porting Ethereum's PQ Research to XDC Ethereum's Lean Consensus R&D program (tracked at [leanroadmap.org](https://leanroadmap.org/)) is XDC's greatest engineering leverage: - leanSig: Hash-based signature scheme optimized for both SNARKs and quantum resistance - leanMultisig: Aggregate signature scheme compressing multiple XMSS signatures into compact proofs - Post-Quantum Signature Aggregation with zkVMs: Exploring minimal zkVMs (Binus M3, SP1, Jolt, OpenVM) optimized for signature aggregation — directly applicable to XDC's Falcon signatures - Formal Verification: Using Lean 4 framework to mathematically prove security of cryptographic proof systems (FRI, STU, WHIR) - Poseidon Cryptanalysis Initiative: Comprehensive security testing of hash functions used in ZK systems XDC's EVM compatibility means all of this research ports directly. We build on Ethereum's $20M+ research investment without duplicating it. [7] Lean Ethereum. "Lean Consensus R&D Progress." 2025–2026. [leanroadmap.org →](https://leanroadmap.org/) // 09 · xdc's solution architecture ### The XDC PQ Migration Architecture #### Hybrid-First: Zero-Disruption Migration Every phase of XDC's migration uses a hybrid parallel approach: - Classical ECDSA and PQ signatures coexist throughout the transition - Acceptance rules require protocol review. Allowing a classical signature alone does not provide post-quantum authentication once that classical scheme is broken. - A both-required signature construction can retain unforgeability if one scheme remains secure, assuming correct composition, uncompromised keys and correct verification. An either-signature rule does not have that property. - Classical path removed only after a publicly announced **18-month sunset notice** This approach mirrors Google's recommendation: "PQC represents a well-understood path to post-quantum blockchain security" — but it must be done in parallel, not as a flag-day cutover. #### XDSS-PQ: The Strategic Moat XDSS-PQ (XDC Document Signing Standard — Post-Quantum) is more than a technical standard — it's a strategic positioning play: - Dual ML-DSA + Falcon hybrid signatures on every trade document - Co-authored as open standard with ITFA, ICC, and IMDA TradeTrust - 30-year validity windows — a document signed in 2028 remains verifiable in 2058 - EU 2030 + NIST FIPS compliance declarations built into the schema - XDC becomes the reference implementation — creating a network effect moat no fee advantage can overcome // references ### References & Further Reading - IBM Quantum Development Roadmap (2024). [ibm.com/quantum/roadmap](https://www.ibm.com/quantum/roadmap) - Gidney, C. "How to factor 2048-bit RSA integers with less than a million noisy qubits." Google Quantum AI, 2025 (preprint). [arxiv.org/abs/2505.15917](https://arxiv.org/abs/2505.15917) - Gidney, C. & Ekerå, M. "How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits." Quantum, 2021. [arxiv.org/abs/1905.09749](https://arxiv.org/abs/1905.09749) - Kakkad, R. "XDC Network's Unbreakable Future: Exploring area of Quantum-Proof Blockchain Research." xdc.dev, 2024. [xdc.dev/riteshkakkad](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9) - Deloitte. "Quantum computers and the Bitcoin blockchain." [deloitte.com](https://www2.deloitte.com/nl/nl/pages/innovatie/artikelen/quantum-computers-and-the-bitcoin-blockchain.html) - Google Security Blog. "Post-Quantum Cryptography Standards." Aug 2024. [security.googleblog.com](https://security.googleblog.com/2024/08/post-quantum-cryptography-standards.html) - Lean Ethereum. "Lean Consensus R&D Progress." 2025–2026. [leanroadmap.org](https://leanroadmap.org/) - NIST. FIPS 203, 204, 205 (Aug 2024); FIPS 206 / FN-DSA (still in development at this review; the source originally expected 2025). [csrc.nist.gov](https://csrc.nist.gov/projects/post-quantum-cryptography) - Buterin, V. "How to hard-fork to save most users' funds in a quantum emergency." Ethereum Research, March 2024. [ethresear.ch](https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901) - Mosca, M. "Cybersecurity in an era with quantum computers: will we be ready?" IEEE Security & Privacy, 2018. - World Economic Forum. "Quantum Computing Governance Principles." 2024. #### On This Page 01 · Background 02 · XDC-Specific Threats ↳ Community Research 03 · Unique Risk Profile 04 · NIST Standards 05 · Industry Comparison 06 · CRQC Timeline 07 · Active Threats (HNDL) 08 · Ethereum Synergies 09 · XDC's Architecture References [← Back to Overview](https://xdc.network/labs/quantum/) [View Roadmap →](https://xdc.network/labs/quantum-roadmap/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Post-quantum blockchain approaches: a source comparison URL: https://xdc.network/labs/quantum-resistant-blockchains-compared/ Last reviewed: 2026-10-22 The Labs 2026 comparison discusses QRL, Algorand, QANplatform and the XDSS-PQ draft. It is an attributed snapshot, not a verified current ranking. > Comparison dated 21 June 2026; reviewed 22 October 2026. It is a source-attributed snapshot, not a continuously verified ranking. Account signatures, state proofs and validator consensus protect different surfaces. An implementation in one surface does not establish network-wide quantum resilience; XDC’s XDSS-PQ is a draft. Post-quantum · Comparison Jun 21, 2026 · By [Ritesh Kakkad](https://www.xdc.dev/riteshkakkad) · [← All posts](https://xdc.network/labs/blog/) Quantum-resistant blockchains compared (2026) In one paragraph Four projects dominate the post-quantum-blockchain conversation in 2026. **QRL** is the oldest, using hash-based XMSS. **Algorand** is the furthest along in live deployment — Falcon signatures have secured state proofs since 2022 and live mainnet accounts since November 2025. **QANplatform** brings ML-DSA to an EVM-compatible chain. **XDC**'s XDSS-PQ is EVM-compatible and uses a both-required hybrid (ML-DSA and Falcon), but is still in development. There is no single "winner" — they make different trade-offs across algorithm, EVM-compatibility, deployment stage and focus. ### The comparison at a glance Facts below are drawn from each project's own documentation (sources at the end), as of mid-2026. "Status" reflects what is live versus on a roadmap — a distinction that matters more than marketing. Post-quantum blockchain comparison — QRL, Algorand, QANplatform, and XDC XDSS-PQ Project | PQ algorithm | Family | EVM | Status (mid-2026) | Primary focus | QRL | XMSS | Hash-based | No* | Live | Dedicated PQ chain (longest-running) | Algorand | Falcon-1024 | Lattice | No | Live | General + institutional; furthest in live PQ use | QANplatform | ML-DSA (Dilithium) | Lattice | Yes | Stage unstated† | Enterprise / EVM | XDC · XDSS-PQ | ML-DSA **+** Falcon | Hybrid lattice | Yes | In development | Trade finance / tokenized RWA | * QRL is extending to Ethereum via a separate product (enQlave), listed as under development. † QANplatform's docs describe ML-DSA via "QAN XLINK" but do not state a mainnet/testnet stage. ### How to read it **Algorand** has the most mature live deployment: Falcon state proofs since 2022, Falcon-protected mainnet accounts since November 2025, with broad quantum resilience (including PQ consensus research) targeted by end of 2027. If "what is live today" is your only axis, it leads — though Algorand is not EVM-compatible. **QRL** is the longest-running quantum-resistant chain, built from genesis on hash-based XMSS. Hash-based signatures are conservative and well-understood, but QRL is a purpose-built chain rather than an EVM environment, and its Ethereum bridge is still in development. **QANplatform** is the closest peer to XDC on paper: a lattice signature (ML-DSA) on an EVM-compatible chain. Its public documentation, however, does not state whether the post-quantum path is on mainnet or testnet, so deployment maturity is hard to verify. **XDC** is the earliest-stage of the four on post-quantum — XDSS-PQ is a draft, forward-looking standard with consensus migration targeted for 2030. We are not going to claim otherwise. What distinguishes it is the design and the use case, not deployment maturity. ### Where XDSS-PQ is different Two choices set XDSS-PQ apart: **It is a both-required hybrid.** Each trade document carries two independent post-quantum signatures — ML-DSA (FIPS 204) and Falcon / FN-DSA (FIPS 206 in development) — under AND semantics: valid only if both verify. Because they rest on different lattice constructions, a future break of one does not forge the document. Most peers rely on a single post-quantum algorithm; XDSS-PQ deliberately does not. **It is built for the trade-finance edge case.** XDSS-PQ targets the 20–30 year legal validity of tokenized trade documents on an EVM chain — the use case where [document permanence and harvest-now-decrypt-later](https://xdc.network/labs/quantum-safe-trade-finance/) make the quantum risk a present one. That is a narrower aim than "secure the whole chain," and a deliberately defensible one. ### Frequently asked Which blockchains are quantum-resistant in 2026? The most-cited are QRL (hash-based XMSS, oldest), Algorand (Falcon, live on mainnet since Nov 2025 with state proofs since 2022), QANplatform (ML-DSA / Dilithium, EVM-compatible), and XDC, whose XDSS-PQ uses a hybrid of ML-DSA and Falcon and is EVM-compatible but still in development. Is XDC Network quantum-resistant yet? Not yet. XDSS-PQ is a draft standard in development, with consensus migration targeted for 2030. XDC's hash-based components (Keccak-256 addresses, state roots) are already quantum-safe; the ECDSA signature surface is what XDSS-PQ migrates, on a hybrid path. What makes XDSS-PQ different from Algorand or QANplatform? It is a both-required hybrid — two independent post-quantum signatures (ML-DSA and Falcon), valid only if both verify — and it is purpose-built for EVM-based tokenized trade finance and 20–30 year document validity. Algorand's Falcon deployment is further along in live use; XDC's differentiator is the hybrid design and the focus, not deployment maturity. ### Sources - Algorand — Post-quantum (Falcon state proofs 2022; Falcon mainnet accounts Nov 2025; 2027 roadmap). [algorand.co/technology/post-quantum](https://algorand.co/technology/post-quantum) - QANplatform — Quantum-resistant security (ML-DSA / Dilithium, EVM). [learn.qanplatform.com](https://learn.qanplatform.com/technology/technology-features/quantum-resistant-security) - QRL — The Quantum Resistant Ledger (XMSS; enQlave Ethereum bridge in development). [theqrl.org](https://www.theqrl.org/) - XDC — [XDSS-PQ specification (Draft v1.0)](https://xdc.network/labs/xdss-pq-spec/) and NIST PQC: [csrc.nist.gov](https://csrc.nist.gov/projects/post-quantum-cryptography) RK Ritesh Kakkad Co-founder, XDC Network · writes on post-quantum security and trade finance ### Related reading [Trade finance Will an on-chain document survive Q-Day?](https://xdc.network/labs/quantum-safe-trade-finance/) [Spec XDSS-PQ signature standard](https://xdc.network/labs/xdss-pq-spec/) [Post-quantum Q-Day is a probability, not a date](https://xdc.network/labs/q-day-probability-not-date/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## The Labs post-quantum migration roadmap URL: https://xdc.network/labs/quantum-roadmap/ Last reviewed: 2026-10-22 Read the Labs proposed migration phases and target dates. Source progress labels do not establish completed audits, deployments, governance decisions or compliance. > Planning snapshot reviewed 22 October 2026. Checkmarks, progress percentages and “Active Now” labels are source annotations, not independently verified completion. The dates differ from the FAQ. Audit publication, governance votes, partner agreements, deployments and compliance achievements require separate evidence. [PQ Initiative](https://xdc.network/labs/overview/) / Migration Roadmap Quantum-first EVM chain · initiative & roadmap to 2030 Quantum-Safe Migration Roadmap Four phases. Highest risk first. No flag-day cutover — classical and post-quantum signatures run in parallel at every phase. This is the XDC roadmap to a quantum-first EVM chain, targeting EU PQC (December 2030) compliance by design. ● Phase 0 — Active now (Q2–Q3 2026) ● Phase 1 — Q4 2026 ● Phase 2 — Q3 2027 ● Phase 3 — Q1 2029 Provenance · research since 2024 ### Research Timeline Since 2024 XDC's quantum-first work isn't new — the community has been actively researching and building toward it for over a year, well ahead of the regulatory clock. MARCH 2024 Ritesh Kakkad publishes quantum research "XDC Network's Unbreakable Future" — first comprehensive analysis of quantum threats to XDC, covering ECDSA vulnerability, NIST PQC standards, and migration strategies. [Read article →](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9) AUGUST 9, 2025 Falcon POC committed to XDPoSChain Working proof-of-concept implementing Falcon signatures for XDPoS consensus — block signing and quorum certificates. Benchmarks: 0.138ms verification, 666B signatures. [View code →](https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon) AUGUST 16, 2025 Gary publishes PQ signatures deep-dive "Securing XDC with Post-Quantum Signatures" — comprehensive 3-layer migration analysis covering validator keys, wallet addresses, and document signatures. [Read article →](https://www.xdc.dev/gary/securing-xdc-with-post-quantum-signatures-2j86) MARCH 2026 XDC PQ Initiative launched Formal four-phase migration roadmap (Phase 0–3), XDSS-PQ standard proposed as an open standard with ITFA/ICC, and published Google Quantum AI resource estimates folded into the threat model. JUNE 2026 — NOW Phase 0 — audit & foundation in progress Cryptographic surface audit and risk matrix underway (Q2–Q3 2026). Hybrid-first by design: every later phase runs classical and post-quantum signatures in parallel. Overall PQ Migration Progress ~8% Phase 0 Q2–Q3 2026 Phase 1 Q4 2026–Q2 2027 Phase 2 Q3 2027–Q4 2028 Phase 3 Q1 2029–Q4 2030 // gantt timeline · 2026 – 2030 H1'26 H2'26 H1'27 H2'27 H1'28 H2'28 H1'29 H2'29 H1'30 H2'30 🏁 Phase 0 Phase 1 Phase 2 Phase 3 Deadlines CNSA 2.0 EU 2030 0 Phase 0 — Active Now Audit & Foundation Q2 – Q3 2026 ● Active ★ Full cryptographic surface audit Inventory every XDC cryptographic dependency — consensus, wallets, bridges, P2P, smart contracts. Publish findings in Threat Assessment Report v1.0. ★ Risk matrix — publicly published Severity × likelihood matrix for all quantum attack vectors. Maps each surface to its NIST PQC solution. ✓ XDC PQ Security Council formed Cross-functional team: protocol engineers, cryptographers, enterprise partners, validator operators. ✓ XIP-PQ-001 community vote Governance proposal ratifying the 4-phase roadmap. Community consensus before any protocol changes. ✓ Engage EF PQ Team, Polkadot, NIST Proposed engagement with external research and standards communities. Formal collaboration agreements are not established by the reviewed source. ✓ Threat Assessment Report v1.0 published Comprehensive public report covering all quantum threats to XDC, with specific mitigation plans and timeline for each. **Foundation built by community:** This phase builds on Ritesh Kakkad's [quantum-proof blockchain research](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9), which identified the seven key defense pillars: quantum-resistant cryptography, network hardening, consensus resilience, QKD integration, continuous assessment, industry collaboration, and regular audits. 1 Phase 1 Infrastructure Hardening Q4 2026 – Q2 2027 Upcoming ✓ PQ-TLS — all 108 masternodes ML-KEM768 + X25519 hybrid TLS 1.3 across all masternode P2P and RPC communications. Eliminates harvest-now-decrypt-later risk. <5% overhead. ✓ Bridge admin keys → hybrid ECDSA+ML-DSA Cross-chain bridge multisig keys upgraded to dual classical+PQ signing. Both signatures required during transition. ✓ XDC DAO governance keys upgraded All protocol governance admin keys migrated to hybrid ECDSA + SLH-DSA (SPHINCS+). Most conservative algorithm for highest-value operations. ★ Proposed CNSA 2.0 readiness objective CNSA 2.0 applies to US National Security Systems and has category-specific transition schedules. This roadmap does not demonstrate compliance. ⚠ CNSA 2.0 — Jan 2027 deadline ✓ Subnet PQ guidance published Best practices document for XDC subnet operators to adopt PQ-TLS and hybrid signing. ✓ QKD partnership pilot Begin QKD integration pilot for critical masternode links, as proposed in community research. Mirrors JPMorgan's Q-CAN dual PQC+QKD strategy. ⚠ CNSA 2.0 (NSA) — Jan 2027 ⚠ DORA (EU) — Active enforcement **Why TLS first:** Harvest-now-decrypt-later is the only quantum attack vector that is **active today**. PQ-TLS eliminates it immediately. Google, Cloudflare, and AWS have proven this is a drop-in upgrade at internet scale. **Dependency:** Phase 0 audit must complete before infrastructure changes begin. Ensures no surface is missed. 2 Phase 2 Execution Layer Q3 2027 – Q4 2028 Upcoming ✓ ML-DSA + Falcon EVM precompiles Dedicated precompiled contracts for PQ signature verification. Reduces gas from ~200,000 to ~12,000–15,000. Ported from Ethereum's J* fork precompile research. ✓ Account abstraction (XIP-AA) deployed Proposed account-abstraction support would require reviewed XDC specifications, implementation and activation rules. Address continuity, migration steps and upgrade requirements are not established here. ✓ Masternode PQ Key Registry on-chain On-chain registry mapping validator addresses to their PQ public keys. Enables the Phase 3 consensus migration. ★ XDSS-PQ v1.0 — open standard published Dual ML-DSA + Falcon hybrid signing schema for trade documents. Draft for review. Formal co-authorship and industry adoption are not established here. The strategic deliverable. ★ First banking partner adoption Initial institutional partner issues PQ-signed trade documents on XDC using XDSS-PQ v1.0. ✓ STARKs-only policy for new ZK deployments All new XDC ZK proofs (DeFi, privacy subnets) must use hash-based STARKs instead of KZG-based SNARKs. PQ-safe by design. **Key milestone:** XDSS-PQ v1.0 publication. This transforms XDC from "a blockchain doing PQ" to "the standard setter for PQ trade finance." Network effect moat. **EVM leverage:** Precompiles and account abstraction are ported from Ethereum's open-source research. Lean Consensus's leanSig and leanMultisig work directly informs XDC's implementation. 3 Phase 3 Consensus Migration Q1 2029 – Q4 2030 Upcoming ✓ XDPoS 2.0 Falcon validator signing Replace ECDSA with Falcon (FIPS 206) in XDPoS 2.0 block signing. 666B sigs preserve gossip bandwidth. The final and most critical migration step. ✓ 12-month dual-signing transition The source proposes a dual-signing transition. Acceptance rules and duration require protocol review: accepting ECDSA alone would not provide post-quantum authentication after ECDSA is broken. ✓ STARK-based signature aggregation Compress N Falcon signatures into one recursive STARK proof. Mirrors Ethereum's leanMultisig approach. Restores BLS-like aggregation efficiency. ✓ ECDSA consensus sunset — 18-month notice After 12-month dual-signing, announce 18-month countdown to ECDSA removal from consensus. Classical path remains for user transactions longer. ★ EU critical-infrastructure transition target: end of 2030 The EU roadmap calls for critical-infrastructure transition by the end of 2030. XDC implementation and organization-specific compliance must be established separately. 🏁 EU PQC Mandate — Dec 2030 ✓ Independent security audit — final Third-party audit of complete PQ migration. Public report. Formal verification of critical paths using Lean 4 framework. 🏁 EU PQC Mandate — Dec 2030 → NIST IR 8547 — 2035 (ECDSA deprecated) **Governance checkpoint:** Community vote required before ECDSA sunset. No surprise migrations. Full transparency at every step. **Google's recommendation:** Google set a 2029 PQC migration deadline for their own systems. Phase 3 aligns with this timeline while providing the 12-month dual-signing safety net. Migration principles ### Guiding Principles 🔄 Hybrid-first, always Hybrid security depends on the acceptance rule and implementation. Requiring both signatures can preserve unforgeability while one scheme remains secure; accepting either signature cannot provide that guarantee. ⚡ Highest risk first HNDL (active today) → Bridge keys → Trade docs → Validator consensus. Each phase addresses the next-highest-risk surface. 🏛️ Community governance XIP votes at each phase gate. Independent audits before each transition. 18-month sunset notices before any removal. 🔗 Leverage Ethereum's research EVM compatibility = direct port of precompiles, account abstraction, STARK aggregation. Build on $20M+ research, don't duplicate it. 📋 Open standards XDSS-PQ is published as an XDC Innovation Labs draft; external co-authorship is not established here. XDC becomes the reference implementation — network effect moat. 🎯 Compliance-driven timeline Anchored to CNSA 2.0 (2027), EU PQC (2030), and NIST IR 8547 (2035). XDC's institutional partners require compliance on these dates. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Post-quantum research for trade documents URL: https://xdc.network/labs/quantum-safe-trade-finance/ Last reviewed: 2026-10-22 A Labs article considers long-lived trade-document signatures and the proposed XDSS-PQ design. The draft does not guarantee authenticity, legal effect or indefinite security. > Article dated 21 June 2026; reviewed 22 October 2026. Document-signature forgery differs from decryption of recorded ciphertext. Legal retention and evidentiary requirements vary. XDSS-PQ remains a draft and does not guarantee a document’s authenticity, legal effect or indefinite security. Post-quantum · Trade finance Jun 21, 2026 · By [Ritesh Kakkad](https://www.xdc.dev/riteshkakkad) · [← All posts](https://xdc.network/labs/blog/) Quantum-safe trade finance: will an on-chain document survive Q-Day? In one paragraph A bill of lading or letter of credit can be **contested in court 20–30 years** after it is signed — and the signature is the legal proof. That lifespan is **longer than most Q-Day estimates**, and because a tokenized document lives on a permanent public ledger, an adversary can copy it now and forge it once quantum computers arrive. XDC's **XDSS-PQ** standard answers this by binding each document to **two** NIST-aligned post-quantum signatures — valid only if both verify — with the goal of long-term resistance to forgery, subject to implementation and security review. ### The hardest deadline in cryptography is a legal one Most signed digital artifacts have a short security horizon — a TLS session, a software release, an authentication token. Trade-finance instruments are the opposite: their **legal lifespan is measured in decades**. A letter of credit, a bill of lading, or a tokenized receivable signed today may need to be presented, audited, or contested **20 to 30 years from now**, and the cryptographic signature is what proves it is authentic. That single fact reorders the entire quantum-risk calculation. You are not securing a document against today's threats — you are securing it against every adversary that will exist across its whole legal life. By [Mosca's rule](https://xdc.network/labs/q-day-probability-not-date/), when the data's required secrecy lifetime alone exceeds the time until a quantum computer arrives, the migration is already late. ### Why a permanent public ledger makes it worse Putting a trade document on-chain is exactly the right move for transparency and auditability — but it changes the threat model. The document, and its classical ECDSA signature, are **public and permanent**. That turns the quantum threat into a present one through a future signature-forgery risk: an adversary does not need a quantum computer today. They only need to keep a copy of the signed record and wait. Trust-Now-Forge-Later When a cryptographically-relevant quantum computer arrives, every ECDSA-signed document already on-chain becomes **forgeable** — decades after it was issued. A 2025 Federal Reserve working paper makes the same point for distributed ledgers: on-chain history stays harvest-now-decrypt-later–vulnerable even after a network migrates. This is the gap generic "quantum-safe blockchain" messaging misses. Protecting new transactions is necessary but not sufficient when your core asset is a document that must remain provably authentic for thirty years. ### XDSS-PQ: two signatures, both required XDC's response is **XDSS-PQ** — a draft, forward-looking standard for post-quantum trade-document signatures. Rather than betting on a single post-quantum algorithm, it binds each document to **two independent NIST-aligned signatures**: - **ML-DSA** (FIPS 204) — the NIST primary post-quantum signature standard, a lattice construction (Dilithium). - **Falcon / FN-DSA** (FIPS 206 in development) — the most compact NIST-track signature, built on a different lattice construction. The two are combined under **AND semantics**: a document is valid only if **both** signatures verify. Forging one therefore requires breaking **both** standardized algorithms at once — and because they rest on different mathematical structures, a future break of one does not collapse the other. For an artifact that must survive 30 years of unknown cryptanalysis, that conservatism is the point. ### Built on an EVM chain, aligned to 2030 XDSS-PQ is designed for XDC — an EVM-compatible chain already used for tokenized trade finance — so the proposed post-quantum protections would apply to documents inside the same developer ecosystem teams already build on. The roadmap is paced to the deadlines that are actually fixed: the EU's 2030 post-quantum migration target and the NIST schedule to retire classical signatures by 2035. To be clear about status: **XDSS-PQ is a Draft v1.0 specification and in development**, not a finished product — it is published now precisely because, for 30-year documents, the design work has to happen before the threat does. ### Frequently asked Will a trade document signed on-chain today survive Q-Day? Only if it is signed with post-quantum cryptography. A classical ECDSA signature can be forged once a quantum computer exists — and because the document sits on a permanent public ledger, an adversary can keep a copy now and forge it later. A 20–30 year document needs a quantum-safe signature today. What is XDSS-PQ? XDC's draft post-quantum signature standard for tokenized trade documents. It binds each document to two independent NIST-aligned signatures — ML-DSA (FIPS 204) and Falcon/FN-DSA (FIPS 206 in development) — under AND semantics, so it stays secure unless both algorithms are broken. It is forward-looking and in development. Why does trade finance need this sooner than other use cases? Document lifespan. A letter of credit may be contested 20–30 years after issuance, and the signature is the legal proof. That exceeds most Q-Day estimates, so by Mosca's rule the migration is already overdue for documents signed now. ### Sources - XDC — [XDSS-PQ specification (Draft v1.0)](https://xdc.network/labs/xdss-pq-spec/): the hybrid ML-DSA + Falcon design, AND semantics, and document schema. - NIST Post-Quantum Cryptography — FIPS 203/204 and the ECDSA transition timeline. [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - Federal Reserve, FEDS 2025-093 — harvest-now-decrypt-later risk for distributed-ledger data. [federalreserve.gov](https://www.federalreserve.gov/econres/feds/files/2025093pap.pdf) RK Ritesh Kakkad Co-founder, XDC Network · writes on post-quantum security and trade finance ### Related reading [Post-quantum Q-Day is a probability, not a date](https://xdc.network/labs/q-day-probability-not-date/) [Spec XDSS-PQ signature standard](https://xdc.network/labs/xdss-pq-spec/) [Deep-dive Quantum threats to XDC](https://xdc.network/labs/quantum-research/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## The Labs post-quantum initiative URL: https://xdc.network/labs/quantum/ Last reviewed: 2026-10-22 Explore the Labs XDSS-PQ proposal, Falcon consensus experiment and migration planning. This reference does not establish quantum-safe XDC mainnet activation. > Source snapshot reviewed 22 October 2026. This page describes proposals and contributor-reported experiments, not quantum-safe XDC mainnet activation. Roadmap dates, compliance claims and benchmarks need their own evidence. NIST has finalized FIPS 203–205; Falcon-based FIPS 206 remains in development. XDC PQ Initiative, Quantum-First EVM Chain The quantum-first EVM chainfor global trade finance. Engineering post-quantum security into validators, wallets, and 30-year trade documents on a roadmap informed by NIST standards and ongoing standardization. [Explore the roadmap →](https://xdc.network/labs/quantum-roadmap/) View XDSS-PQ standard $5T Global trade-finance gap targeted 20–30yr Trade-document legal longevity 2030 EU PQC readiness target 108 XDPoS 2.0 masternode keys to migrate ### You can't schedule Q-Day . Count down to the deadline you control. "Q-Day", the day a cryptographically-relevant quantum computer breaks ECDSA, has no fixed date. It's a probability, not a calendar entry. But the deadlines to be ready are real, and because of harvest-now-decrypt-later, the clock on every 30-year document signed today already started. Time until XDC must be fully quantum-safe --days --hrs --min --sec The EU roadmap calls for critical-infrastructure transition by the end of 2030. Its applicability depends on the organization and system; this page does not establish a binding deadline for XDC or every partner. -- days to **CNSA 2.0**NSA PQC mandate, Jan 2027 -- days to **NIST ECDSA sunset**IR 8547, 2035 2056 **30-yr documents** signed today must stay unforgeable until thenharvest-now-decrypt-later horizon Researcher view, Mosca's inequality #### If X + Y > Z , you're already late. Michele Mosca's rule for the quantum transition: if the time your data must stay secret (X) plus the time it takes to migrate (Y) exceeds the time until Q-Day (Z), exposure is already unavoidable. - X, secrecy lifetime**~30 yr**trade documents legally valid to ~2056 - Y, migration time**~4 yr**audit → infrastructure → consensus cutover - Z, time to Q-Day**est. 5–10 yr**expert median; wide uncertainty 30 + 4 = 34  >  ~7. The safe start line is **already behind us**. For long-lived documents, migration has to be underway now, not when Q-Day is announced. The honest estimate, not a date #### When is Q-Day? Nobody knows. That's the point. Expert surveys (Global Risk Institute Quantum Threat Timeline; M. Mosca) put a small-but-rising probability on a cryptographically-relevant quantum computer this decade. The responsible plan assumes the early end of the range, not the late one. Q-Day is a probability distribution, not a fixed event. Sources vary widely; plan for the early end of the range rather than a specific date. **What this means for you.** You can't wait for Q-Day to act. By the time it's announced it's already too late, and migration takes years. If you hold XDC assets, sign trade documents, or run a masternode, the deadline that matters is the **migration deadline (2030)**, not Q-Day itself. XDC's PQ Initiative is the plan to get there with hybrid signing and zero disruption. ### XDC carries a uniquely long-lived quantum exposure Long-lived trade records motivate early cryptographic planning. Future signature forgery is distinct from harvest-now-decrypt-later attacks on encrypted information; document retention and legal requirements vary. P0 Critical #### Trade document signatures Bills of lading, letters of credit, and RWA instruments signed on XDC today remain legally valid for decades. A future quantum computer could forge them to claim false asset ownership, the Trust-Now-Forge-Later (TNFL) attack. ECDSA, secp256k1, 20–30yr lifespan P0 Critical #### Validator masternode keys 108 active masternodes hold ECDSA keys signing XDPoS 2.0 blocks. Compromise via Shor's algorithm would give an adversary control of finality and block production, the chain's ultimate authority. ECDSA, secp256k1, 108 validator keys P0 Critical #### Bridge & DAO governance Cross-chain bridge multisigs and XDC DAO admin keys are the highest-value TNFL targets. A forged bridge signature could redirect settlement funds, undetectable until after Q-Day arrives. ECDSA multisig, TNFL, indefinite P0 Critical #### EOA wallet keys Every XDC account uses secp256k1. Once a public key is on-chain, a quantum computer could derive the private key and drain the wallet. All accounts that have transacted are exposed. ECDSA, secp256k1, exposed pubkeys P1 High #### P2P node communications Masternode TLS uses classical ECDH key exchange. Harvest-now-decrypt-later attacks on this traffic are possible today; adversaries can record now and decrypt later when quantum hardware arrives. ECDH, TLS 1.2–1.3, HNDL active now Low Risk #### Hash functions - already safe Keccak-256 and SHA-3 are quantum-resistant by design. Grover's algorithm provides only a quadratic speedup, effectively doubling the security requirement, not breaking it. Keccak-256, Grover 2x only, no action ### XDC's partners face hard compliance deadlines Banks and regulated financial entities building on XDC face active PQC mandates. If XDC's cryptography isn't on a credible quantum-safe path, it risks becoming a compliance liability for its own institutional ecosystem. In force DORA (EU) Financial entities must demonstrate robust cryptographic controls to regulators. Mandated CNSA 2.0 (NSA) All new National Security System acquisitions must be PQC-compliant on a fixed timeline. 2030 EU PQC Roadmap Full PQC migration for EU critical infrastructure, including XDC's regulated partners. 2035 NIST IR 8547 ECDSA and all quantum-vulnerable algorithms deprecated from NIST standards. // industry already deploying pqc Google Chrome, ML-KEM TLSIn production Apple iMessage PQ3Kyber + ECC live Cloudflare edge TLSX25519 + Kyber AWS, PQ-TLSAvailable JPMorgan, QKD + PQCResearch live Mastercard contactlessPQ deployed Signal PQXDHPQ msgs 2023 Ethereum, leanEthereum PQResearch Polkadot, Falcon keysRoadmap → PQC is already shipping across the industry. XDC is building to be ready alongside it. The algorithm stack ### Proposed post-quantum choices for every XDC cryptographic surface Each surface needs a different algorithm. XDC's planned stack is optimised for validator bandwidth (Falcon), document longevity (XDSS-PQ hybrid), and institutional TLS compliance (ML-KEM). #### Falcon / FN-DSA (FIPS 206 in development), proposed XDPoS 2.0 validator signing › 666-byte signatures, a compact NIST-selected signature scheme still undergoing standardization. Critical for XDPoS 2.0, where 108 masternodes sign every block and gossip signatures network-wide. Polkadot is also evaluating Falcon for validator keys for similar bandwidth reasons. #### ML-DSA / Dilithium (FIPS 204), EOA wallets › ML-DSA is standardized in FIPS 204. Signature size depends on the parameter set: 2,420 bytes for ML-DSA-44 and 3,309 bytes for ML-DSA-65. XDC wallet integration is proposed; Signal PQXDH is a key-agreement protocol, not evidence of ML-DSA deployment. #### XDSS-PQ hybrid (FIPS 204 + 206), trade documents › XDC flagship: dual ML-DSA + Falcon signatures on RWA issuances, letters of credit, and bills of lading. The hybrid requires BOTH signatures to verify, so a forgery would require breaking BOTH NIST algorithms simultaneously. Designed for 20–30 year validity windows. #### SLH-DSA / SPHINCS+ (FIPS 205), DAO governance › Hash-based; security depends only on SHA-256, the most conservative foundation. 8–50 KB size is acceptable for rare, high-value governance operations. Recommended by UK NCSC for software signing. // signature size comparison (relative) ECDSA (now) Falcon 666 B ML-DSA 2.4 KB SPHINCS+ 8 KB All are PQ-safe. Bar = relative sig size. FIPS all NIST std 2024 finalised 3 backup algos #### ML-KEM + X25519 hybrid TLS (FIPS 203), all nodes › Upgrade all 108 masternodes + RPC endpoints to ML-KEM768 + X25519 hybrid TLS 1.3. Already deployed at internet scale by Google, AWS, and Cloudflare. <5% overhead on high-bandwidth links. A pure infrastructure upgrade, no protocol changes required. #### Hybrid parallel scheme, zero disruption › Classical + PQ run in parallel during every phase, so a session is protected as long as EITHER key-exchange holds. The classical path is removed only after a publicly announced 18-month notice sunset date. #### QKD for critical masternode links › Physics-based key distribution for the highest-value node-to-node links. Any interception is immediately detectable. Mirrors JPMorgan's dual PQC + QKD strategy for critical financial infrastructure. // hybrid tls overhead (reported) High-BW link Standard conn Low-BW link <5% overhead HB drop-in for ECDH #### STARKs over SNARKs for all new ZK deployments › KZG-based SNARKs rely on elliptic-curve pairings, quantum-vulnerable. STARKs are hash-based, require no trusted setup, and are PQ-safe by design. All new XDC ZK proofs (DeFi, privacy subnets) should use STARKs from Phase 1 onwards. #### Recursive STARK aggregation for consensus › Falcon / ML-DSA lack BLS's native aggregation. The approach: compress N Falcon signatures into one recursive STARK proof. This mirrors Ethereum's leanMultisig / leanVM work. XDC's EVM compatibility means we can port it rather than rebuild it. #### EVM precompiles, gas optimisation › PQ signature verification without a precompile is on the order of ~200,000 gas, versus ~80 gas amortised for an ECDSA verification today. Dedicated ML-DSA + Falcon precompiles target the ~12,000–15,000 gas range, which is what keeps PQ verification economically practical at scale. Ethereum's precompile research ports directly to XDC; we build on it rather than duplicate it. // gas: pq signature verification ECDSA now PQ no precomp PQ precompile STARK aggreg. ~80 gas amortized STARKs PQ-safe ZK // XDC full algorithm stack, reference XDC Use Case | Algorithm | Standard | Sig Size | Why | XDPoS 2.0 validator signing | Falcon / FN-DSA | FIPS 206 | 666 B | Most compact NIST PQ sig, bandwidth-critical for 108-node gossip | EOA wallet signing | ML-DSA / Dilithium | FIPS 204 | 2.4 KB | Primary NIST standard; best-audited; IBM Research co-authored | RWA & trade doc signing | XDSS-PQ dual hybrid | FIPS 204 + 206 | ~3 KB | Both must hold to verify; forgery needs breaking both; 30-year validity designed-in | P2P & RPC TLS | ML-KEM + X25519 | FIPS 203 | KEM | Drop-in for ECDH; deployed by Google/Cloudflare/AWS at scale | DAO & bridge governance | SLH-DSA / SPHINCS+ | FIPS 205 | 8–50 KB | Hash-only; most conservative; fine for rare high-value ops | DeFi & subnet ZK proofs | STARKs (hash-based) | PQ-safe | hash | No KZG/ECC dependency; no trusted setup; PQ-safe by design | ### XDC isn't just talking. There is working code. While most chains publish whitepapers, XDC has a live Falcon proof-of-concept in the official repository, backed by published research from core contributors Gary and Ritesh Kakkad. Live Code #### Falcon consensus proof of concept August 9, 2025 XDC has a `poc_falcon` branch in **XinFinOrg/XDPoSChain** implementing Falcon signatures for the consensus layer, block signing + QC (Quorum Certificate) verification. Benchmarks report ~0.138 ms verification time with 666-byte signatures. [View Falcon POC →](https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon) Research #### Gary's 3-layer migration analysis August 16, 2025 "Securing XDC with Post-Quantum Signatures" by Gary, a 3-layer migration strategy covering validator keys, EOA accounts, and trade-document signing. Published on XDC.dev with threat modelling and algorithm-selection rationale. [Read Gary's research →](https://www.xdc.dev/gary/securing-xdc-with-post-quantum-signatures-2j86) Research #### Ritesh's quantum threat landscape March 19, 2024, first in the XDC ecosystem "XDC Network's Quantum-Proof Future" by Ritesh Kakkad, explores the quantum threat landscape, Google's cryptographic-vulnerability disclosures, and why XDC's institutional focus calls for an early post-quantum path. [Read Ritesh's research →](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9) Falcon PoC, measured on XinFinOrg/XDPoSChain poc_falcon branch 0.138 ms verify time Falcon sig verification 666 B signature size most compact NIST PQ sig 108 validator keys XDPoS 2.0 masternodes poc_falcon branch XinFinOrg/XDPoSChain // where XDC stands #### Among the few chains with working PQ consensus code ✓XDC, Falcon POC in the official repo + published research + XDSS-PQ standard in development. ●Ethereum, leanEthereum PQ research underway; consensus-layer PQ not yet shipped. ●Bitcoin, no formal PQ roadmap; community discussion; soft-fork complexity high. ✓Polkadot, announced Falcon for validator keys; execution-layer plan still emerging. ✓Algorand, state-proof PQ research published; implementation timeline unclear. ○Others, many large L1s have no publicly announced PQ initiative or working code. → XDC is one of the few chains with working Falcon code in an official repository, not just research papers. // Google Quantum AI, supporting research Google's Quantum AI team has published responsible-disclosure research on the quantum risk to cryptocurrency cryptography. Notably, their 2025 resource-estimate work substantially lowered the estimated quantum resources needed to break RSA-2048, reported as roughly a 20x reduction versus prior estimates, reinforcing the case for migrating well ahead of any "Q-Day." We cite this qualitatively; the exact hardware figures remain subject to active research. [→ Google Research blog: "Safeguarding Cryptocurrency by Disclosing Quantum Vulnerabilities Responsibly"](https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/) ### Every XDC layer is on the quantum-hardening roadmap consensus #### XDPoS 2.0 to Falcon signing Replace ECDSA with Falcon in validator block signing. 666 B sigs preserve gossip bandwidth. A 12-month dual-signing window targets zero disruption. CurrentECDSA secp256k1 TargetFalcon FN-DSA Validators108 masternodes flagship, open standard #### XDSS-PQ, a PQ trade-document standard Dual ML-DSA + Falcon hybrid on RWA issuances, letters of credit, and bills of lading. Being developed as an open, NIST-aligned standard so XDC can serve as a reference implementation institutions can adopt. ML-DSAFalconHybrid dual-sigFIPS 204FIPS 206MLETR-aligned infrastructure #### PQ-TLS for all masternodes ML-KEM768 + X25519 hybrid TLS 1.3 across all 108 masternode P2P and RPC comms. Proven at internet scale by Cloudflare and Google. 108 nodes <5% overhead wallets #### Account abstraction + PQ opt-in Port an EIP-8141-equivalent to XDC so users can upgrade to ML-DSA signing without a hard fork. A gradual, incentivised, non-disruptive migration path. Opt-in user path 0 disruption governance #### DAO & bridge keys, hybrid XDC DAO and cross-chain bridge admin keys upgraded to hybrid ECDSA + ML-DSA. Protocol upgrades require both signatures during the transition. SLH-DSAML-DSAHybrid roadmap #### Four phases, 2026 to 2030 A structured migration with governance checkpoints, community votes, and independent audits at each phase gate. No surprise migrations. Phase 0, Audit & FoundationQ2–Q3 2026 Phase 1, InfrastructureQ4 2026–Q2 2027 Phase 2, Execution LayerQ3 2027–Q4 2028 Phase 3, ConsensusQ1 2029–Q4 2030 compliance #### EU 2030 & NIST 2035 targeted Phase 3 is planned to align with the EU 2030 PQC migration target and the NIST IR 8547 2035 deprecation deadline. EU 2030 target NIST FIPS aligned The migration roadmap ### Four phases. Highest-risk first. EU-2030 target. No flag-day cutover. Classical and PQ run in parallel at every phase. The network migrates when the community is ready. 01 Audit & Foundation Crypto inventory, risk matrix, PQ Security Council, Threat Report v1.0 02 Infrastructure PQ-TLS masternodes, bridge & DAO key upgrades, subnet guidance 03 Execution Layer PQ precompiles, account abstraction, PQ key registry, XDSS-PQ 04 Consensus Migration Falcon XDPoS 2.0, STARK aggregation, ECDSA sunset, EU 2030 Phase 0, Active now Audit & Foundation Q2–Q3 2026 ★Full crypto audit, all XDC surfaces ★Risk matrix published publicly ✓XDC PQ Security Council formed ✓XIP-PQ-001 community vote ✓Engage EF PQ team, Polkadot, NIST ✓Threat Assessment Report v1.0 published Phase 1 Infrastructure Hardening Q4 2026 – Q2 2027 ✓PQ-TLS (ML-KEM + X25519), all 108 masternodes ✓Bridge admin keys to hybrid ECDSA + ML-DSA ✓XDC DAO governance keys upgraded ★CNSA 2.0 alignment milestone Phase 2 Execution Layer Q3 2027 – Q4 2028 ✓ML-DSA + Falcon EVM precompiles live ✓Account abstraction (XIP-AA) deployed ✓Masternode PQ Key Registry on-chain ★XDSS-PQ v1.0, open standard published ★First banking-partner adoption Phase 3 Consensus Migration Q1 2029 – Q4 2030 ✓XDPoS 2.0 Falcon validator signing ✓12-month dual-signing transition ✓STARK-based aggregation deployed ✓ECDSA consensus sunset, 18-month notice ★EU 2030 PQC readiness target Phase 0 items marked ✓ are underway; ★ items and later phases are the active plan. The consensus migration is targeted to complete by 2030. Two audiences. Two next steps. [For engineers Fork the Falcon PoC The live poc_falcon branch in XinFinOrg/XDPoSChain implements Falcon validator signing. 0.138 ms verification, 666 B signatures, working code, not a whitepaper. View poc_falcon on GitHub →](https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon) [For institutions Read the XDSS-PQ draft The hybrid ML-DSA + Falcon standard for 30-year trade documents, open, NIST-aligned, designed for adoption by regulated finance counterparties. Read the XDSS-PQ standard →](https://xdc.network/labs/xdss-pq-spec/) ### XDSS-PQ: the standard built to make XDC indispensable Not just a technical upgrade, the strategic move that aims to reposition XDC from a blockchain into a cryptographic-infrastructure reference for global trade finance. Open, NIST-aligned standard, not proprietary crypto Built on FIPS 203/204/205/206 and published openly, so XDC can serve as a reference implementation institutions can adopt, creating a durable network effect. Both algorithms must hold to verify Hybrid ML-DSA + Falcon with AND semantics: a document validates only if both signatures verify, so a forgery would require breaking both FIPS-standardized algorithms simultaneously. Designed for 30-year validity windows An XDSS-PQ bill of lading signed in 2028 is designed to remain cryptographically verifiable and unforgeable in 2058, long after any Q-Day. xdss-pq/v1.0, trade document schemaDRAFT EXAMPLE { "standard": "XDSS-PQ/1.0", "document_type": "bill_of_lading", "issuer": "xdc://0xA3f2...91CC", "signatures": { "ml_dsa": "", "falcon": "", "scheme": "hybrid-dual-sig", "valid_if": "both_required" }, "valid_until": "2058-12-31", "compliance": ["EU-PQC-2030","NIST-FIPS","MLETR"] } Sigs BOTH VALID Quantum SAFE MLETR OK EU 2030 READY Aligned with NIST FIPS 203FIPS 204FIPS 205FIPS 206 (in development)MLETR " The XDC commitment Quantum computers will not arrive with a 90-day migration window. The only path that protects the institutions, businesses, and individuals who trust XDC Network with their most critical trade-finance infrastructure is to build the migration now — so that every instrument signed in 2026 is designed to remain verifiable, unforgeable, and trusted in 2056. — XDC Network PQ Security Council ### Why this matters to institutional trade finance "Trade-finance documents have lifespans measured in decades. The cryptographic infrastructure signing them today must remain verifiable and unforgeable in 2055. XDC's XDSS-PQ initiative is the first serious, structured attempt by any blockchain to face this reality directly — built on NIST standards, not proprietary crypto." AK Atul Khekade Co-Founder, XDC Network 20–30yr doc longevity $5T trade gap 2030 EU target FAQ ### Common questions #### When will quantum computers actually break ECDSA? + Most roadmaps place cryptographic relevance in the early-to-mid 2030s. IBM targets large-scale logical-qubit systems around 2030; DARPA's 2033 benchmark is a useful objective signal. The critical factor isn't the exact threat date, it's lead time. Migrating XDC's decentralised infrastructure takes years, so starting in 2026 is what makes readiness by 2030–2035 realistic. #### Why is XDC's exposure longer-lived than most chains? + Two reasons specific to XDC. First, trade-finance documents have 20–30 year legal lifespans; a bill of lading signed today may be referenced in litigation in 2050. Second, XDC's institutional partners (banks, regulated financial entities) face active DORA and EU-2030 PQC mandates. That combination gives XDC a uniquely long cryptographic-longevity window to plan for. #### Will the PQ migration disrupt XDC users or validators? + No, by architectural design. Every phase uses a hybrid parallel approach: classical ECDSA and PQ signatures coexist. Users opt in to PQ signing at their own pace. Masternodes dual-sign during the 12-month Phase 3 transition. Existing smart contracts work unchanged throughout Phases 0–2. There is no flag-day cutover. #### Why Falcon for XDPoS 2.0 validators, not Dilithium? + Bandwidth. XDPoS 2.0 has 108 masternodes signing every block, and those signatures must be gossiped network-wide. Falcon (FN-DSA, FIPS 206 in development) produces 666-byte signatures, the most compact NIST PQ scheme. ML-DSA's ~2.4 KB signatures are roughly 3.6x larger than Falcon and far larger than current ECDSA, making Falcon the clear choice for bandwidth-constrained validator gossip. #### What exactly is XDSS-PQ and why does it matter strategically? + XDSS-PQ is a complete trade-document signing schema: dual ML-DSA + Falcon signatures (both required to verify), metadata standards, 30-year validity windows, and EU-2030 + NIST FIPS compliance declarations. Developed as an open, NIST-aligned standard, it is designed to make XDC a reference implementation, a network-effect advantage no fee discount can match. #### How does XDC benefit from Ethereum's PQ research? + Directly, via EVM compatibility. Ethereum's open-source PQ toolchain (leanSig, leanSpec, leanMultisig, STARK aggregation, and future precompiles) can port to XDC. The XDC PQ effort engages with the EF PQ team at pq.ethereum.org as a collaboration partner, so XDC benefits from that research base without duplicating it. #### Join the initiative Open to researchers, validators, enterprise clients, and institutional partners. Co-develop XDSS-PQ, contribute to the roadmap, or pilot PQ signatures on your subnet. [Contact the PQ Council →](mailto:pq@xdcindia.com) Attend the retreat EF Post-Quantum Research Retreat Cambridge, UK, Oct 9–12, 2026 [→ pq.ethereum.org](https://pq.ethereum.org) [→ github.com/leanEthereum](https://github.com/leanEthereum) [→ NIST FIPS 203/204/205/206](https://csrc.nist.gov/projects/post-quantum-cryptography) ### Building toward post-quantum-ready trade finance for the next century. Join the XDC PQ Initiative. Help build a post-quantum-ready, NIST-aligned standard for the world's enterprise trade-finance chain. [Explore the roadmap →](https://xdc.network/labs/quantum-roadmap/) [Get in touch](mailto:pq@xdcindia.com?subject=XDSS-PQ%20Initiative) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Reading Gidney’s 2025 RSA-2048 resource estimate URL: https://xdc.network/labs/reading-gidney-rsa-2048/ Last reviewed: 2026-10-22 The Labs article discusses a theoretical RSA-factoring estimate and its implications. It is not a demonstrated attack or a measurement of XDC signature security. > Article dated 15 August 2025; reviewed 22 October 2026. Gidney’s paper estimates RSA-2048 factoring resources under stated assumptions and a longer runtime than the earlier estimate. It does not demonstrate a cryptographic attack or measure the resources needed to break XDC’s secp256k1 signatures. Post-quantum · Research Aug 15, 2025 · By [Ritesh Kakkad](https://www.xdc.dev/riteshkakkad) · [← All posts](https://xdc.network/labs/blog/) Reading the 2025 Gidney result on RSA-2048 In one paragraph In 2025, Google Quantum AI researcher Craig Gidney published a resource estimate showing that a fault-tolerant quantum computer could factor a 2048-bit RSA key with **under one million noisy qubits** over several days — roughly **20× fewer qubits** than his own widely-cited 2019 figure of ~20 million. It is an **estimate, not a demonstrated attack**: no machine today comes close. But because XDC's secp256k1 ECDSA relies on elliptic-curve discrete logarithms, a different problem also vulnerable to Shor's algorithm, the steadily falling estimates are exactly why a post-quantum migration should begin before any working attack exists. ### What Gidney actually showed The headline of the 2025 preprint is a number: a fault-tolerant machine could factor RSA-2048 with **fewer than one million noisy physical qubits**, given several days of continuous operation. The improvement over the prior baseline is the real story — it comes from better algorithms and error correction, not a hardware breakthrough. <1M noisy qubits to factor RSA-2048 (2025 estimate) ~20M qubits in Gidney's 2019 estimate for the same task ~20× reduction in estimated qubits, in six years For context on the hardware gap: Google's **Willow** processor demonstrated 105 qubits with below-threshold error correction (Dec 2024), and IBM's **Condor** reached 1,121 physical qubits (Dec 2023). A cryptographically-relevant machine needs many thousands of error-corrected logical qubits — IBM targets 200 logical qubits for Starling in 2029 and 2,000 for Blue Jay in 2033+. The estimate and the hardware are still separated by orders of magnitude. The important caveat This is a resource **estimate**, not a demonstrated attack. No quantum computer today can run millions of high-quality qubits error-free for days. The result tells you where the goalposts are moving — not that the game is over. ### Why it matters for XDC RSA-2048 and the **secp256k1 ECDSA** used by XDC — and by Bitcoin and Ethereum — both rest on problems that [Shor's algorithm](https://xdc.network/labs/quantum-research/#section-2) solves in polynomial time. They are different problems (integer factoring vs. the elliptic-curve discrete logarithm), but a sharp drop in the estimated cost of one is a leading indicator for the other. When the factoring estimate falls 20× in six years, the prudent assumption is that the signature-forging estimate is on a similar trajectory. Not everything in XDC is exposed. The chain's **hash-based components — Keccak-256 addresses and state roots — remain quantum-safe**, because Grover's algorithm only offers a quadratic speedup against hashes, which is readily offset by output size. The exposed surface is **ECDSA**: the signatures that authorize transactions and, on a trade-finance chain, the signatures that prove a document's authenticity. ### The trajectory, not the number Fixating on "one million qubits" misses the point. The planning signal is the **direction of travel**: published estimates for breaking RSA- and ECC-class cryptography have fallen by roughly an order of magnitude in a few years. That pulls the planning horizon forward even though no cryptographically-relevant quantum computer (CRQC) exists yet. This is what **Mosca's theorem** formalizes: if the time to migrate (T) plus the lifetime your data must stay secure (L) exceeds the time until a CRQC arrives (Q), you are already late. For XDC's use case the numbers are stark — a migration takes an estimated 4–7 years, trade documents must stay valid for 20–30 years, and common CRQC estimates land at roughly 8–12 years out. **T + L comfortably exceeds Q.** For tokenized trade documents the risk has a name: **Trust-Now-Forge-Later**. An adversary does not need a quantum computer today — they only need to keep a copy of a signed document. When CRQCs arrive, every ECDSA-signed letter of credit or bill of lading on-chain becomes forgeable, decades after it was issued. ### What XDC does about it XDC's answer is **XDSS-PQ** — a post-quantum signature standard built on the NIST-selected algorithms (ML-DSA / FIPS 204 and the Falcon family), designed as a **hybrid** in which classical ECDSA and post-quantum signatures coexist throughout the transition. Hybrid migration is a design goal whose compatibility and security require implementation and testing. The full reasoning — Shor vs. Grover, the CRQC timeline table, and the migration phases — lives in the [technical deep-dive](https://xdc.network/labs/quantum-research/) and the [XDSS-PQ specification](https://xdc.network/labs/xdss-pq-spec/). ### Frequently asked Did a quantum computer break RSA-2048 in 2025? No. Gidney's 2025 paper is a resource estimate showing RSA-2048 could be factored with under one million noisy qubits over several days. It is not a demonstrated attack — no machine today comes close to millions of high-quality qubits running error-free for days. Is XDC Network at risk from this result? Not today, but it is a leading indicator. XDC's secp256k1 ECDSA signatures rest on the same Shor-vulnerable foundation as RSA. XDC's hash-based components — Keccak-256 addresses and state roots — remain quantum-safe; the exposed surface is ECDSA, which is why the XDSS-PQ standard adds NIST-selected post-quantum signatures. How much did the qubit estimate fall? About 20×. The 2025 estimate of under one million noisy qubits compares to Gidney's own 2019 figure of roughly 20 million qubits for the same RSA-2048 task — a reduction driven by algorithmic and error-correction improvements, not a hardware leap. ### Sources - Gidney, C. "How to factor 2048-bit RSA integers with less than a million noisy qubits." Google Quantum AI, 2025 (preprint). [arxiv.org/abs/2505.15917](https://arxiv.org/abs/2505.15917) - Gidney, C. & Ekerå, M. "How to factor 2048-bit RSA integers in 8 hours using 20 million noisy qubits." Quantum, 2021 — the 2019 baseline the 2025 estimate improves on. [arxiv.org/abs/1905.09749](https://arxiv.org/abs/1905.09749) - NIST Post-Quantum Cryptography — FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) RK Ritesh Kakkad Co-founder, XDC Network · writes on post-quantum security and trade finance ### Related reading [Deep-dive Quantum threats to XDC](https://xdc.network/labs/quantum-research/) [Spec XDSS-PQ signature standard](https://xdc.network/labs/xdss-pq-spec/) [Overview XDC Post-Quantum Initiative](https://xdc.network/labs/quantum/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDC RPC endpoints and network reference URL: https://xdc.network/labs/rpc/ Last reviewed: 2026-10-22 Explore endpoint definitions preserved from the Labs snapshot and optionally check selected responses. Listings and source privacy labels are not service guarantees. > This directory preserves source-reported endpoint and network metadata. Browser height and latency checks do not establish provider privacy, security or validator readiness. Unreachable may mean CORS or rate limiting. The net5050 and devnet entries are development environments; confirm their current chain configuration before use. Network & tools · RPC status Live RPC endpoints. Block height, latency, score & privacy, measured live from your browser, for every XDC network across all six clients: **legacy XDPoSChain · go-ethereum · Erigon · reth · Nethermind · Besu**. One click adds any network to MetaMask. Refreshes every 15s. Sort each network by online / at tip lagging offline / unreachable checking… no-track first-party / fleet tracks third-party (may log) Served via `open.xdcrpc.com` (per-client gateway) and public provider RPCs. Score = at-tip status + latency tier (5 = best). Privacy reflects whether the provider is a first-party / fleet node (**no-track**) or a public third party that may log requests (**tracks**). net5050 is a private mainnet-parity multi-client stress net (genesis, bootnodes & hardforks tracked internally). Height & latency are measured from your browser; a cell reads “offline” if the endpoint blocks CORS or is down. ### Network and endpoint reference These definitions are preserved from the source JavaScript configuration. Client roles and privacy labels are historical publisher descriptions, not verified uptime, validator status or privacy guarantees. #### XDC Network Chain ID 50 (0x32); XDC; 18 decimals. Explorer: [https://xdcscan.com](https://xdcscan.com). Endpoint | Source client label | Source role | Source type | Source privacy label | https://rpc.xinfin.network | XDPoSChain (legacy) | provider | full · public · legacy | tracks (source means provider may log) | https://open.xdcrpc.com/getha | go-ethereum (modern) | provider | archive · fleet | no-track (unverified source label) | https://new.xdcrpc.com | go-ethereum (modern) | provider | snap-full · fleet | no-track (unverified source label) | https://rpc.ankr.com/xdc | Ankr | provider | full · public | tracks (source means provider may log) | #### XDC Apothem Testnet Chain ID 51 (0x33); TXDC; 18 decimals. Explorer: [https://testnet.xdcscan.com](https://testnet.xdcscan.com). Endpoint | Source client label | Source role | Source type | Source privacy label | https://erpc.apothem.network | XDPoSChain (geth) | provider | archive · public | tracks (source means provider may log) | https://apothem.xdcrpc.com | XDPoSChain (geth) | provider | full · public | tracks (source means provider may log) | #### net5050 · Private Devnet Chain ID 5050 (0x13ba); XDC; 18 decimals. Explorer: [https://stats.xdcindia.com](https://stats.xdcindia.com). Multi-client stress net. Plus 4 legacy XDPoSChain producers with no public RPC (6 producers total). besu is funded+proposed but currently penalty-evicted (follower). See issue #1019. Endpoint | Source client label | Source role | Source type | Source privacy label | https://open.xdcrpc.com/gethrpc | go-ethereum | producer | validator · mint | no-track (unverified source label) | https://open.xdcrpc.com/erigonrpc | Erigon | producer | validator · mint | no-track (unverified source label) | https://open.xdcrpc.com/rethrpc | reth | follower | full · penalty-evicted | no-track (unverified source label) | https://open.xdcrpc.com/nethermindrpc | Nethermind | follower | full | no-track (unverified source label) | https://open.xdcrpc.com/besurpc | Besu | follower | full · tunnel | no-track (unverified source label) | #### XDC Devnet Chain ID 5551 (0x15af); XDC; 18 decimals. Explorer: [https://stats.xdcindia.com](https://stats.xdcindia.com). v2.8 fork canary: no public RPC. Self-host via the xdc.network installer (NETWORK=devnet). Config shown for Add-to-MetaMask against your own node (default http://localhost:8545). Endpoint | Source client label | Source role | Source type | Source privacy label | http://localhost:8545 | any (self-host) | selfhost | run your own | no-track (unverified source label) | #### Original status-score methodology Start at 3 if within four blocks of the highest observed endpoint; otherwise 1. Add 2 below 150 ms, or 1 below 400 ms. Maximum 5. Observation from browser only. Not provider uptime, privacy or consensus-security scoring. The source refresh interval was 15 seconds with a 7-second timeout. The new checker runs manually and displays actual responses or errors. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## The Labs XDC node installer guide URL: https://xdc.network/labs/run/ Last reviewed: 2026-10-22 The Labs source describes installer options, networks and client-specific restrictions. Review the script and current releases before running operational commands. > Installer capabilities below are source-reported as of this review. Geth is labeled Stable; Erigon and Nethermind Beta; XOne, Reth and Besu Experimental. Reth mainnet needs explicit experimental opt-in. The source says Besu cannot yet peer on net5050. Review the script, release and selected network before running commands. [Live now · join the running XDC mainnet nodes](https://xdc.network/labs/network-architecture/) XDC Network · Node Installer Run an XDC node in minutes — one command. **One command to the live chain.** Run a full XDC Network node with no build, no scp, no prerequisites but **curl**. It auto-detects your OS and CPU, pulls the sha256-verified geth binary, restores a recent snapshot, and starts syncing to **XDC mainnet (chainId 50)** — a fresh machine reaches the tip in **minutes**. Watch yours appear on the [live network status](https://xdc.network/labs/network-architecture/). bash — install xdc node `$curl -fsSL https://xdc.network/install.sh | bash` Prefer erigon, reth, besu or nethermind? Add `--client` — e.g. **sha256-verified** binary **~16 GB** snapshot (geth default) Linux · macOS · **amd64 · arm64** How it works ### Quick facts · what this installer does The XDC Network one-command node installer sets up and starts a geth-based XDC node on Linux or macOS. It auto-detects your OS and CPU, downloads a sha256-verified geth binary from xdc.network, restores a recent chain snapshot, and syncs to the live chain in minutes. Run this single command: ``` $ curl -fsSL https://xdc.network/install.sh | bash ``` Prerequisites curl only — no build, no scp, no toolchain. Platforms Linux and macOS, on amd64 (x86-64) or arm64 (aarch64). The build is auto-selected. Verification The geth binary is sha256-verified against the artifact published at xdc.network before it runs. Snapshot A recent ~16 GB chain snapshot is restored instead of replaying every block. Setup time Measured full setup was 5m 32s on a datacenter host: binary 1s, snapshot download 2m 58s, extract 1m 44s, then a short catch-up to the live chain tip. Networks XDC mainnet (chainId 50) by default; Apothem testnet (chainId 51), devnet, and the net5050 private multi-client devnet (chainId 5050) also available via `--network`. Other clients Add `--client xone|erigon|reth|besu|nethermind` to spin up a different client. Default (no flag) is always geth. See the client matrix for modes and readiness. Step-by-step Run `curl -fsSL https://xdc.network/one.sh -o one.sh`, then `bash one.sh setup` → `start` → `status`. ### Why it's fast · minutes, not days #### No build, no compile The installer downloads the matching prebuilt geth node binary for your exact OS and CPU. Nothing to scp, no toolchain to wait on. binary download · ~1s #### Verified, not trusted Every download is sha256-verified before it runs. You get the exact artifact published at xdc.network — checked, then executed. sha256 · checked #### Snapshot, not replay Instead of replaying years of blocks, it restores a recent ~16 GB chain snapshot, then catches up the last stretch to tip. 16 GB restore · 2m 58s ### What happens · measured on a datacenter host - 01 #### Detect host Reads your OS and CPU — Linux or macOS, amd64 or arm64 — and picks the matching build. instant - 02 #### Download binary Fetches the geth node binary from xdc.network and verifies its sha256. No compiling. 1s - 03 #### Restore snapshot Pulls a recent ~16 GB chain snapshot, integrity-checks it, then extracts the state. 2m 58s + 1m 44s - 04 #### Sync to tip Node boots near the head and runs a short catch-up to the live chain. Every stage prints its own timing. minutes, not days Full setup **5m 32s**  ·  binary 1s  ·  snapshot 2m 58s  ·  extract 1m 44s →  then a short catch-up to tip. ### Platform support · the right build, auto-selected OS × architecture OS \ CPU | amd64 (x86-64) | arm64 (aarch64) | Linux | Supported | Supported | macOS | Supported | Supported | Detection is automatic — the installer resolves `uname -s` / `uname -m` and pulls the matching `geth` build. XDC mainnet by default; apothem testnet also available. ### Choose your client · five ways to run XDC Client | Default mode | Supported modes | Networks | Snapshot | Status | `geth` | fast | fast · full · snap · archive | mainnet · apothem · devnet · net5050 | ✓ published | Stable | `xone` | snap | snap · full · archive · validator | mainnet · apothem · devnet · net5050 | not yet | Experimental | `erigon` | minimal | minimal · full · archive | mainnet · apothem · net5050 · devnet | not yet | Beta | `reth` | full | full | apothem · net5050 · mainnet​* | not yet | Experimental | `besu` | full | full | apothem · mainnet · net5050​† | not yet | Experimental | `nethermind` | fast | fast · full · archive | mainnet · apothem · net5050 · devnet | not needed (SnapSync) | Beta | `*` reth on mainnet requires `XDC_EXPERIMENTAL=1` or an interactive confirm — M20 consensus fixes are in progress. · erigon and reth have no published snapshot; first sync from genesis may take days — the installer prints an explicit time estimate and build-from-source pointer if the binary is not yet published. · besu requires Java 21+ (the installer prints a clear install hint if missing). · nethermind fast mode uses FastSync + SnapSync and reaches the tip without a published snapshot (hours, not days). · `†` `net5050` (chainId 5050) is a private multi-client devnet: the installer forces full-sync from genesis (small chain, ~15–40 min) and wires the net5050 validator peers. geth, xone and nethermind also report to [stats.xdcindia.com](https://stats.xdcindia.com); besu installs but cannot peer yet (XDPoS2 handshake port pending). #### One-liner per client Default `curl | bash` is unchanged — geth, fast, mainnet. Add `--client` for anything else. `$ curl -fsSL https://xdc.network/install.sh | bash` `$ curl -fsSL https://xdc.network/install.sh | bash -s -- --client erigon --mode minimal` `$ curl -fsSL https://xdc.network/install.sh | bash -s -- --client nethermind` `$ curl -fsSL https://xdc.network/install.sh | bash -s -- --client nethermind --network net5050` `$ curl -fsSL https://xdc.network/install.sh | bash -s -- setup --client besu --network apothem` `$ CLIENT=reth NETWORK=apothem ./one.sh start` `$ curl -fsSL https://xdc.network/install.sh | bash -s -- --client all` Passing `--client all` sets up and starts every supported client side-by-side. Each uses its own directory (`$HOME/xdc-node` for geth, `$HOME/xdc-node-` for others) and non-colliding port blocks. Clients whose binaries are not yet published degrade gracefully — the fleet continues with the remaining clients. Use `./one.sh --client all status` to print a fleet table showing running state, block height, and peer count for each client. ### Manual control · same binary, step by step #### Drive it yourself Prefer to see each stage? Download `one.sh` and run the phases by hand. ``` # 1 · download the manager $ curl -fsSL https://xdc.network/one.sh -o one.sh # 2 · run the phases $ bash one.sh setup $ bash one.sh start $ bash one.sh status ``` #### Node manager One script runs the whole lifecycle — `bash one.sh [--client ] `. `setup`Fetch the verified binary and restore the snapshot (geth); or prepare datadir for genesis sync (other clients). `start`Start the node; auto-fetches binary if missing. `stop`Stop the node safely. `restart`Stop, then start again. `status`Sync %, current block, peers, stage timings. `logs`Tail the live node log. `attach`Open the geth console (advanced, geth only). `clients`Print the per-client capability matrix (modes, networks, snapshot, status). Select client via env or flag — flags take precedence: ``` # env-style (existing pattern) $ CLIENT=reth NETWORK=apothem ./one.sh start $ NODETYPE=archive ./one.sh setup # geth archive # flag-style (new) $ ./one.sh --client erigon status $ ./one.sh --client besu --network apothem setup $ ./one.sh clients # print matrix ``` ### Node operator FAQ How do I run an XDC node? Run one command on Linux or macOS: `curl -fsSL https://xdc.network/install.sh | bash`. It auto-detects your OS and CPU, downloads a sha256-verified geth binary from xdc.network, restores a recent chain snapshot, and starts syncing to the live XDC chain. No build or scp is required. Which networks are supported? The installer sets up an **XDC mainnet** node (chainId 50) by default, and also supports the **Apothem testnet** (chainId 51). What are the system requirements? Linux or macOS on an amd64 (x86-64) or arm64 (aarch64) CPU. The only software prerequisite is `curl` — the installer downloads a prebuilt binary, so there is no build toolchain. Allow roughly **16 GB** or more of free disk for the chain snapshot plus headroom for ongoing chain growth. Full node or fast node? A snapshot-restored **fast node**. Instead of replaying every block from genesis, the installer restores a recent ~16 GB chain snapshot and then catches up the last stretch to tip. How long does it take, and is the binary safe? Measured full setup was **5m 32s** on a datacenter host (binary 1s · snapshot 2m 58s · extract 1m 44s) plus a short catch-up to tip — minutes, not days, because it restores a snapshot instead of replaying every block. Every download is **sha256-verified** against the artifact published at xdc.network before it runs. Can I run the installer step by step instead? Yes. Download the manager script: `curl -fsSL https://xdc.network/one.sh -o one.sh`, then run `bash one.sh setup`, `bash one.sh start`, and `bash one.sh status`. Other commands include `stop`, `restart`, `logs`, `attach`, and `clients`. Can I run a client other than geth? Yes — pass `--client erigon|reth|besu|nethermind` after `bash -s --`: `curl -fsSL https://xdc.network/install.sh | bash -s -- --client erigon --mode minimal`. The default (no flag) is always geth. **erigon** and **nethermind** are Beta; **reth** and **besu** are Experimental. Non-geth clients degrade gracefully if their binary is not yet published — the installer prints the exact URL it looked for, a build-from-source pointer, and a local-binary override hint, then exits without creating a half-populated data directory. Run `./one.sh clients` to print the full capability matrix. What sync modes are supported per client? Pass `--mode` to choose: **geth** supports fast (default), full, snap (experimental), and archive. **erigon** supports minimal (default, --prune.mode=minimal), full, and archive. **reth** supports full only. **besu** supports full only (XDPoS port validates from genesis). **nethermind** supports fast (default, FastSync+SnapSync — reaches tip without a snapshot), full, and archive. Clients without a published snapshot sync from genesis; the setup banner prints an honest time estimate up front. ### Live network [Network architecture live multi-client status](https://xdc.network/labs/network-architecture/) [Snapshots & binaries xdc.network/snapshots/ — verified downloads](https://xdc.network/snapshots/) [Estimate node hosting cost hosting-calculator.html — by role & provider](https://xdc.network/labs/hosting-calculator/) ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## Labs security and disclosure reference URL: https://xdc.network/labs/security/ Last reviewed: 2026-10-22 The Labs source explains its security approach and vulnerability-reporting route. Audit status, client resilience and disclosure contacts remain attributed to that publisher. > This reporting policy belongs to XDC Innovation Labs. Its audit status and disclosure contact must remain attributed to that publisher. Security Security posture & responsible disclosure. An honest statement of where XDC's infrastructure security stands today — open-source clients, resilience by client diversity, and a cryptographic audit that is **in progress, not finished**. We describe the posture, not promises. ### Security posture ⚙️ #### Open-source clients The XDC clients are public and auditable. Read, build, or review the source: [XinFinOrg/XDPoSChain](https://github.com/XinFinOrg/XDPoSChain) (XDPoS, Go) and the [Besu fork](https://github.com/XDCIndia/besu-xdc). 🛡️ #### Resilience by client diversity Four independent execution clients across three languages run mainnet. A defect or CVE in one implementation leaves the others serving the chain — network resilience still depends on validator distribution and consensus thresholds. [See the architecture →](https://xdc.network/labs/network-architecture/) 🔬 #### Cryptographic audit — in progress A cryptographic-surface audit and risk matrix are underway as **Phase 0 (Q2–Q3 2026)** of the post-quantum migration. This is roadmap work in progress; we make **no claim of a completed third-party audit**. [See the PQ roadmap →](https://xdc.network/labs/quantum-roadmap/) 🔐 #### Hybrid-first migration Every post-quantum phase runs classical and PQ signatures in parallel, so no migration step requires a hard cutover. The standard (XDSS-PQ) builds on NIST-selected algorithms. [Explore the initiative →](https://xdc.network/labs/quantum/) #### Reporting a vulnerability If you believe you've found a security issue in XDC Innovation Labs' infrastructure or the XDSS-PQ work, please report it privately to `pq@xdcindia.com` rather than opening a public issue. Include enough detail to reproduce, and give us reasonable time to investigate and remediate before any public disclosure. We'll acknowledge receipt and keep you updated. This page states the current, verifiable posture only. It deliberately makes no claims of completed audits, named audit firms, bug-bounty prize pools, or findings — those do not exist yet and the audit work is tracked transparently on the [roadmap](https://xdc.network/labs/quantum-roadmap/). ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XDSS-PQ: a draft trade-document signature design URL: https://xdc.network/labs/xdss-pq-spec/ Last reviewed: 2026-10-22 Read the Labs June 2026 draft proposing ML-DSA and Falcon signatures for trade documents. It is not a certified product, finalized protocol or activated network upgrade. > June 2026 draft, reviewed 22 October 2026. This is not a shipped product, certification or activated protocol. Parameter sets, canonical encoding, key registration and revocation need implementation-level definition. The example’s compliance tags are declarations, not evidence. Falcon-based FIPS 206 remains in development. Specification · Draft · forward-looking XDSS-PQ — Post-Quantum Trade-Document Signature Standard ● Draft v1.0 June 2026 · Status: forward-looking / in development · Aligned with NIST FIPS 203/204/205/206 [XDSS-PQ on the Quantum page →](https://xdc.network/labs/quantum/#xdss) **Draft & forward-looking.** This is a Draft v1.0 specification describing a standard under active development. Algorithm parameters, schema fields, and timelines are subject to change as NIST standards finalise (notably FIPS 206) and as the design is reviewed. It is not a guarantee of any future product, certification, or outcome. Abstract XDSS-PQ is a proposed post-quantum signature standard for long-lived trade-finance documents on the XDC Network. It binds a document to **two independent NIST-aligned post-quantum signatures** — **ML-DSA** (FIPS 204) and **Falcon / FN-DSA** (FIPS 206 in development) — under **AND semantics**: a document is valid only if **both** signatures verify. The intended combined protection depends on secure composition, key handling and implementation, as well as the security of the algorithms. The standard targets the 20–30 year legal validity window of instruments such as bills of lading and letters of credit, and is designed to remain verifiable and unforgeable long after any cryptographically-relevant quantum computer (“Q-Day”) arrives. This document defines the motivation, threat model, algorithm choices, document schema, and a hybrid migration path. Contents - Abstract & status - Motivation - Threat model - Algorithm choices - Document schema - Migration & hybrid signing - Standards alignment - References ### 1 Status of this document This is a **Draft v1.0**, dated June 2026, published for discussion within the XDC ecosystem and the broader community. It is **forward-looking**: it describes a standard and reference design that are still being developed, not a shipped or certified product. Where it references draft standards (in particular FIPS 206 / FN-DSA), those underlying specifications may still change. Terms such as “must” and “should” describe the intended behaviour of conforming implementations of this draft, not a legal obligation. ### 2 Motivation Trade-finance instruments are unusual among signed digital artefacts: their **legal lifespan is measured in decades**. A bill of lading or letter of credit signed today may need to be presented, audited, or contested **20 to 30 years** from now. The cryptography that authenticates such a document must therefore remain trustworthy across that entire horizon. Classical signatures (ECDSA over secp256k1) do not offer that guarantee against a future quantum adversary. This creates a **Trust-Now-Forge-Later (TNFL)** exposure: a document trusted and relied upon today could, after a sufficiently capable quantum computer exists, be **retroactively forged** — for example to assert false ownership of the underlying goods or receivable. Because the document’s value persists for decades, the risk cannot be deferred; instruments signed now are already within the exposure window. XDSS-PQ exists to remove that exposure for the documents that matter most, using **only NIST-aligned, openly specified algorithms** — so the standard can be independently reviewed and adopted as a reference, rather than depending on proprietary cryptography. ### 3 Threat model XDSS-PQ is designed against the following adversary and assumptions: - **Future quantum adversary.** An attacker who, at some point within the document’s validity window, gains access to a cryptographically-relevant quantum computer capable of running Shor’s algorithm against the elliptic-curve and RSA problems. Public 2025 resource-estimate research has **materially lowered** the estimated quantum resources required to break RSA-2048, reinforcing the case for migrating well ahead of any fixed “Q-Day” (see References). - **Harvest-now / forge-later.** The adversary may record documents and public keys today and act on them years later. Defences must protect documents signed **before** the adversary becomes capable. - **Single-algorithm cryptanalysis.** A post-quantum scheme that is standardised today may later be weakened by classical or quantum cryptanalysis. The design must not collapse if **one** chosen PQ algorithm is broken. - **Out of scope.** Endpoint key theft, social-engineering of signers, compromise of the issuing organisation’s processes, and the integrity of off-chain physical goods are outside the cryptographic scope of this standard, though deployments should address them operationally. Hash functions (Keccak-256 / SHA-3) are treated as quantum-resistant; Grover’s algorithm yields only a quadratic speed-up and does not break them. The central design response to single-algorithm cryptanalysis is the **hybrid AND construction** described next. ### 4 Algorithm choices XDSS-PQ binds each document with **two** independent post-quantum signatures over the same canonical payload: XDSS-PQ signature algorithms Role | Algorithm | Standard | Sig size | Why | **Primary** | ML-DSA (Dilithium) | **FIPS 204** | ~2.4 KB | NIST’s primary lattice signature standard; among the best-audited PQ signature schemes. | **Compact** | Falcon / FN-DSA | **FIPS 206** (draft) | ~666 B | The most compact NIST-track PQ signature; a different lattice construction from ML-DSA, giving algorithm diversity. | The two algorithms are deliberately **different constructions**, so that a cryptanalytic advance against one is unlikely to apply to the other. #### 4.1 AND semantics — both_required 🔗 **A document is valid only if BOTH the ML-DSA signature AND the Falcon signature verify.** Forging a document therefore requires breaking **both** signature schemes under the stated cryptographic assumptions simultaneously — not just one. The security of XDSS-PQ holds unless **both** schemes are broken. Formally, for a document `D` with signatures `s_mldsa` and `s_falcon` over the canonical encoding of `D`: - `valid(D) = verify_mldsa(pk_mldsa, D, s_mldsa) **AND** verify_falcon(pk_falcon, D, s_falcon)` - If **either** verification fails, the document is **invalid**. There is no fallback to a single signature. The both-required rule is intended to retain unforgeability when one signature scheme remains secure. This depends on sound composition, uncompromised keys and correct implementation; the draft is not an unconditional security guarantee. ### 5 Document schema An XDSS-PQ document is a JSON object that carries the issuer reference, the dual signatures, the explicit `both_required` rule, the validity window, and compliance declarations. The schema below mirrors the reference example published on the XDC Quantum page: xdss-pq/v1.0 · trade document schemaDRAFT EXAMPLE { "standard": "XDSS-PQ/1.0", "document_type": "bill_of_lading", "issuer": "xdc://0xA3f2...91CC", "payload_hash": "keccak256:0x…", "signatures": { "ml_dsa": "", "falcon": "", "scheme": "hybrid-dual-sig", "valid_if": "both_required" }, "valid_until": "2058-12-31", "compliance": ["EU-PQC-2030", "NIST-FIPS", "MLETR"] } #### 5.1 Field semantics - `standard` — the XDSS-PQ version identifier. - `document_type` — the instrument class (e.g. `bill_of_lading`, `letter_of_credit`). - `issuer` — the on-chain identity of the issuing party. - `payload_hash` — a quantum-resistant hash (Keccak-256) binding the signatures to the exact document content. - `signatures.ml_dsa` / `signatures.falcon` — the two PQ signatures over the canonical payload. - `signatures.valid_if` — **must** be `both_required`; a verifier rejects any other value or a missing signature. - `valid_until` — the intended validity horizon (a decades-long window). - `compliance` — declarative alignment tags (e.g. EU PQC 2030, NIST FIPS, MLETR). A document is accepted only when both signatures verify against the issuer’s registered keys and `valid_if` equals `both_required`. ### 6 Migration & hybrid signing XDSS-PQ is intended to be adopted **without disruption** to existing issuance flows, using a phased, additive path: - **Hybrid issuance.** New documents are signed with the dual ML-DSA + Falcon scheme from day one, while existing classical workflows continue in parallel where required for interoperability. - **Key registry.** Issuer PQ public keys are published to an on-chain key registry so any verifier can independently check both signatures. - **Verification precompiles.** ML-DSA and Falcon verification are expensive in the EVM without native support; dedicated precompiles are planned to make on-chain verification economically practical. This mirrors Ethereum’s PQ precompile research, which XDC’s EVM compatibility allows it to adopt rather than rebuild. - **Long-term verifiability.** Because validity depends on the two PQ signatures and a quantum-resistant hash, an XDSS-PQ document signed in, say, 2028 is designed to remain verifiable and unforgeable through its `valid_until` date — long after Q-Day. This standard addresses **trade-document** signing specifically. Related migrations on the XDC Network — validator signing (Falcon for XDPoS), wallet keys (ML-DSA), and transport security (ML-KEM hybrid TLS) — are described in the broader [PQ migration roadmap](https://xdc.network/labs/quantum-roadmap/) and are complementary to, but separate from, this document. ### 7 Standards alignment XDSS-PQ is built on, and declares alignment with, the following: - **NIST FIPS 203** (ML-KEM) — for the hybrid transport security that protects documents in transit. - **NIST FIPS 204** (ML-DSA) — the primary document signature. - **NIST FIPS 205** (SLH-DSA) — a conservative hash-based option referenced for high-value governance contexts in the wider roadmap. - **NIST FIPS 206** (FN-DSA / Falcon, draft) — the compact second document signature. - **MLETR** — the UNCITRAL Model Law on Electronic Transferable Records, for legal recognition of electronic trade documents. - **EU PQC roadmap (2030)** and **NIST IR 8547 (2035 deprecation)** — as forward-looking regulatory targets the standard is designed to meet ahead of time. ### 8 References - NIST, FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM), 2024. [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - NIST, FIPS 204 — Module-Lattice-Based Digital Signature Standard (ML-DSA), 2024. [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - NIST, FIPS 205 — Stateless Hash-Based Digital Signature Standard (SLH-DSA), 2024. [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - NIST, FIPS 206 — FFT over NTRU-Lattice-Based Digital Signature Standard (FN-DSA / Falcon), draft. [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - NIST, IR 8547 — Transition to Post-Quantum Cryptography Standards (ECDSA and other quantum-vulnerable algorithms deprecated by 2035). [csrc.nist.gov/projects/post-quantum-cryptography](https://csrc.nist.gov/projects/post-quantum-cryptography) - C. Gidney (Google Quantum AI), 2025 resource-estimate research substantially lowering the estimated quantum resources to factor RSA-2048 (reported as roughly a 20× reduction versus prior estimates); summarised in Google Research, “Safeguarding Cryptocurrency by Disclosing Quantum Vulnerabilities Responsibly.” [research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly](https://research.google/blog/safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly/) Cited qualitatively; exact hardware figures remain subject to active research. - R. Kakkad, “XDC Network’s Quantum-Proof Future” (quantum threat landscape for XDC’s institutional focus), 19 March 2024. [xdc.dev — Ritesh Kakkad, 2024](https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9) - XinFinOrg, XDPoSChain — `poc_falcon` branch (Falcon block signing & QC verification proof-of-concept; ~666-byte signatures), August 2025. [github.com/XinFinOrg/XDPoSChain/tree/poc_falcon](https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon) - UNCITRAL, Model Law on Electronic Transferable Records (MLETR), 2017. **Forward-looking notice.** Dates, parameters, and regulatory-alignment targets in this draft are goals and estimates, not guarantees. “Q-Day” references describe probabilities, not fixed dates. This document will be revised as standards finalise and review proceeds. ### About this source Publisher: XDC Innovation Labs. Contact: [pq@xdcindia.com](mailto:pq@xdcindia.com). This source-specific contact is separate from the replacement website operator. --- ## XinFin (legacy xinfin.org content) Legacy xinfin.org content is hosted as a separate sub-site: https://xdc.network/xinfin/ (sitemap: https://xdc.network/xinfin/sitemap.xml).