QuantumShield™ version 3.0 — the current production implementation — combines ML-DSA-65 with ECDSA in a hybrid authentication system. It addresses the threat that exists today and the threat that may exist in a decade.
Version 4.0 addresses a harder problem: building for threats that have not been identified yet.
The history of security is not a history of known threats being successfully defended. It is a history of defenders being surprised by attack vectors they did not anticipate. Heartbleed exploited a feature, not a bug. Log4Shell was hiding in a logging library used by half the internet. The pattern repeats: the attack that matters most is usually the one nobody modeled.
QuantumShield™ 4.0 is organized around five capabilities that address not specific known threats but the structural conditions that allow unknown threats to become catastrophic.
Feature 1: Quantum-Recoverable Authentication
The problem it solves:
If a user's ECDSA credentials are compromised — whether by a quantum computer or a classical attack — current systems have no recovery path that does not involve support intervention, account verification, and potential loss of transaction history.
Inspired by Zcash's quantum recoverability research, this feature allows users to re-establish authenticated access using only their ML-DSA-65 key material, without losing account data or requiring manual verification.
The architecture separates the authentication layer into two independent paths: the classical path (ECDSA-based, used for all normal authentication) and the quantum path (ML-DSA-65 based, dormant under normal operation, activatable as a recovery mechanism). If the classical path is compromised, the quantum path allows re-issuance of credentials without re-verification.
In plain terms: even if a quantum computer someday renders ECDSA signatures worthless, users do not lose access to their accounts. The post-quantum layer becomes not just additional security but a recovery guarantee.
Feature 2: ML-KEM Session Encryption
The problem it solves:
Current TLS session key exchange uses X25519, which is vulnerable to Shor's algorithm. A network adversary recording TLS sessions today could decrypt them retroactively with a future quantum computer — harvest-now-decrypt-later at the transport layer.
ML-KEM (FIPS 203) — NIST's post-quantum key encapsulation mechanism — protects the session key exchange itself. Combined with X25519 in a hybrid configuration (the same approach Cloudflare deployed in production in 2023 and Google Chrome adopted in 2024), this closes the harvest-now-decrypt-later vulnerability at the transport layer.
Authentication tokens and session traffic that are captured today cannot be decrypted in the future — because the session keys themselves were established using lattice-based cryptography that quantum computers cannot break.
Feature 3: Algorithm Transparency Dashboard
The problem it solves:
No payment platform currently publishes its cryptographic configuration publicly. Users, auditors, and regulators have no way to verify what algorithms are actually in use — they must take the platform's word for it.
The algorithm transparency dashboard — accessible at schnelpay.com/security/status — will publish in real time:
- Current signature algorithms in production and their NIST standard versions
- Current key exchange mechanisms
- Date of last algorithm update
- Quantum Threat Level indicator, updated based on published NIST advisories and quantum computing milestones
- Upcoming planned algorithm changes with timelines
This is radical transparency — no other payment platform offers it. The philosophy is simple: if the security is real, it should be visible. Security through obscurity is not security at all.
Feature 4: Versioned Crypto-Agility
The problem it solves:
When algorithms need to change — whether due to new vulnerabilities, updated NIST standards, or regulatory requirements — systems without explicit version management require coordinated upgrades that risk downtime or transition-period vulnerabilities.
Every QuantumShield™ token carries a version identifier in its header — currently QS-v3. When version 4 is deployed, both versions will be accepted during a configurable transition window. Old tokens continue to work. New tokens carry new algorithm versions. The migration happens transparently, without forcing simultaneous updates across all active sessions.
When FIPS 206 (FN-DSA, FALCON-based signatures) is incorporated, or when ML-DSA-87 becomes appropriate for higher-value accounts, the version system allows gradual, auditable migration rather than a flag-day cutover.
Feature 5: Honest Threat Uncertainty Score
The problem it solves:
Security posture should respond to changing threat conditions. Current systems treat security configuration as static — set at deployment and changed only in response to incidents. This is reactive rather than adaptive.
The Quantum Threat Level indicator — one of four states: Monitoring, Elevated, High, Critical — will be updated based on published developments in quantum computing: qubit count milestones from major quantum computing programs, NIST advisory updates, published cryptanalytic advances against current post-quantum algorithms, and intelligence community threat assessments that become public.
When the level changes, the reasoning is published. When it returns to a lower level, that is also explained. The goal is a running public record of the quantum threat landscape as understood by the team building against it.
The Timing
These five features represent the difference between a quantum-safe system and a quantum-resilient one. The current implementation is safe — it uses algorithms that resist known quantum attacks. The 4.0 roadmap makes it resilient — designed to adapt, recover, and remain transparent as the threat landscape changes.
The timeline for version 4.0 is 2026-2027. Each feature will be documented publicly as it ships, with the implementation approach, the trade-offs considered, and the specific NIST standards followed.
"The goal is not to build the perfect quantum-safe system. The goal is to build a system that is honest about what it does not know and designed to improve as knowledge improves."
That is the architecture of QuantumShield™ 4.0. Not a guarantee against a threat nobody fully understands. A commitment to building the best available answer and updating it as understanding grows.