Deterministic, evidence-grounded, and NIST-aligned. Every QorTrace point traces to a specific cryptographic fact. The LLM advisor only narrates these findings — it cannot invent risk. This page is the canonical public formula. We keep it living: as standards evolve and as we adopt new techniques, the methodology version bumps and previously-issued reports remain pinned to the version they were generated against.
Why QorTrace is different
Deterministic Scoring
Rule-based engines, not heuristic black-boxes. Same input, same output, every time. Two independent reviewers reproduce identical scores.
Stamped & Reproducible
Every report freezes its methodology_version. We can replay 2025 reports with 2025 rules five years later — auditors love this.
Peer-Reviewable
The full formula lives on this page in plain language. Submit corrections via /security or open a public review thread — we publish responses.
No LLM Hallucination
Our AI narrator describes findings only. It cannot invent severity, change scores, or bypass detectors. The math is deterministic; the prose explains it.
Threat model · institutional crypto inventory
QorTrace assumes the eventual existence of a cryptographically-relevant quantum computer (CRQC) running Shor's at scale. But blockchain primitives are only one of six institutional threat surfaces we score. The full inventory is broader:
Harvest Now, Decrypt Later (HNDL)
State-level adversaries are already capturing TLS / VPN / RPC traffic, signed transactions, and encrypted backups. When a cryptographically-relevant quantum computer (CRQC) arrives, today's RSA-2048 / ECDSA / X25519 ciphertexts become retroactively decryptable. Anything with a long secrecy half-life — IP, M&A, custody key recovery, regulatory filings — is exposed today, even before a CRQC exists.
Blockchain Cryptographic Primitives
ECDSA (BTC/ETH/BSC/Tron), EdDSA (Solana/Stellar/Cosmos), Schnorr (Taproot), and BLS (Ethereum consensus, Chia, ZK rollups) are all broken by Shor's algorithm. Hash functions (SHA-256, Keccak-256) are weakened by Grover's to ~128-bit security. Public-key exposure timing varies by address type — see Section 6.
KMS / HSM Key Inventory
Institutions accumulate cryptographic keys across AWS KMS, Azure Key Vault, GCP KMS, on-prem HSMs (Thales, Entrust, AWS CloudHSM), and bespoke key escrow services. Each key has a generation algorithm, key length, rotation cadence, and a downstream blast-radius. We help you inventory which keys protect what, and which ones become quantum-vulnerable on day one of a CRQC.
Certificate / PKI Inventory
Enterprise PKI sprawls across internal CAs, public CAs, mTLS certs, code-signing certs, S/MIME, and IoT device identities — each with its own RSA/ECDSA dependency. We map your certificate inventory against PQ-readiness: which certs need hybrid issuance now, which need pure ML-DSA at next rotation, which can wait until 2030.
Vendor & Supply-Chain Cryptography
Your TLS terminator, payment gateway, identity provider, code-signing toolchain, observability stack, and HSM vendor all bring their own cryptographic primitives. A single vendor still on RSA-2048 in 2031 is a single point of HNDL exposure for your entire institution. We track vendor PQ-readiness publicly and integrate roadmap signals into your inventory.
Migration & Compliance Windows
NSA CNSA 2.0 mandates PQ adoption for NSS by 2030 (software/firmware) and 2035 (hardware). FFIEC examiners expect documented crypto-agility plans now. EU DORA (Jan 2025) requires ICT third-party risk reporting. The window to inventory → migrate → re-certify is shorter than vendors admit; we sequence migration so the highest-risk assets move first.
Schnorr / Ed25519 / BLS are not quantum-safe. All three rely on the discrete-log problem and are broken by Shor's. NIST-finalized replacements (ML-DSA / SLH-DSA / Falcon) are operational today; STARKs are PQ-safe by construction.
Compliance & standards alignment
QorTrace findings map directly onto standards used by auditors, examiners, and procurement reviewers. Each alignment is a real clause, not a vague reference — click through to the source.
Used to identify systems still on RSA / ECDH key exchange.
Recommended replacement for ECDSA / RSA signatures.
Conservative fallback for long-lived signing roots.
Drives priority sequencing for federal-adjacent inventory.
Cross-referenced against your HSM / KMS inventory.
Crypto-inventory feeds the A.10 control review evidence.
Crypto-readiness reports map to CC6 trust criteria.
Examiners increasingly request crypto-agility plans.
EU baseline for institutional PQ-readiness.
Maps third-party crypto-dependency reporting.
Custody-risk weighting includes signature-scheme exposure.
Cited in Taproot / P2TR exposure analysis.
Scoring engine · per-chain formulas
| FACTOR | RANGE | RULE |
|---|---|---|
| Public-key exposure | 0–40 | P2PK / P2TR ⇒ 40. Hash-locked + spent ⇒ 40. Hash-locked + unspent ⇒ 0. |
| Address reuse | 0–15 | min(15, (outgoing_tx − 1) × 3) |
| Balance at risk | 0–20 | log₁₀(USD) / 6 × 20 · only if exposed |
| Dormancy with exposed key | 0–15 | +15 if exposed and inactive > 365d · +8 if > 180d |
| Address-type modifier | 0–10 | P2PK +10 · P2TR +5 · others +0 |
Address-type taxonomy · Bitcoin family
| Type | Pubkey on-chain | When exposed | Risk class |
|---|---|---|---|
| P2PK (Satoshi-era) | Yes, always | Always | Critical |
| P2PKH (1…) | Hash only | On first spend | High after spend |
| P2SH (3…) | Depends | On spend | Variable |
| P2WPKH (bc1q…) | Hash only | On first spend | Same as P2PKH |
| P2TR (bc1p…) | Yes (x-only) | At creation | High — Schnorr broken |
Smart-contract detector inventory
Nine deterministic detectors run against every contract submission. Each fires on a specific Solidity / EVM bytecode pattern and emits a default severity that operators can override per-engagement.
ecrecover_usageHIGHDirect ecrecover ECDSA signature verification.
v, r, s = ecrecover(msgHash, ...)
eip712_signingHIGHEIP-712 typed-data signing patterns.
DOMAIN_SEPARATOR · _hashTypedDataV4(...)
permit_patternHIGHERC-2612 ECDSA permit() function.
permit(owner, spender, value, deadline, v, r, s)
bls_precompileCRITICALBLS / pairing precompile (0x08, 0x0a, EIP-2537).
staticcall(0x08, ...) · pairing()
hardcoded_signerHIGHConstant SIGNER / VERIFIER / ORACLE address.
address constant SIGNER = 0x...;
multisig_thresholdMEDIUMThreshold / Safe / requireMultiSig patterns.
require(threshold ≤ owners.length)
replay_protectionINFONonce, deadline, chainId, DOMAIN_SEPARATOR present.
nonces[user]++ · block.chainid
upgradeable_proxyINFOUUPS / Transparent / Beacon / _authorizeUpgrade.
_authorizeUpgrade(address newImpl)
eip1271_signerMEDIUMisValidSignature(bytes32, bytes) modular signer.
isValidSignature(bytes32, bytes) → 0x1626ba7e
Tier mapping
Minimal exposure. Monitor.
Plan migration within 24 months.
Migrate within 12 months. Consider hybrid signing.
Migrate immediately. Move funds to a fresh, unspent address.
Rigorous testing & validation
Every formula change ships behind a regression test. We re-run the complete suite before every methodology bump — if a published score would change, the version stamps it explicitly. We treat scoring determinism as a load-bearing invariant, not a nice-to-have.
Live methodology updates
- · Aptos / Sui Move primitives + score modifiers
- · Hybrid PQ + ECDSA signature attestation
- · KMS / HSM inventory probe (AWS, Azure, GCP)
- · Certificate-chain crawler for enterprise PKI
Get notified when the methodology version bumps. We email a human-readable diff + the previous version's permanent URL.
Subscribe via RSSor emailMethodology compliance receipt
Auditors and compliance reviewers — generate a stamped PDF receipt proving you accessed and read this version of the methodology. Useful for SOC 2 / ISO 27001 / FFIEC workpapers. Receipt includes your name, organization, the methodology version, a SHA-256 hash of the canonical content, and a unique serial number.
Cite this methodology
QorTrace methodology is open and citable. When you reference QorTrace in research, audits, board reports, regulatory filings, or press, please cite the specific version you used. Older reports stamp methodology_version and remain reproducible against their stamped revision.
QorTrace. (2026). QorTrace Scoring Methodology (Version 0.2) [Methodology specification]. https://qortrace.com/methodology
QorTrace. QorTrace Scoring Methodology. Version 0.2, 6 May 2026, qortrace.com/methodology.
QorTrace. 2026. QorTrace Scoring Methodology. Version 0.2. Methodology specification. https://qortrace.com/methodology.
@techreport{qortrace_method_02,
title = {{QorTrace Scoring Methodology}},
author = {{QorTrace}},
organization = {{QorTrace}},
year = {2026},
month = {05},
type = {Methodology specification},
version = {0.2},
number = {qortrace-method-v0.2},
note = {Quantum Cryptographic Audit Methodology},
url = {https://qortrace.com/methodology}
}Version history
- Threat model expanded beyond Shor/Grover to 6 institutional surfaces (HNDL, blockchain, KMS/HSM, PKI, vendor supply chain, compliance windows).
- Compliance & standards alignment grid added — 12 standards with direct external citations (NIST FIPS 203/204/205, NSA CNSA 2.0, ISO 27001, SOC 2, FFIEC, FIPS 140-3, ENISA, EU DORA, BIS).
- Page restructured into 13 numbered sections with IDE/whitepaper aesthetic.
- Detector inventory expanded with example trigger snippets per detector.
- References list includes external links to every cited standard.
- Methodology compliance receipt — downloadable SHA-256-stamped PDF for SOC 2 / ISO 27001 / FFIEC workpapers.
- BTC / UTXO-family scoring engine: 5 factors (pubkey exposure, address reuse, balance at risk, dormancy, address-type modifier).
- EVM-family scoring engine: 5 factors (Ethereum, BSC, Base, Polygon, Arbitrum, Optimism, Tron).
- Solana scoring engine — recognizes structural address-as-pubkey exposure (60-point baseline).
- EIP-7702 delegation detection (Pectra, May 2025) — preserves EOA classification.
- 9 Solidity detectors: ecrecover_usage, eip712_signing, permit_pattern, bls_precompile, hardcoded_signer, multisig_threshold, replay_protection, upgradeable_proxy, eip1271_signer.
References
- [01]NIST FIPS 203 — Module-Lattice Key-Encapsulation Mechanism (ML-KEM)
- [02]NIST FIPS 204 — Module-Lattice Digital Signature Algorithm (ML-DSA)
- [03]NIST FIPS 205 — Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)
- [04]NIST SP 800-57 — Recommendation for Key Management
- [05]NSA CNSA 2.0 PQC migration timeline (2030 / 2035)
- [06]BIP-340 — Schnorr signatures over secp256k1
- [07]EIP-712, EIP-1271, EIP-2537, EIP-7702
- [08]ENISA — Post-Quantum Cryptography integration study
- [09]FFIEC IT Examination Handbook · Information Security
- [10]ISO/IEC 27001:2022 — Annex A.10 cryptographic controls
- [11]EU DORA — Digital Operational Resilience Act
- [12]BIS — Prudential treatment of cryptoasset exposures
- [13]NIST CMVP — FIPS 140-3 Cryptographic Module Validation
Run this methodology under your own brand.
Big-4 and boutique audit firms can license the QorTrace scanning engine + CBOM generator as QorBOM™— your tenant, your brand, your client-facing portal, issuing reports stamped with the methodology version cited on this page. One platform; two go-to-market surfaces.
EXPLORE QORBOM →methodology version qortrace-method-v0.2 · canonical specification · stamped reports remain reproducible against their methodology version
Was this article helpful?
Book a free 30-minute consultation with the QorTrace team. We'll walk through your scan results and a migration roadmap — no commitment.
We use strictly-necessary cookies to run the app. With your consent we also use analytics cookies to understand how QorTrace is used so we can improve it. Cookie Policy · Privacy Policy