What Is the Quantum Threat Oracle?
The Quantum Threat Oracle is an on-chain monitoring system that tracks the real-world cost and capability of quantum computers and translates those measurements into automated protocol responses. It does not predict when quantum computers will break existing cryptography. It measures how close that event is, continuously, and acts when defined thresholds are crossed.
Most blockchains have no equivalent mechanism. They rely on researchers, developers, or governance participants to notice a threat, propose a response, and coordinate an upgrade. That process takes months even under ideal conditions. The Quantum Threat Oracle compresses that timeline to days, and in some cases to blocks.
The Oracle is part of TADEQS (Threat-Adaptive Dynamic Encryption and Quantum Security), QuanChain's overarching security architecture. TADEQS designed the Oracle from the start as the network's early-warning and automated-response layer.
The LQCp/h Metric
LQCp/h stands for Logical Qubit Cost per Hour. It is the Oracle's primary threat index. The metric answers a specific question: what would it cost in USD to rent enough logical qubit-hours to execute Shor's algorithm against a 256-bit elliptic curve key at today's hardware prices and error rates?
A logical qubit is not the same as a physical qubit. Current quantum hardware requires many physical qubits to implement one error-corrected logical qubit due to error rates. As hardware error rates fall, the physical-to-logical ratio improves, and LQCp/h drops. As quantum cloud providers lower access prices, LQCp/h also drops. The metric captures both dimensions simultaneously.
When LQCp/h is $10 billion per hour, breaking a key is economically infeasible even for a nation-state. When LQCp/h reaches $1 million per hour, it becomes a realistic threat for well-funded adversaries. When LQCp/h reaches $10,000 per hour, it is a practical threat for a wide range of attackers. The three migration thresholds are pegged to these cost levels, with specific values set by QCH governance and adjustable via vote.
Data Sources the Oracle Monitors
The Oracle does not rely on a single data feed. It aggregates from four source categories, each submitted by independent oracle nodes that stake QCH and face slashing for submitting false data.
Published qubit counts and error rates. When IBM, Google, IonQ, or other hardware vendors publish new processor specifications, oracle nodes parse these announcements and submit structured data: qubit count, gate fidelity, T1/T2 coherence times, and two-qubit gate error rates. The Oracle's scoring function converts these specs into a logical qubit density estimate using a lookup table maintained by governance.
Cloud quantum compute pricing. Oracle nodes query public APIs from AWS Braket, Azure Quantum, and IBM Quantum Network to retrieve current per-shot and per-hour pricing for quantum compute time. These prices are submitted on a 6-hour cycle. Large pricing changes (over 20% in either direction over 7 days) trigger an accelerated update cycle.
Academic and government publications. Oracle nodes monitor arXiv, NIST, and national security agency publications for algorithm advances. Submissions from this category carry a 30-day verification lag: they do not affect the threat score immediately but enter a pending queue that governance can fast-track if the publication is from a top-tier venue.
Error correction milestone events. Specific milestones (such as achieving below-threshold error rates on a surface code of defined size) are pre-classified in the Oracle's ruleset as high-weight events. A confirmed milestone automatically increases the threat score by a fixed increment, regardless of what the continuous metrics show.
How the Oracle Converts Data Into a Threat Score
Each data source category contributes a weighted component to the overall LQCp/h index. Hardware specs carry 40% weight, compute pricing carries 30%, publication signals carry 15%, and milestone events carry 15%. Within each category, the Oracle uses the median of the last 5 valid submissions from independent oracle nodes, which filters out outliers and delayed data.
The resulting LQCp/h index updates on-chain every 6 hours under normal conditions. During a hardware announcement event or milestone trigger, the update cycle drops to 1 hour. All historical LQCp/h values are stored on-chain permanently, which means anyone can audit the Oracle's history and verify when and why each threshold crossing occurred.
The Three Migration Thresholds
The Oracle operates on three thresholds, each triggering a different protocol response.
T1 (Preparation threshold). When LQCp/h drops below the T1 level (currently set at $50 million per hour), the Oracle emits an on-chain alert and opens a 60-day governance window. During this window, QCH holders vote on which replacement algorithm to approve for CCRP activation. The vote follows standard governance rules: 10% quorum, 66% approval. If the vote passes, the approved algorithm is queued for CCRP Phase 1 activation at T2. If no vote passes within 60 days, the fallback algorithm list activates automatically at T2.
T2 (Activation threshold). When LQCp/h drops below the T2 level (currently $5 million per hour), CCRP Phase 1 begins automatically. Both the existing and new algorithm versions become valid. The network starts accepting transactions signed with the new algorithm. This phase runs for a minimum of 90 days, giving wallets, exchanges, and developers time to migrate. See the CCRP protocol deep dive for exactly how Phase 1 operates.
T3 (Emergency threshold). When LQCp/h drops below the T3 level (currently $100,000 per hour), the Oracle accelerates the CCRP Phase 2 deprecation window from 30 days to 7 days. This is the emergency response: the network treats an attack as potentially imminent and prioritizes completing the migration over providing maximum transition time.
Protection Against False Positives
A single quantum hardware announcement should not trigger a network-wide migration. The Oracle has three mechanisms to prevent false positives.
First, the median aggregation across multiple oracle nodes means a single malicious or erroneous submission cannot move the index. An attacker would need to corrupt the majority of oracle nodes simultaneously to manipulate the score.
Second, T1 and T2 require the LQCp/h index to stay below the threshold for 72 consecutive hours before the threshold is officially crossed. A brief anomaly that corrects within 3 days does not trigger a protocol response. T3 has a shorter confirmation window of 12 hours, given its emergency nature.
Third, QCH governance can veto a T2 activation within the first 24 hours after it triggers. This veto requires a 20% quorum and 75% approval and is designed only for cases where the Oracle's data is demonstrably corrupted. Normal disagreement with the threat assessment does not meet the veto standard.
The Governance Role of QCH Holders
QCH holders govern the Oracle's threshold parameters through standard on-chain governance. The adjustable parameters include the T1, T2, and T3 LQCp/h values, the weighting percentages across data source categories, the hardware vendor list that oracle nodes report on, the fallback algorithm priority list, and the oracle node slashing penalty amounts.
Parameter changes require a 7-day voting period, 10% quorum, and 66% approval. Threshold changes (T1, T2, T3) require 75% approval given their direct impact on migration timing. All parameter changes take effect after a 48-hour time lock, giving node operators and developers time to prepare for any behavioral change.
Why This Matters: What Other Chains Do Instead
Most blockchains today have no automated quantum monitoring. Their security teams may follow quantum hardware news manually. A major hardware breakthrough would trigger a response process that starts with researchers noticing the news, writing a proposal, building community consensus, scheduling a governance vote, coordinating a fork, and waiting for adoption. That process realistically takes 6-18 months.
The Quantum Threat Oracle targets a response time measured in weeks from T2 to full migration. The difference is architectural: QuanChain was built with quantum resistance as a core protocol requirement, not an afterthought. The Oracle and CCRP are what that looks like in practice. For the current status of the Oracle on the live testnet, see the testnet launch post.
