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.
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 (draft FIPS 206) — under AND semantics: a document is valid only if both signatures verify. Security therefore holds unless both algorithms are broken. 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.
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.
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.
XDSS-PQ is designed against the following adversary and assumptions:
The central design response to single-algorithm cryptanalysis is the hybrid AND construction described next.
XDSS-PQ binds each document with two independent post-quantum signatures over the same canonical payload:
| 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.
both_requiredA document is valid only if BOTH the ML-DSA signature AND the Falcon signature verify. Forging a document therefore requires breaking both FIPS-standardised algorithms 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)This is strictly stronger than either algorithm alone and is the defining property of the standard
("valid_if": "both_required" in the schema below).
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:
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.
XDSS-PQ is intended to be adopted without disruption to existing issuance flows, using a phased, additive path:
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 and are complementary to, but separate from, this document.
XDSS-PQ is built on, and declares alignment with, the following:
poc_falcon branch (Falcon block signing & QC
verification proof-of-concept; ~666-byte signatures), August 2025.
github.com/XinFinOrg/XDPoSChain/tree/poc_falconForward-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.