How Quantum Hub Works
A transparent look at where our data comes from, how we score it, and what the numbers mean. This page exists so you can judge the dashboard for yourself rather than trusting a black box.
📊 At a glance
Loading live stats...
🎯 The threat scoring model
Every article is scored on two independent axes, then combined. The split prevents low relevance quantum research from crowding out genuine Bitcoin risk.
bitcoin_relevance: 0 to 3, how directly the article ties to Bitcoin or PQC migration
otherwise:
min(5, max(1, quantum_progress + bitcoin_relevance - 1))The cap exists because pure quantum progress without a crypto tie should not look like a Bitcoin emergency on this dashboard. A level 4 or 5 requires either strong quantum progress AND a crypto tie, or a direct PQC migration event (BIP proposal, NIST standard finalization) that warrants top billing on its own.
Pure quantum research, no Bitcoin or PQC tie. Background only.
General quantum progress with no current Bitcoin impact. Worth noting.
Quantum progress with a Bitcoin or PQC angle, or strong PQC migration news.
Fault tolerant demonstrations with crypto tie, or strong PQC migration milestones.
CRQC class events, NIST FIPS finalizations, BIP-360 activations, demonstrated breaks.
📚 Data sources
Two live sources, one curated static source, all conservative on rate limits.
| Source | What it provides | Cadence | Auth |
|---|---|---|---|
| arXiv search API | Bitcoin and PQC relevant preprints, scoped by query, top 5 per query | Every 3s polite delay, 15 candidates per run | None required |
| Brave News search | Six Bitcoin and PQC anchored queries, source allowlist of 21 quality outlets | Weekly, freshness = past week | BRAVE_API_KEY |
| Curated static JSON | Signature schemes, PQC timeline events, Quantum Cliff metrics, frozen UTXO risk | On demand, versioned in git | None, checked in |
Source allowlist, not denylist
Brave News returns whatever it ranks, and many results come from SEO content farms. Rather than maintain a growing denylist, we maintain an allowlist of 21 trusted outlets (Nature, arstechnica, IEEE Spectrum, CoinDesk, Bitcoin Magazine, The Quantum Insider, MIT News, and similar). Anything outside the allowlist is dropped on read. The same allowlist is the gate for what reaches the dashboard. This is a deliberate inversion of the usual approach.
Rate limit discipline
The collector validates any GitHub or Brave token via a single /rate_limit request before making any other calls. If the token is invalid (401), below a 100 request safety floor, or returns 429, the source is skipped cleanly with a logged reason. No retry loops, no 429 escalation. A bad token in a retry loop can burn an unauthenticated 60 requests per hour budget, which then looks like a rate limit error from inside the loop. The collector is designed to never enter that pattern.
📂 Records provenance
Every row in the bitcoin_quantum table has a known origin. There is no mystery collector writing rows in the background. 42 records total, broken into four provenance buckets.
| Category bucket | Count | Origin |
|---|---|---|
signature_scheme, timeline, metric | 13 | Curated static JSON at collector/data/bitcoin_static.json. The original Bitcoin quantum threat surface: PQC signature schemes, NIST PQC standardization timeline, Mosca inequality, CRQC estimate range, and the frozen P2PK UTXO risk call-out. |
utxo_age | 11 | Static snapshot from the Glassnode Studio public chart, captured 2026-06-09. Intended to be replaced by a live Coin Metrics fetch once a community API key is available; rows show a snapshot badge in the UI until the live data lands. |
bip | 5 | Fetched from the GitHub bitcoin/bips repository via REST API by bitcoin_collector.py source 2. Gated on a live token check at the start of every run. |
ai_threat_*, ai_timeline, ai_threat_compound | 13 | Curated for the "AI: The Other Threat to Bitcoin" page at /ai. Four threat surface categories (cryptography, social, consensus, ux) with two or three records each, plus the compound "AI shortens Mosca's clock" record and four AI timeline events. Same provenance model as the static JSON bucket: curated by edos, versioned in git, idempotent upsert. |
All 42 records share the same lifecycle: slug stable, idempotent upsert keyed on the slug, updated_at refreshed on every collector run. Re-running the collector on the same source data produces identical rows. The static JSON is versioned in git, so any change to a curated record is a deliberate commit with a recorded reason. The collector has no silent failure mode that would materialize rows from nowhere; if you see a count that does not match this table, it is a collector bug to fix, not a mystery to accept.
🏷️ Tagging system
Tags are extracted from title and summary using keyword proximity. They are for filtering, not scoring. A tag never raises or lowers threat level.
🔄 The data lifecycle
Three passes per run, designed to be additive and reversible.
- Collect. Run all configured source queries. Apply source allowlist (Brave) or query scope (arXiv). Polite delays between calls.
- Score. Compute quantum_progress and bitcoin_relevance for every candidate. Combine per the formula above. Extract tags.
- Save.
INSERT OR IGNOREkeyed on URL, so existing articles are never replaced or deleted. A--rescoreflag runs a re-classification pass over the existing table and is the only non-additive path. It is opt in and never runs on a normal schedule.
Date decay is applied at score time. Articles older than 90 days lose one threat level. Articles older than 365 days floor at threat 1. This keeps the dashboard weighted to recent material without losing history.
⚠️ Limitations and honest caveats
- Keyword based scoring is fast and explainable, but it is not semantic. An article that paraphrases "CRQC demonstrated" without using the exact phrase will not auto score as a 5. We accept the false negatives in exchange for a fully auditable rule set.
- The arXiv search API is queried with Bitcoin and PQC anchored queries, which means arXiv papers that are quantum hardware focused but Bitcoin silent will not appear. This is intentional. The old collector pulled the live quant-ph feed and surfaced 84 percent of the database as irrelevant physics papers. That was a signal to noise problem, and we fixed it by narrowing the retrieval.
- Source allowlist drift is a real risk. When a quality outlet is acquired, rebrands, or shifts editorial direction, the allowlist does not know automatically. A quarterly review of the allowlist is part of the maintenance checklist.
- Curated records (signature scheme specs, NIST FIPS finalization dates, frozen P2PK UTXO risk) reflect what was true at curation time. They are versioned in git, so any update is a deliberate commit with a recorded reason.
- Bitcoin threat estimates are not predictions. They are snapshots of expert opinion, curated records, and live signals, all combined on a single dashboard. The Mosca inequality (time to migrate plus time data must remain secure greater than time to CRQC) is the only canonical planning framework, and it is shown on the Bitcoin page, not here.
📬 How to report errors
If you spot a misclassification, a missing source, or a stale fact on the curated records, the fastest path is to message the project owner directly. The collector code is open in the project repository, and the scoring rules are visible in this page and in the source. If a rule change would fix a systemic misclassification, that change goes in as a small, named commit with a recorded reason.
The whole system is built to be auditable, not magical. The threat level on any article is reproducible by reading the scoring rules, the keyword lists, and the article text. No hidden weights, no opaque models, no surprise adjustments.
Contact
Project lead: Daniel Schott. Reach out on X at x.com/DOSHostNet for the fastest response. For code or data issues, the project repository has issue tracking and a changelog that records every scoring change with its reason.