Quantum Safe

TLDR; A Rust-based Falcon-512 post-quantum hardware wallet on STM32, providing quantum-resistant transaction signing for institutional cryptocurrency custody.

Institutional capital will not fully commit to blockchains until keys and signatures are provably safe against quantum adversaries. Ethereum's current ECDSA and BLS schemes are dead in a post-quantum world: Shor's algorithm breaks elliptic-curve cryptography which is based on the difficulty of the discrete log problem over elliptic curves, which means that any account that broadcasts a signed transaction leaks enough information (signature + message) to reconstruct its public / private key pair once a a sufficiently powerful quantum computer exists. Recent roadmaps and expert surveys now treat a cryptographically relevant quantum computer as a medium-term risk in roughly a five-to-ten-year window, with non-trivial probability even near five years for state-level actors. In that world, it is rational for an adversary to spend significant resources to compromise large Bitcoin and Ethereum accounts while shorting the assets, with potential economic damage in the multi-trillion-dollar range. "Harvest-now, exploit-later" collection of signatures is therefore a credible threat to long-lived wallets and institutional treasuries.

Hardware wallets are effectively mandatory for institutions, which require dedicated signing modules, strong key isolation, and auditable controls. Yet devices in mass production today (Ledger, Trezor, and peers) still expose only classical ECC DSAs for user keys; there is no widely deployed hardware wallet that supports NIST-standardized post-quantum signatures for transaction signing. "Quantum-ready" offerings mostly use PQC for firmware attestation and update authenticity, not for the DSAs that actually secure on-chain assets.

Falcon-512 is one of the few lattice-based schemes compact enough to be economically viable on-chain: at level-1–equivalent security it offers ~897-byte public keys and ~666-byte signatures, versus roughly 3–4× larger signatures for Dilithium-2 / ML-DSA-44. Those size differences translate directly into higher calldata costs on Ethereum. Falcon-512 is also the better fit as Ethereum "zk-ifies": compared to other PQ resistant DSAs, Falcon-512 has a lighter arithmetic and hashing footprint during signature verification in zkVMs. Dilithium's verification uses multiple SHAKE invocations and many polynomial multiplications, whereas Falcon uses a single hash of the message to a polynomial (easy to replace with Poseidon2 or RPO in zk settings) and one polynomial multiplication. Each extra SHAKE call and multiplication is costly to arithmetize, so Falcon is substantially cheaper to verify in a zkVM. zkVM systems such as Miden already use a Falcon-512 variant as their default wallet scheme.

This project delivers a post-quantum hardware wallet based on an STM32 microcontroller and a heavily optimized no_std Rust implementation of Falcon-512. Starting from aszepieniec/falcon-rust, we optimized the cryptographic core for embedded constraints, replaced standard math dependencies with libm = "0.2", and refactored memory usage to fit safely within the MCU's SRAM. Rust was chosen over the official C reference (pornin/c-fn-dsa) for stronger safety guarantees, tighter control over undefined behavior, and a clearer path toward formal verification. The result is a forward-compatible signing device capable of generating compact, quantum-resistant Falcon-512 signatures today, giving institutions and security-sensitive individuals a realistic way to harden key custody ahead of the quantum transition.

The prototype is implemented entirely in Rust (frontend in typescript), from cryptographic core to embedded firmware and host tooling. I began by forking an existing Falcon-512 Rust implementation (aszepieniec/falcon-rust) and converting it to no_std, replacing std dependencies and floating-point/math calls with core and libm = "0.2", and then aggressively optimizing memory usage (explicit scratch buffers, reduced copies, flattened call paths) to fit comfortably within the SRAM constraints of an STM32 microcontroller. This no_std Falcon-512 library is compiled into a bare-metal STM32 firmware that exposes a minimal message-based protocol over the wire: the host sends messages (or hashes), the device returns Falcon-512 signatures, and the private key never leaves the microcontroller. In this hackathon version, on-device key generation and any secure element integration are explicitly out of scope, keys are provisioned externally, and the device is intended as a feasibility demonstration that Falcon signing on a microcontroller is straightforward in practice. On the host side, a Rust frontend handles user interaction, talks to the STM32 over a simple framed transport, and verifies signatures using a WebAssembly module that reuses the same Falcon verifier code compiled to WASM, yielding a single coherent Rust codebase for embedded signing of Falcon512.