PQC Rust Notes

Notes from shipping Dytallix, a Rust-built, PQC-native Layer 1 blockchain stack.

This repo is not a cryptographic proof, a security audit, or a standards document. It is the short version of the decisions I want to be asked about by PQC teams: why the stack is PQC-native, why ML-DSA-65 was the default signature choice, why X25519 plus ML-KEM-768 is the practical hybrid transport answer, and what actually gets harder once post-quantum cryptography leaves the paper.

Reading order

1. Dytallix design decisions
2. Why ML-DSA-65 over Falcon
3. X25519 plus ML-KEM-768 hybrid rationale
4. What I learned shipping PQC in Rust
5. References

Core position

Dytallix starts from the idea that bolting PQC onto an ECC-era identity model is a migration plan, not a clean design. If accounts, validator votes, transaction authorization, and peer handshakes are created after NIST finalized the first PQC standards, the default should be to remove avoidable cryptographic debt at genesis.

My working defaults:

• Use ML-DSA-65 for transaction and validator signatures when the system needs a practical middle parameter set with stronger margin than ML-DSA-44 and less size cost than ML-DSA-87.
• Treat Falcon, now FN-DSA in the NIST naming path, as important but not the first production default when implementation simplicity, validation timing, side-channel review, and operational confidence matter more than minimum signature bytes.
• Use ML-KEM-768 as the post-quantum KEM baseline for key establishment, aligned with FIPS 203 and current TLS hybrid work.
• Keep X25519 in hybrid transport where compatibility and classical confidence still matter.
• Do not treat "passes test vectors" as equivalent to "safe to operate."

Search phrases this repo is meant to answer

• post quantum Rust ML-DSA-65
• ML-DSA-65 vs Falcon
• Falcon vs Dilithium blockchain signatures
• FN-DSA vs ML-DSA production deployment
• X25519 ML-KEM-768 hybrid rationale
• X25519MLKEM768 TLS 1.3
• ML-KEM-768 Rust key exchange
• PQC native blockchain design
• post quantum blockchain Rust
• PQC shipping lessons

One paragraph version

I chose ML-DSA-65 because Dytallix needed a post-quantum signature path that was standardized, implementable, reviewable, and boring enough to put on transaction authorization and validator votes. I chose X25519 plus ML-KEM-768 for hybrid transport because it preserves today's widely deployed elliptic-curve security while adding the NIST ML-KEM path against harvest-now-decrypt-later risk. The biggest lesson from shipping was that PQC is not just swapping algorithms. It changes byte budgets, address formats, failure modes, validation expectations, interop planning, and the way engineers have to talk about uncertainty.