qsafe quantum-risk transparency

qsafe

qsafe is an open-source framework for quantum risk in cryptographically secured software. Quantum computers don’t break cryptography in one way; they affect specific cryptographic surfaces: signatures, encryption, pairings, and hashing. qsafe maps those risks across 5 core sections and 30 components, providing a transparent view into a project’s current quantum-safety status.

Frameworkdocs/framework.md explains the reasoning, threat model, and sources.
Taxonomydata/taxonomy.json is the canonical 5-core / 30-component model.
Projectsdata/projects/index.json lists assessed and queued projects; each assessed project has a matching data/projects/<id>.json.
Agentsllms.txt and AGENTS.md provide crawler and contributor guidance.

Framework at a glance

  1. 1 Keys & AccountsWho is allowed to move money. Components 1.1-1.7: account signing keys, custody, MPC/threshold signing, account abstraction, passkeys/session keys, identity/naming, governance/voting. universalBreakable
  2. 2 Apps & InputsThe programs and outside data they trust. Components 2.1-2.5: contract signature checks, proof/pairing verifiers, oracles, randomness/beacons, VDF/time ordering. commonBreakable
  3. 3 Block Production & ProvingHow blocks get ordered, proven, and published. Components 3.1-3.6: sequencing, proof system, trusted setup, data availability, state commitment, execution/VM. conditionalDepends
  4. 4 Consensus, Finality & Cross-chainHow the network agrees and how chains talk. Components 4.1-4.7: consensus signatures, light clients, settlement, bridges, restaking/AVS, payment channels, MEV/PBS. commonBreakable
  5. 5 Networking & ConfidentialityThe wires between computers. Components 5.1-5.5: P2P transport, node identity, RPC/client transport, key agreement/stealth addresses, app-layer encryption/privacy. universalBreakable

Contribution paths

There are two normal contribution routes: add a missing chain or product, or update one component in an existing assessment.

  1. Add a chain or product: read docs/framework.md, docs/taxonomy.md, and CONTRIBUTING.md; copy data/projects/_template.json to data/projects/<id>.json; fill all 30 components; add it to data/projects/index.json; open a PR.
  2. Update one component: open data/projects/<project-id>.json, find the stable component id such as 1.3, update only that component’s assessment block, then open a PR or use the component update form.
  3. Scoring rule: score the project’s live mainnet reality, not its roadmap. A component passes when its default is quantum-safe, or when a post-quantum option meets all six election conditions in docs/framework.md (individually electable risk, finalized NIST standard, audited production on mainnet, normal-user accessible, full surface coverage, no loss of core function). Use primary sources; future plans can be noted in why, but never count.