Post-Quantum Security | XDC Innovation Labs

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

EU PQC mandate, December 2030, the binding deadline for XDC's regulated trade-finance partners. The date we can plan to, while Q-Day itself stays uncertain.

days to CNSA 2.0NSA PQC mandate, Jan 2027

days to NIST ECDSA sunsetIR 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 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

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

Trade-finance documents have 20–30 year legal lifespans. Every XDC-signed bill of lading is a live harvest-now-decrypt-later target, so XDC's cryptographic-longevity risk window is far longer than that of a typical short-horizon chain.

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

NIST-standardized PQC 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).

666-byte signatures, the most compact NIST-standardized PQ scheme. 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.

Primary NIST signature standard. ~2.4 KB. Best-audited PQ signature scheme, co-developed by IBM Research. Deployed in production by Signal (PQXDH, Sept 2023). A strong choice for user keys where bandwidth is less constrained than validator gossip.

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.

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

backup algos

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.

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.

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

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.

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.

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 POC in production repo

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 →

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 →

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 →

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"

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

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.

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.

Audit & Foundation

Crypto inventory, risk matrix, PQ Security Council, Threat Report v1.0

Infrastructure

PQ-TLS masternodes, bridge & DAO key upgrades, subnet guidance

Execution Layer

PQ precompiles, account abstraction, PQ key registry, XDSS-PQ

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 →

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 →

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 schemaQUANTUM SAFE

{ "standard": "XDSS-PQ/1.0", "document_type": "bill_of_lading", "issuer": "xdc://0xA3f2...91CC", "signatures": { "ml_dsa": "<FIPS-204, 2.4KB>", "falcon": "<FIPS-206, 666B>", "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 (draft)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."

Atul Khekade

Co-Founder, XDC Network

20–30yr

doc longevity

$5T

trade gap

2030

EU target

FAQ

Common questions

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.

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.

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.

Bandwidth. XDPoS 2.0 has 108 masternodes signing every block, and those signatures must be gossiped network-wide. Falcon (FN-DSA, draft FIPS 206) 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.

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.

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 →

Attend the retreat

EF Post-Quantum Research Retreat
Cambridge, UK, Oct 9–12, 2026

→ pq.ethereum.org → github.com/leanEthereum → NIST FIPS 203/204/205/206

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 → Get in touch