XDC Network XDC

Claim: XDC has published a comprehensive cryptographic inventory and quantum threat model covering ECDSA (secp256k1) usage in transactions, consensus, bridges, P2P, and smart contracts, with attack assumptions and affected layers.

Coverage basis: Official documentation and research publications

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Primary sources are official XDC Innovation Labs publications and community research posts. Threat model is detailed and publicly accessible.

The quantum threat research page maps every cryptographic surface to attack type, severity, and time window. The FAQ answers 26 questions covering ECDSA vulnerability, NIST PQC standards, migration strategy, and regulatory compliance.

• https://xdc.network/quantum-research.html
• https://xdc.network/quantum-faq.html
• https://xdc.network/quantum-roadmap.html
• https://www.xdc.dev/riteshkakkad/xdc-networks-unbreakable-future-exploring-area-of-quantum-proof-blockchain-research-47e9

Claim: Evidence record includes code references (XDPoSChain GitHub), specification documents (whitepaper, block structure docs), audit reports (XDPoSChain security audit, CertiK XDC 2.0 audit), transaction examples (xdcscan.io), and reproducible PoC benchmarks.

Coverage basis: Multiple primary-source artifacts

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: Classical audit is undated/stale; CertiK audit is current (2024) but covers classical security only. Evidence is nevertheless sufficient to verify the classical ECDSA-only production state from primary code and documentation.

The evidence dossier and web search confirm consistent findings across code, specs, audits, and explorer: all production cryptography is classical ECDSA/secp256k1.

• https://github.com/XinFinOrg/XDPoSChain
• https://xinfin.org/docs/whitepaper-tech.pdf
• https://xinfin.org/docs/reports/xdposchain-security-audit-report.pdf
• https://www.xdc.dev/gary/block-structure-in-xdc-20-2lo8
• https://xdcscan.com/

Claim: All XDC mainnet transactions use ECDSA (secp256k1) signatures. No PQC or hybrid-PQC transaction types exist in production.

Coverage basis: Production mainnet code and transaction format

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production spend authorization remains entirely ECDSA (secp256k1) — all transaction signatures are quantum-vulnerable.

Assurance: Confirmed by GitHub source code (secp256k1 crypto package, keystore), official FAQ acknowledgment, audit report, and mainnet explorer showing standard EVM transaction formats.

The XDC PQ FAQ explicitly states: 'XDC currently uses ECDSA (secp256k1) for transaction signatures.' Hybrid wallets (ECDSA + ML-DSA) are planned for Phase 1 (2027).

• https://github.com/XinFinOrg/XDPoSChain
• https://xdcscan.com/
• https://xdc.network/quantum-faq.html
• https://xinfin.org/docs/reports/xdposchain-security-audit-report.pdf

Claim: XDC uses standard EVM-style addresses (Keccak-256 hash of public key). Public keys are exposed on-chain when an account sends a transaction, creating long-exposure quantum-vulnerable surfaces for all transacted accounts.

Coverage basis: EVM-compatible address derivation

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Address format and public-key exposure follow standard Ethereum patterns, confirmed by explorer and codebase.

Accounts that have never sent transactions have no exposed public key (only address hash). However, all transacted accounts have long-exposure ECDSA public keys visible on-chain, including treasuries, bridges, exchanges, and foundation wallets. No PQ/hybrid address scheme or key-derivation design exists in production.

• https://xdcscan.com/
• https://github.com/XinFinOrg/XDPoSChain
• https://xdc.network/quantum-faq.html

Claim: XDPoS 2.0 consensus uses ECDSA (secp256k1) for block proposer signatures, quorum certificate signatures, and validator votes. No PQC or hybrid-PQC consensus authentication exists in production.

Coverage basis: XDPoS 2.0 block structure specification and mainnet code

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: Active production consensus authentication (XDPoS 2.0 block signing, quorum certificates, validator votes) remains entirely ECDSA (secp256k1).

Assurance: Block structure documentation explicitly confirms: 'The signature is secp256k1, which is currently used in XDPoS 1.0' and carried forward into XDPoS 2.0. Whitepaper confirms ECDSA for masternode authentication.

Falcon (FIPS 206) validator signing is planned for Phase 3 (Q1 2029 – Q4 2030) with a 12-month dual-signing transition. PoC exists on poc_falcon branch but is not deployed to mainnet or testnet.

• https://www.xdc.dev/gary/block-structure-in-xdc-20-2lo8
• https://github.com/XinFinOrg/XDPoSChain
• https://xinfin.org/docs/whitepaper-tech.pdf
• https://xdc.network/quantum-roadmap.html

Claim: Core state integrity uses Keccak-256 based Merkle Patricia tries (quantum-safe for collision resistance). XDC v2.6.8 (activated January 2026) introduced KZG/blob cryptography for data availability — a pairing-based, quantum-vulnerable primitive.

Coverage basis: Protocol design analysis and v2.6.8 release notes

Implementation score: 0.75 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Quantum blocker: XDC v2.6.8 introduced KZG/blob cryptography (pairing-based, quantum-vulnerable) into production for data availability.

Assurance: v2.6.8 release notes explicitly list 'Blob & KZG cryptography support' and 'Support KZG cryptography and blob handling' as production features. Core block hashing and state roots remain Keccak-based (quantum-safe).

KZG is quantum-vulnerable (pairing-based). Blob data is transient (pruned after ~18 days per Ethereum EIP-4844 equivalent design), so KZG does not secure long-lived consensus state. However, any L2/rollup depending on XDC blob DA would face quantum settlement forgery risk. The PQ roadmap addresses KZG/SNARKs in Phase 2 (STARKs-only policy for new ZK deployments, Q3 2027).

• https://github.com/XinFinOrg/XDPoSChain/releases/tag/v2.6.8
• https://www.xdc.dev/anilchinchawale/xdc-network-v268-the-cancun-upgrade-goes-live-on-mainnet-b7o
• https://xdc.network/quantum-faq.html

Claim: XDC Network has no native privacy features (no shielded pools, no confidential transactions, no ZK privacy at protocol level). EVM-compatible smart contracts can deploy privacy solutions, but these are application-layer, not protocol-native.

Coverage basis: Protocol architecture

Implementation score: 1 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Subnets (introduced in XDC 2.0) provide private blockchain instances with separate validator sets, but these are segregated networks, not privacy-preserving cryptography on the public mainnet.

• https://docs.xdc.network/xdcchain/xdpos/
• https://xdc.org/articles/xdc-2.0-an-overview-of-the-major-consensus-upgrade

Claim: XDC uses devp2p (Ethereum-compatible) for P2P networking with ECDSA node keys and ECDH key exchange. No PQ-TLS or hybrid key exchange is deployed on mainnet.

Coverage basis: devp2p protocol and v2.6.8 release notes

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: P2P node identity is not directly consensus-critical (separate from validator keys), but enables harvest-now-decrypt-later on masternode communications and potential node impersonation. PQ-TLS (ML-KEM768 + X25519 hybrid) is planned for Phase 1 (Q4 2026).

While P2P node identity is not spend-authorization-critical, it is applicable per the spec. The quantum roadmap correctly prioritizes PQ-TLS as Phase 1 (addressing the only active-today quantum threat of harvest-now-decrypt-later).

• https://github.com/XinFinOrg/XDPoSChain/releases/tag/v2.6.8
• https://xdc.network/quantum-roadmap.html

Claim: No production wallet, custody, HSM, or hardware-wallet workflow supports PQ or hybrid-PQ signing on XDC mainnet. All wallet tooling uses ECDSA exclusively.

Coverage basis: Production wallet ecosystem

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Evidence is indirect — no explicit audit of wallet/custody PQ support exists because no PQ support exists. The FAQ confirms hybrid wallets are planned for Phase 1 (2027). BitGo custody integration (February 2026) is classical only.

The PQ FAQ states: 'Upgrade your wallet software when Phase 1 releases (2027). The wallet will automatically generate PQ keys and dual-sign.' No PQ wallet, custody, or HSM path is available to production users today.

• https://xdc.network/quantum-faq.html
• https://xdc.network/quantum-roadmap.html

Claim: 0% of XDC value-at-risk is protected by PQ mechanisms in production. All native XDC in all account types (EOAs, contracts, treasuries, bridges, exchanges, staked masternode collateral) remains ECDSA-secured with no hybrid or PQ fallback.

Coverage basis: Production mainnet state as of June 2026

Implementation score: 0.05 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Coverage is scored at <25% (implementation score 0.05) per QRI coverage thresholds. XDC is not PQ-native; it launched with classical ECDSA ownership and all value remains in ECDSA-secured accounts.

The XDC FAQ claims ~0.1% public-key exposure, suggesting most addresses have never transacted. However, this refers to key exposure, not migration coverage. All value — including value in addresses with unexposed keys — remains secured only by ECDSA and would be vulnerable once quantum attack capability exists.

• https://xdcscan.com/
• https://xdc.network/quantum-faq.html
• https://xdc.network/quantum-roadmap.html

Claim: No critical wallets (treasuries, exchanges, custodians, bridges, foundations, masternode collateral) have been migrated to PQ or hybrid-PQ protection. All remain ECDSA-only.

Coverage basis: Production mainnet state

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: No PQ migration attestations from any exchange, custodian, or institutional holder exist because the PQ migration has not begun. BitGo custody integration (Feb 2026) is classical-only.

The roadmap targets bridge admin keys → hybrid ECDSA+ML-DSA in Phase 1 (Q4 2026–Q2 2027) and XDC DAO governance keys → hybrid ECDSA+SLH-DSA in the same phase. No critical wallet migration has occurred yet.

• https://xdc.network/quantum-faq.html
• https://xdcscan.com/

Claim: XDC's quantum threat research identifies ECDSA-vulnerable surfaces across all layers, but no formal measurement, deprecation, freeze, or burn mechanism for legacy vulnerable accounts exists in production.

Coverage basis: Quantum threat research and roadmap documentation

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: quantum-critical uncertainty · Score treatment: score-reducing

Assurance: Identification exists at the assessment level (all ECDSA surfaces catalogued). No production measurement system, on-chain registry of vulnerable accounts, or deprecation policy is active.

The 5-phase roadmap includes ECDSA deprecation only in Phase 4 (2032–2035), after >95% network upgrade. No freeze/burn/salvage policy for unmigratable dormant or lost accounts has been published.

• https://xdc.network/quantum-research.html
• https://xdc.network/quantum-roadmap.html
• https://xdc.network/quantum-faq.html

Claim: XDC has published a detailed 5-phase quantum-safe migration roadmap (2026–2035) with specific algorithm choices, activation criteria, governance gates, and dependency mapping.

Coverage basis: Official roadmap publication on xdc.network

Implementation score: 0.25 · Evidence confidence: High

Issue classification: none · Score treatment: confidence-only

Assurance: The roadmap is one of the most detailed publicly available — includes Gantt chart, phase gates, algorithm selection rationale, governance checkpoints, regulatory deadline anchors (CNSA 2.0 2027, EU PQC 2030, NIST IR 8547 2035), and dependency mapping. However, it remains a roadmap (Implementation Score 0.25) with no production deployment.

Phase 0 (active): cryptographic surface audit, risk matrix, security council, community vote. Phase 1 (Q4 2026): PQ-TLS, bridge admin key migration. Phase 2 (Q3 2027): EVM precompiles, account abstraction. Phase 3 (Q1 2029): Falcon validator signing. Phase 4 (2032–2035): ECDSA deprecation.

• https://xdc.network/quantum-roadmap.html
• https://xdc.network/quantum-faq.html
• https://www.xdc.dev/gary/securing-xdc-with-post-quantum-signatures-2j86

Claim: No PQ/hybrid account creation, wallet tooling, transaction paths, custody paths, user-facing warnings, or migration prompts exist in production. All user-facing infrastructure remains ECDSA-only.

Coverage basis: Production ecosystem as of June 2026

Implementation score: 0 · Evidence confidence: High

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: Explorer, wallet ecosystem, and documentation all confirm ECDSA-only transaction paths. The FAQ explicitly states wallet upgrades will be available in Phase 1 (2027).

Users can still create new quantum-vulnerable ECDSA accounts by default with no warning. Account abstraction (XIP-AA) is planned for Phase 2 (Q3 2027) to enable in-place wallet upgrades without moving funds.

• https://xdcscan.com/
• https://xdc.network/quantum-faq.html

Claim: No enforcement mechanisms (deprecation, freeze, disabled legacy signing, restricted withdrawals, mandatory migration deadlines) are active in production. No exchange, custody, bridge, or wallet coordination for PQ migration has occurred.

Coverage basis: Production protocol rules

Implementation score: 0 · Evidence confidence: Medium

Issue classification: quantum-critical vulnerability · Score treatment: score-reducing

Assurance: The roadmap includes governance checkpoints (XIP votes at each phase gate) and an 18-month ECDSA sunset notice period (Phase 4), but none of these mechanisms are active.

The hybrid-first design (classical and PQ signatures coexist) means enforcement can be gradual, but the absence of any active enforcement mechanism means 100% of value remains on quantum-vulnerable paths.

• https://xdc.network/quantum-roadmap.html
• https://xdc.network/quantum-faq.html

Claim: XDC has general security incident response processes (demonstrated in KYC/KYB incident handling and upstream CVE analysis). The PQ FAQ documents emergency hard fork procedures for PQ algorithm break scenarios. No formal quantum-specific incident-response playbook exists.

Coverage basis: Published incident responses and roadmap documentation

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: General security incident response capability is evidenced. Quantum-specific planning is documented in the FAQ (SLH-DSA fallback activation via emergency hard fork). No formal, tested quantum-specific IR playbook. Not score-reducing per Section 8.2 — recorded as an assurance note.

The FAQ describes: 'If lattice-based crypto gets broken: 1. XDC activates SLH-DSA via emergency hard fork. 2. Validators roll back to ECDSA temporarily while SLH-DSA integrates. 3. Community chooses next-gen PQ algorithm.' This is documented planning but has never been exercised.

• https://www.xdc.dev/omkar_mestry_737f5f43d6e1/security-update-kyckyb-document-accessibility-incident-fully-resolved-1lb3
• https://www.xdc.dev/sina/analysis-of-upstream-security-advisories-12m0
• https://xdc.network/quantum-faq.html
• https://www.xdc.dev/walterblueu/xdc-network-issue-reporting-process-jm8

Claim: XDC's PQ strategy uses NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), and FIPS 206 (Falcon/FN-DSA). Falcon PoC implements FIPS 206 Falcon-512/1024.

Coverage basis: Roadmap specification and PoC implementation

Implementation score: 0.5 · Evidence confidence: High

Issue classification: none · Score treatment: not applicable

Assurance: All four NIST FIPS standards are correctly identified with appropriate use cases. Falcon (FIPS 206) for validator consensus (bandwidth-constrained), ML-DSA (FIPS 204) for user wallets, SLH-DSA (FIPS 205) for governance fallback, ML-KEM (FIPS 203) for TLS.

Implementation Score 0.50 reflects prototype status — algorithms are selected and prototyped but not deployed in production. The roadmap also correctly identifies mathematical diversity (lattice-based + hash-based fallback).

• https://xdc.network/quantum-faq.html
• https://xdc.network/quantum-roadmap.html
• https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon
• https://github.com/XDCInnovationLabs

Claim: No independent cryptographic audit of any PQ implementation (Falcon PoC, planned ML-DSA, SLH-DSA, hybrid construction) has been published. Existing audits cover classical ECDSA only.

Coverage basis: Audit coverage gap

Implementation score: 0 · Evidence confidence: Medium

Issue classification: assurance-only caveat · Score treatment: confidence-only

Assurance: No PQ audit exists because no PQ code is in production. The XDPoSChain audit and CertiK audit cover classical crypto only. Phase 0 roadmap includes a full cryptographic surface audit (in progress, not yet published). Phase 3 roadmap includes a final independent security audit of the complete PQ migration.

The PQ roadmap explicitly includes 'Independent security audit — final' in Phase 3 (Q1 2029–Q4 2030) with formal verification using Lean 4 framework.

• https://xinfin.org/docs/reports/xdposchain-security-audit-report.pdf
• https://xdc.org/articles/xdc-2.0-an-overview-of-the-major-consensus-upgrade

Claim: Falcon PoC is open-source on the poc_falcon branch of XDPoSChain GitHub repository with reproduction instructions. XDCInnovationLabs GitHub demonstrates Falcon integration with XDPoS consensus.

Coverage basis: Public GitHub repositories

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: PoC code is publicly available with reproduction instructions. However, this is prototype-grade code (not production-hardened, not audited, not on testnet/mainnet).

The community proposal provides step-by-step reproduction instructions and benchmark results. Code compiles and runs but is isolated from the main branch and not integrated into any release.

• https://github.com/XinFinOrg/XDPoSChain/tree/poc_falcon
• https://github.com/XDCInnovationLabs
• https://www.xdc.dev/gary/securing-xdc-with-post-quantum-signatures-2j86

Claim: XDC roadmap documents algorithm selection rationale, hybrid coexistence design, fallback procedures for algorithm breaks, and governance-controlled upgrade paths.

Coverage basis: Roadmap and FAQ documentation

Implementation score: 0.25 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: Documented planning only (Implementation Score 0.25). The hybrid-first design inherently provides parameter agility since either classical or PQ validation is acceptable during transition.

The FAQ explicitly addresses algorithm break scenarios: activate SLH-DSA via emergency hard fork, roll back validators to ECDSA temporarily, community selects next-gen algorithm.

• https://xdc.network/quantum-roadmap.html
• https://xdc.network/quantum-faq.html

Claim: XDC selected Falcon (stateless) for validator consensus and ML-DSA (stateless) for wallets, avoiding stateful-signature pitfalls of XMSS/LMS.

Coverage basis: FAQ and roadmap algorithm selection documentation

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: All selected PQ algorithms are stateless (Falcon, ML-DSA, SLH-DSA), avoiding the state-management risks of XMSS/LMS. However, no formal side-channel analysis has been published.

No stateful signatures (XMSS/LMS) are planned. The stateless design choice is appropriate for a blockchain with high transaction volume.

• https://xdc.network/quantum-faq.html
• https://xdc.network/quantum-roadmap.html

Claim: XDC has published detailed performance benchmarks comparing ECDSA, Falcon-512, ML-DSA-65, and SLH-DSA-128s for signature size, verification speed, and bandwidth impact on XDPoS 2.0's 108-validator gossip network.

Coverage basis: FAQ benchmarks and community PoC results

Implementation score: 0.5 · Evidence confidence: Medium

Issue classification: none · Score treatment: not applicable

Assurance: FAQ includes comparative table, verification speed benchmarks, and bandwidth calculations. PoC benchmarks confirm block verification at 0.138ms for Falcon.

Performance analysis is thorough for the prototype phase. Production-scale benchmarks under realistic mainnet conditions are pending.

• https://xdc.network/quantum-faq.html
• https://www.xdc.dev/gary/securing-xdc-with-post-quantum-signatures-2j86