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.
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.
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 yrtrade documents legally valid to ~2056
- Y, migration time~4 yraudit → infrastructure → consensus cutover
- Z, time to Q-Dayest. 5–10 yrexpert median; wide uncertainty
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.
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.
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 lifespanValidator 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 keysBridge & 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, indefiniteEOA 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 pubkeysP2P 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 nowHash 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 actionXDC'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.
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›
ML-DSA / Dilithium (FIPS 204), EOA wallets›
XDSS-PQ hybrid (FIPS 204 + 206), trade documents›
SLH-DSA / SPHINCS+ (FIPS 205), DAO governance›
ML-KEM + X25519 hybrid TLS (FIPS 203), all nodes›
Hybrid parallel scheme, zero disruption›
QKD for critical masternode links›
STARKs over SNARKs for all new ZK deployments›
Recursive STARK aggregation for consensus›
EVM precompiles, gas optimisation›
| 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.
Falcon consensus proof of concept
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.
Gary's 3-layer migration analysis
"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 →Ritesh's quantum threat landscape
"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 →Among the few chains with working PQ consensus code
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.
Every XDC layer is on the quantum-hardening roadmap
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.
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.
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.
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.
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.
Four phases, 2026 to 2030
A structured migration with governance checkpoints, community votes, and independent audits at each phase gate. No surprise migrations.
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.
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.
Phase 0 items marked ✓ are underway; ★ items and later phases are the active plan. The consensus migration is targeted to complete by 2030.
poc_falcon branch in XinFinOrg/XDPoSChain implements Falcon validator signing. 0.138 ms verification, 666 B signatures, working code, not a whitepaper.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.
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.
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."
Common questions
When will quantum computers actually break ECDSA?+
Why is XDC's exposure longer-lived than most chains?+
Will the PQ migration disrupt XDC users or validators?+
Why Falcon for XDPoS 2.0 validators, not Dilithium?+
What exactly is XDSS-PQ and why does it matter strategically?+
How does XDC benefit from Ethereum's PQ research?+
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 →Cambridge, UK, Oct 9–12, 2026
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.
About this source
Publisher: XDC Innovation Labs. Contact: pq@xdcindia.com. This source-specific contact is separate from the replacement website operator.
Repository snapshot d2345a8 · Source content and historical measurements are attributed to XDC Innovation Labs. Links to independently operated services remain with their providers.