The post-quantum algorithm landscape is fragmented. NIST has finalized three standards, with two more in the pipeline. Blockchain ecosystems are developing their own schemes optimized for onchain constraints. Hash-based, lattice-based, and code-based constructions each carry different tradeoffs in key size, signature size, security assumptions, and implementation complexity. If you are an engineer trying to evaluate these algorithms side by side, you have to piece together information from FIPS documents, ePrint papers, mailing list threads, and scattered README files. We built a single reference to fix that: the Post-Quantum Cryptography Registry.
The registry is an open-source reference site that catalogs post-quantum cryptographic algorithms with structured, comparable data. For each algorithm, it provides parameter sizes (public key, secret key, signature or ciphertext), the underlying security assumption, NIST security level, risk ratings for assumption strength, implementation maturity, and side-channel exposure, along with a prose explainer covering security basis and practical considerations.
The data is schema-validated YAML paired with MDX. Every algorithm follows the same structure, which means you can compare ML-DSA's 2,420-byte signatures against FN-DSA's 666-byte signatures against SHRINCS's 324-byte stateful signatures without switching between different document formats or reconciling inconsistent terminology.
The registry currently includes nine algorithms spanning three categories of maturity.
The NIST standards are all present: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). These are the algorithms that NIST expects organizations to begin deploying now, with classical alternatives deprecated by 2030 and disallowed by 2035. The registry also covers FN-DSA, the NTRU-lattice-based signature scheme heading toward FIPS 206, and HQC, the code-based KEM selected by NIST in March 2025 as a backup to ML-KEM.
Beyond the NIST pipeline, the registry tracks schemes purpose-built for blockchain constraints, where signature size directly affects transaction cost. SHRINCS and SHRIMPS from Blockstream Research target Bitcoin's one-spend-per-key pattern with stateful hash-based signatures as small as 324 bytes (SHRINCS has already been deployed on Liquid mainnet). leanSig takes a different approach for Ethereum, optimizing for SNARK-based aggregation using Poseidon hashes. XMSS, the stateful hash-based scheme standardized in RFC 8391, rounds out the set as a mature baseline for environments where state management is feasible.
The registry does not recommend algorithms. It does not rank them. Different applications have different constraints, and a 324-byte signature scheme that requires state management is not better or worse than a 2,420-byte stateless one in the abstract. The registry gives you the numbers, the assumptions, and the tradeoffs.
The registry is open source. If an algorithm is missing, a parameter is wrong, or a new implementation has shipped, open a PR. The YAML schema and contribution workflow are documented in the repo.