# Quantum Canary · Prepare — the DIY guide to offline, quantum-aware key generation and migration

*A companion to [Quantum Canary](https://quantum-canary.sites.imd.fun), the public on-chain alarm at [`0x626517225096671868609c1bbf9c1b416a4efd9a`](https://etherscan.io/address/0x626517225096671868609c1bbf9c1b416a4efd9a) on Ethereum mainnet. The Canary says WHEN to move. This report says WHAT to build, HOW to generate keys, and HOW to migrate.*

Snapshot date: **2026-10-12**. Status markers used throughout: **[Observed]** — verified directly in a cited repository, datasheet, or on-chain record; **[Inferred]** — a reasonable conclusion not explicitly stated by a primary source; **[Open question — 2026]** — unresolved as of this writing. Citations are numbered `[n]` and resolved in **References**.

---

## Executive summary

A cryptocurrency seed is, at the entropy level, already quantum-safe: 256 bits of good randomness costs Grover's algorithm roughly 2^128 operations to search, which is not a near-term threat `[3]`. What a quantum computer actually breaks is not the seed — it is the **public key** your signature scheme derives from that seed and exposes on-chain. Shor's algorithm solves the discrete-log problem behind secp256k1 (Bitcoin, Ethereum EOAs) and Ed25519 in polynomial time, recovering the private key from an exposed public key `[36]`. So "quantum-resistant seed generation" is really two separable problems: (1) generate 256 bits of real entropy offline, verifiably, without leaking it — a solved problem with decades of hardware-RNG and dice-based tooling; and (2) stop deriving and exposing Shor-breakable public keys from that entropy, which requires either hiding pubkeys (hash-locked outputs, never reusing an address) or switching the signature scheme itself to a post-quantum one — a nearly-unsolved problem for live chains in October 2026.

This report covers both halves. **Section 1–2** separate the threat model into entropy weaknesses (solvable today) versus signature-scheme exposure (an open, chain-level migration problem), and give the dice-and-hashing math and MCU TRNG caveats needed to generate a real 256-bit seed on $20–150 of hardware. **Section 3** surveys the air-gapped reference projects that exist as of October 2026 — SeedSigner, Krux, Specter DIY, Blockstream Jade, Keystone, Coldcard, Trezor Safe, and the mandatory reference, **EthereumPhone's PQ1** — on licence, maturity, audit status, and dice support. **Section 4** is the generation-and-backup procedure as a checklist. **Section 5** covers the actual post-quantum signature primitives (SLH-DSA/FIPS 205, ML-DSA/FIPS 204, hash-based escape hatches) and their MCU and on-chain costs. **Section 6** is the migration playbook for an Ethereum BIP-39 user and a Bitcoin user, with a decision table. **Section 7** gives four buildable BOMs with purchase links: a ≤60 EUR variant, a ~150 EUR reference design, a paranoid variant, and PQ1 itself. **Section 8** closes with where the Canary's `isTripped()` fits as a migration trigger, and draft "Prepare" copy for the Canary site.

**The central finding, stated plainly:** as of October 2026, there is no production-ready, audited, funds-safe device or on-chain contract that lets a hobbyist generate a key and sign with a post-quantum scheme for real money, on Ethereum or Bitcoin. PQ1 is the most complete and most honest attempt — it runs on real silicon, signs real SPHINCS+-style transactions, and its own documentation says so: **no PQ1 device has shipped, and no PQ1 on-chain wallet holds funds** `[8]`. Everything recommended here is either (a) entropy-generation hardware you can trust today, or (b) a PQ *signing* path you can build, test with dust, and watch — not yet a vault for savings.

---

## 1. Threat model: what "quantum-resistant seed generation" can and cannot mean

A BIP-39 seed is **symmetric entropy**: 128–256 raw bits, turned into a mnemonic and then into a 512-bit seed via PBKDF2-HMAC-SHA512 `[1]`. Symmetric primitives (AES, SHA-2, SHA-3, PBKDF2, HMAC) are not broken by Shor's algorithm. Grover's algorithm gives a quadratic speedup against brute-force key search, so a quantum adversary searching a 256-bit keyspace faces roughly 2^128 operations instead of 2^256 — still astronomically infeasible, and the standard reason NIST set Category-1 PQ security equivalent to AES-128, not AES-256 `[5]`. **A 256-bit BIP-39 seed generated with real entropy is not weakened by quantum computers in any practically relevant way.** `[Observed]`

What quantum computers break is the **asymmetric** layer derived from that seed: the secp256k1 (Bitcoin, Ethereum) or Ed25519 key pairs your wallet signs with. Shor's algorithm solves the elliptic-curve discrete logarithm problem in polynomial time on a sufficiently large, fault-tolerant quantum computer, recovering a private key from its public key `[36]`. Whether *your* funds are exposed depends not on how the seed was generated but on:

- **Address/script format.** Bitcoin P2PKH/P2WPKH addresses are a hash of the public key; the pubkey itself is not revealed until you spend. Taproot (P2TR) regresses this: the output script *is* the public key, so a Taproot UTXO is quantum-exposed the moment it is funded, not just when it is spent — this is the exact gap BIP-360 (below) targets `[28]`. Ethereum EOAs reveal the public key the first time the address signs anything (the signature itself encodes a recoverable pubkey), so any EOA that has ever sent a transaction has an exposed pubkey sitting in a block forever `[Observed, from ECDSA recovery mechanics; general knowledge, not independently re-derived here]`.
- **Signature scheme**, which section 5 covers at length.
- **Derivation.** A seed used only to derive secp256k1 keys is exactly as exposed as those keys; the seed's entropy quality is irrelevant to this specific exposure.

**Harvest-now-decrypt-later (HNDL) and Mosca's inequality.** An adversary does not need a quantum computer today to benefit from one tomorrow: they can record every exposed public key and every piece of on-chain ciphertext now, and decrypt or forge against it the day a cryptographically-relevant quantum computer (CRQC) exists. Mosca's inequality formalizes the urgency: if `X` (how long your assets must stay safe) plus `Y` (how long migration takes you) exceeds `Z` (years until a CRQC exists), you are already too late `[36]`. The Global Risk Institute's 2025 expert survey put CRQC arrival at 28–49% likely within 10 years and 51–70% within 15 `[36]`. For a cryptocurrency holding with no planned end date, `X` is effectively infinite, which makes `Y` — your own migration speed — the only variable you control. This is the direct argument for building and rehearsing a migration path *before* Q-day, which is what section 6 and the Canary's `isTripped()` trigger are for.

**Design choices that help vs. that are theatre**, against each named failure mode:

| Failure mode | Helps (and why) | Theatre (and why) |
|---|---|---|
| Weak/backdoored RNG | Independent entropy sources mixed via SHA-256/SHA-3 (so one bad source can't dominate); dice rolls you personally generate and can re-derive; NIST SP 800-90B health tests on the hardware source `[3]` | Trusting a vendor's "TRNG" marketing claim without checking the datasheet's actual certified configuration — see §2's STM32U5 example, where the *correct* chip was briefly run in an *uncertified* configuration in a real open-source project `[14]` |
| Supply-chain hardware/firmware | Reproducible, signed, independently-buildable firmware (PQ1's `make verify-repro` `[8]`); off-the-shelf parts you can inspect under a microscope; open secure-element firmware where it exists (Keystone's SE firmware `[19]`, Trezor's TROPIC01 `[20]`) | A closed-source "secure" app on your everyday smartphone with no verifiable build |
| Side channels (power, EM, timing) | TrustZone/MPU isolation, constant-time compares, verify-before-release, tamper/brownout wipe — all present in PQ1's threat model `[8]` as *mitigations*, explicitly not fully validated yet | Claiming "side-channel resistant" without an external FI/SCA lab result — PQ1's own docs are honest that this step (Phase 5) has not happened `[8]` |
| Exfiltration (USB, Wi-Fi, BLE, QR, ultrasound) | **Physically removing** the radio die or never populating it; a true air gap (QR/camera/SD only) | "Disabled in firmware" radios — see the dedicated discussion below; firmware bugs, supply-chain tampering, or a later update can re-enable a radio that still physically exists |
| Operator mistakes | Numbered procedures, test-restores, metal backups, a written "never do this" list (§4) | A single unverified mental checklist |
| Harvest-now-decrypt-later | Never reusing addresses; moving to hash-hiding formats early; building (not necessarily funding) a PQ escape hatch now | Assuming "quantum computers don't exist yet" means the exposure doesn't either — HNDL means it already does for any pubkey already on-chain |

**Why "radios physically removed" beats "disabled in firmware."** A firmware disable is a software state that a firmware bug, a malicious update, a fault-injection glitch, or a supply-chain-modified binary can flip back on; a Wi-Fi/BLE chip that was never populated, or whose antenna trace was never routed, cannot be turned on by any software failure. SeedSigner's choice of the Raspberry Pi Zero **1.3** specifically (no Wi-Fi/Bluetooth silicon on-die, unlike the Zero W) is the canonical example of this principle `[15]`; Blockstream Jade's "No-Radio" firmware variant is the opposite case — it keeps the BLE radio installed and merely disables it in firmware, and Blockstream's own documentation is candid that the radio hardware still contributes boot-time noise even on that build `[18]`. Both are legitimate design points, but only one is "radio-can't-exist," and a hobbyist choosing hardware should know which one they are building.

---

## 2. Entropy sources

**MCU true random number generators and their known weaknesses.**

- **STM32U5** (used by PQ1): has a hardware TRNG that is **NIST SP 800-90B certifiable** in a specific register configuration ("Configuration A" per ST's reference manual RM0456) — ST holds actual CMVP-style entropy-source certificates for several STM32U5 sub-families `[34]`. The caveat is concrete and recent: PQ1's own issue tracker recorded, and fixed, a case where the firmware's documented security claim ("the STM32U585 TRNG meets NIST SP 800-90B in our configuration") was **false as shipped**, because the silicon was running the uncertified "Configuration C" (AIS-31-style) instead of the certified "Configuration A" `[14]`. The lesson generalizes: a chip being *capable* of a certified TRNG mode is not the same as a given firmware actually *using* that mode, and this is exactly the kind of claim a hobbyist builder should re-verify against the datasheet rather than trust from a README. `[Observed]`
- **ESP32**: the on-die TRNG only mixes genuine RF noise into its output **when Wi-Fi or Bluetooth is active**; with both radios off, `esp_random()` degrades to a pseudo-random sequence unless the firmware explicitly calls `bootloader_random_enable()` to pull in an internal entropy source first `[32]`. This is a real trap for anyone building an "air-gapped" ESP32 device by simply not enabling the radios: doing the privacy-correct thing (radios off) silently does the security-wrong thing (no true randomness) unless the firmware is written with this in mind.
- **RP2040** (Raspberry Pi Pico): the datasheet itself states its ring-oscillator-based RNG "does not meet the requirements of randomness for security systems" `[33]`; the bias comes from temperature-dependent oscillator frequency and strong autocorrelation between closely-spaced samples. Raspberry Pi's successor chip, the RP2350, added a proper ARM TRNG IP block specifically to fix this `[33]`. A seed-generation tool built on a bare RP2040 **must not** use the on-chip RNG as its only entropy source.
- **nRF52840** (Nordic): the CryptoCell-310 subsystem includes a TRNG compliant with NIST SP 800-90A/90B and FIPS 140-2 `[35]`, but the chip also exposes a *separate*, non-CryptoCell RNG peripheral used by the BLE stack that is not built to the same standard — a builder must know which peripheral their firmware is actually calling.

**Non-MCU physical entropy**: avalanche/Zener-diode noise (reverse-biased p-n junction — the basis of commercial TRNG USB sticks like ChaosKey and TrueRNG `[41]`), radioactive decay (rare in hobbyist builds, requires a licensed source and a Geiger counter, used mostly as a novelty/teaching demonstration), and camera sensor noise (used by Blockstream Jade as one of several mixed sources `[18]`, and supported as a user-selectable entropy method in SeedSigner `[15]` and Krux `[16]`).

**Dice and coins, with the exact math.** A fair six-sided die carries log₂(6) ≈ 2.585 bits of entropy per roll. To reach 256 bits you need at least 256 / 2.585 ≈ 99.03 rolls — Krux's documentation states this precisely: "a minimum of 99 rolls is required for 256 bits of entropy" for a 24-word mnemonic, and "a minimum of 50 rolls" for 128 bits/12 words `[16]`. For a d20, each roll carries log₂(20) ≈ 4.322 bits, so 60 rolls clear 256 bits `[16]`. **Bias handling**: rolls are not fed into the seed as raw bits one-for-one (that would waste the die's full 6-way resolution and risks subtle bias if any die face is even slightly favored); the standard practice (used by Krux, Keystone, and Ian Coleman's dice tool) is to treat the sequence of rolls as digits of a base-6 (or base-20) number and run it through a cryptographic hash (SHA-256/SHA-3) to compress it uniformly into the target bit length `[16] [19]`. A single visibly loaded or "lucky" die therefore cannot meaningfully bias the output as long as (a) the die is not catastrophically biased and (b) the hash step is applied — but a builder should still use casino-grade precision dice, as Keystone explicitly recommends `[19]`, and should roll enough extra to tolerate a mis-recorded digit.

**Mixing**: hashing (SHA-256 or SHA-3) over multiple *independent* sources — an MCU TRNG, a second secure element's TRNG, and user dice rolls — is the standard, provable way to combine entropy: as long as *any one* input source is a real 256-bit-strength source, the SHA-256 output is uniformly random, which is why mixing is strictly better than trusting a single source `[3]`. PQ1's own approach, XOR-splitting its two secure elements' entropy and running the XOR through HKDF (`E = HKDF(half_O ⊕ half_E)`), is a variant of this same idea aimed specifically at **storage** compartmentalization (neither chip alone holds a usable half) rather than at combining untrusted *sources* `[8]`; it does not by itself substitute for also verifying the quality of each individual TRNG, which is the role of SP 800-90B-style testing.

**Statistical tests and their limits.** NIST SP 800-90B specifies min-entropy estimators (most-common-value, collision, Markov, compression, and others) for certifying an entropy *source*, with sample sizes on the order of 10^6 samples for the restart tests `[3]`. NIST SP 800-22 is a separate statistical test suite (frequency, runs, spectral, serial-correlation tests, etc.) commonly run via tools like `ent` or `dieharder`. **What these tests do *not* prove**: passing SP 800-22/`dieharder` demonstrates the *output looks statistically random*; it cannot detect a cryptographically-constructed backdoor (a deterministic PRNG seeded from a known value, or an entropy source secretly correlated with something an attacker can observe, will pass these tests perfectly while being fully predictable to the attacker). Only a hardware/design-level audit of the *source* itself — not a statistical test of its *output* — can rule that out. This is precisely why SP 800-90B tests the *source and conditioning design*, not just output bitstreams, and why "it passed `dieharder`" is a necessary but far from sufficient claim for a hobbyist to make about their own entropy pipeline. `[Inferred, standard cryptographic-engineering reasoning from the cited NIST documents]`

---

## 3. Air-gap architectures and reference projects

| Project | Licence | Hardware | Maturity (Oct 2026) | Dice/user entropy | Secure element | Known audits/CVEs | Notes |
|---|---|---|---|---|---|---|---|
| **PQ1** `[8][9][10][11]` | GPL-3.0 | STM32U585 (Cortex-M33 TrustZone) + OPTIGA Trust M V3 + NXP SE050 | **Pre-production bring-up.** Boots on real B-U585I-IOT02A + QEMU; **no devices shipped, no on-chain wallet holds funds** | Not dice-based — entropy from MCU+dual-SE TRNGs, mixed via `hw::secret_keys` | Dual SE, XOR-split entropy | On-chain contracts audited 2026-05-18, **3 High findings** (one fund-trapping bug in the factory) `[12]`; firmware audit intake exists but the engagement's findings are not in this repo; firmware-format authority for OTA updates explicitly unresolved `[8][11]` | **Only PQ project here with a working post-quantum signer** (SPHINCS+-style SLH-DSA variant) and an ERC-4337 smart-contract wallet; see §5–7 |
| **SeedSigner** `[15]` | Permissive, "give back" style OSS licence (not MIT/GPL — see repo) | Raspberry Pi Zero (1.3, no radio silicon) + camera + LCD | Mature, widely deployed since 2020; actively maintained | Yes — explicit dice-to-seed module (99 d6 rolls → 24 words), plus camera-noise | None (software-only; "stateless," never writes the seed to persistent storage) | Community-audited by use; no formal third-party security audit found as of this writing `[Open question — 2026]` | Reference implementation for "camera or dice, your choice" entropy UX |
| **Krux** `[16]` | GPL-3.0 (per repo) | Kendryte K210-based boards (Maix Amigo, M5StickV, etc.) | Mature, active | Yes — d6 **and** d20 supported, with the exact entropy math documented | None | No formal third-party audit found as of this writing `[Open question — 2026]` | Best-documented dice-entropy math of any project surveyed |
| **Specter DIY** `[Specter sources via search, see §References note]` | GPL-3.0 (bootloader + firmware) | STM32F469 Discovery board, MicroPython | Mature but smaller community than SeedSigner/Krux; secure-element integration described as "coming" in project docs | Not primarily dice-focused; QR-based air gap | "Agnostic" (no persistent secret) or "reckless" (flash) mode; SE support historically incomplete | No formal third-party audit found as of this writing `[Open question — 2026]` | Good example of "no custom PCB, no exotic parts" philosophy, same spirit as PQ1's DIY page |
| **Blockstream Jade** `[18]` | Open firmware and hardware | ESP32-class + display; can be reflashed onto an M5Stack | Mature, commercially shipped product with years of field use | Yes — user-added dice-roll entropy, mixed with camera/sensor/radio-noise/companion-app sources | **No discrete secure-element chip** — uses a software "virtual secure element" (blind-oracle encryption scheme) instead, a deliberate choice to keep the whole stack open-source (real SE chips are NDA-bound and cannot be fully audited) `[18]` | Commercial product; Blockstream publishes firmware/hardware openly | Good illustration of the "open SE chip vs. open software SE" trade-off discussed in §3.1 below |
| **Keystone (3 Pro)** `[19]` | Partially open (firmware for the SE is open; the SE silicon/mask itself is not, due to vendor IP) | Triple-chip: MCU + two SE chips (e.g. ATECC608B/DS28S60-class), each with its own TRNG | Mature, commercially shipped | Yes — up to 256 dice rolls supported, explicit entropy math in vendor blog | Dual/triple SE | Commercial; no independent public audit report located as of this writing `[Open question — 2026]` | First hardware-wallet vendor to open-source *SE firmware* specifically, while keeping SE silicon design closed |
| **Coldcard** (benchmark, not DIY) `[20]` | Firmware open source; Bitcoin-only | Two SE chips from two different vendors (ATECC608 + DS28C36-class) | Mature, long field history | Supports dice/user-supplied entropy | Dual SE, deliberately multi-vendor | Long field history, several vendor-disclosed fixes over the years | Not a DIY build — closed hardware design — included only as a maturity benchmark per the assignment |
| **Trezor Safe 7** (benchmark, not DIY) `[20]` | Firmware open source throughout; **TROPIC01 SE is the first SE whose hardware design is also published** | Dual-SE (TROPIC01 + a second EAL6+ chip) | Newest flagship, 2026 | Supports user entropy (historical Trezor feature) | Dual SE, one of which (TROPIC01) is open-hardware | Long Trezor audit history on firmware; TROPIC01 is new enough that independent third-party silicon audits were not located as of this writing `[Open question — 2026]` | Notably, **PQ1's own dependency tree carries an unused, feature-gated `tropic01-se` binding** to `tropicsquare/libtropic-rs`, pinned but explicitly not used in the shipping dual-SE configuration `[11]` — the two projects are aware of the same open-SE option |

**3.1 Why "radios physically removed" beats "disabled in firmware" (reprise, hardware-specific).** SeedSigner's Pi Zero 1.3 has no Wi-Fi/BT silicon at all — there is no firmware state to misconfigure `[15]`. Jade's BLE-equipped builds (including "No-Radio" firmware) keep the radio chip on the PCB; Blockstream's own help documentation states the radio hardware still contributes a brief noise sample at boot even when the BLE stack is disabled `[18]` — meaning the hardware is doing *something* electrically even in the "off" state, which is a materially different trust position than a chip that is simply not present. For a hobbyist choosing between these philosophies, the question to ask about any device is not "can I turn the radio off?" but "is there a radio die on this board at all?"

**3.2 Dual-SE vs. open-software-SE vs. no-SE.** Three distinct design philosophies are visible in this table: (1) **dual proprietary SE** (PQ1, Coldcard, Keystone, Trezor Safe 3/5) — strong physical tamper resistance from CC EAL6+-class silicon, at the cost of trusting closed SE firmware/mask design from the vendor; (2) **open-hardware SE** (Trezor Safe 7's TROPIC01) — the newest attempt to get EAL-class tamper resistance *and* a publishable design, not yet independently audited long enough to have a track record; (3) **no discrete SE, software-only protection** (Jade, SeedSigner, Specter DIY in its default mode) — fully auditable at every layer, at the cost of relying on the host MCU's own (weaker) tamper resistance. None of these is strictly "more open-source" than the others in every dimension — PQ1 and Coldcard are open in firmware and buildable from off-the-shelf SE dev-kits, but the SE silicon itself is a black box either way, which is exactly why PQ1's dual-SE XOR split is designed so that a single-vendor SE compromise does not alone leak the seed `[8]`.

---

## 4. Generation and backup procedure — numbered checklist

1. **Prepare the environment.** Work in a room with no networked devices nearby; disable or physically cover any camera/microphone on *other* devices in the room if you are photographing anything. Have a second, independent air-gapped computer ready for step 6.
2. **Obtain the firmware from source**, not a pre-built binary from an unverified host. Clone the project's repository at a specific tagged commit (e.g. `git clone --depth 1 <repo>`), and record the commit hash.
3. **Build reproducibly.** Projects that support it (PQ1: `docs/firmware/reproducible-builds.md`, `make verify-repro` `[8]`) let you confirm that your locally-built binary is byte-identical to any officially published one, closing the gap between "I read the source" and "I am running the source I read." If the project publishes signed release hashes, verify the signature against the maintainers' published key through at least two independent channels (the repository's release page *and* a separate announcement channel) before trusting a hash.
4. **Verify the flashed image on-device, if supported.** PQ1 renders its secure-world image hash as **8 BIP-39 words on the device's own LCD** at boot, specifically so you can compare it to a hash you compute yourself from the exact source tree you built (`make measure`), without needing a second trusted display `[8]`. Treat any device that cannot show you *some* self-attestation of what it is running as unverifiable by design.
5. **Generate entropy on the device**, using whichever method the project documents (TRNG, camera, dice) — and if dice are offered and you want maximum assurance, prefer dice: you can independently re-derive the result.
6. **Verify entropy independently, off-device.** If you used dice, re-run the *exact same* roll sequence through an independent, open-source implementation on a **second, separately air-gapped machine** (a different SBC, a different OS install, built from a different copy of the source) and confirm it produces the identical mnemonic. This step catches a compromised device silently substituting its own entropy for yours — a single device, however well-built, cannot prove this about itself.
7. **Choose your backup format.** BIP-39 (single mnemonic, single point of physical compromise if found) vs. SLIP-39/Shamir Backup (an `m`-of-`n` threshold scheme — no single share, nor fewer than the threshold, reveals anything about the secret `[2]`) vs. raw hex entropy (no checksum, no plausible-deniability wordlist, not recommended for most users). SLIP-39 is strictly stronger against "one share stolen or lost" scenarios but is **not** BIP-39-compatible — pick one before you fund anything, because switching later means a full migration, not a format conversion `[2]`.
8. **Record a metal backup.** Paper burns, floods, and fades; a stamped or engraved steel/titanium plate survives most single-location disasters. Store the mnemonic (or SLIP-39 shares) and, separately, any passphrase.
9. **Add a passphrase (BIP-39 "25th word") if you want plausible deniability or an extra secret factor** — but write down, somewhere equally durable, the fact that a passphrase exists and exactly how you will remember or retrieve it; a seed phrase with a forgotten passphrase is unrecoverable by construction.
10. **Test-restore before funding.** Wipe the device (or get a second identical device), restore from your backup exactly as you wrote it down, and confirm it derives the same addresses/public keys you recorded in step 6. Do this *before* any real value touches the wallet.
11. **Fund with dust first.** Send a trivial, disposable amount to the restored wallet and confirm you can move it back out, before treating the setup as production-ready.
12. **"Never do this" list:**
    - Never type a seed phrase, in whole or in part, into any device that has ever been connected to the internet, including "just this once."
    - Never photograph a seed phrase with a networked phone, even "to delete it right after" — cloud photo backup is often instantaneous and silent.
    - Never reuse the same dice-roll sequence for two different wallets — if logged anywhere, it defeats the point of independent verification in step 6.
    - Never skip the test-restore because the device "obviously worked."
    - Never store the only copy of a metal backup and its passphrase in the same physical location.
    - Never trust a "quantum-resistant" marketing claim on a product without checking, in a repository or datasheet, exactly which signature scheme protects your funds today versus which is merely roadmapped.

---

## 5. Post-quantum readiness

**The seed is fine; the signature path is the problem.** A 256-bit BIP-39 seed already clears NIST's Category-1 PQ security floor `[5]`. What needs to change is what you *derive* from it and *sign with*.

**Address exposure today.** Bitcoin: P2WPKH (SegWit v0) hashes the pubkey — quantum-exposed only after you spend from the address (the signature reveals the key); Taproot (P2TR) **embeds the raw tweaked public key directly in the output script**, so a funded-but-unspent Taproot UTXO is already exposed on-chain, a regression Bitcoin core developers have explicitly flagged and BIP-360 is designed to fix `[28]`. Ethereum: a plain EOA reveals its public key the moment it first signs a transaction (ECDSA signatures are recoverable); a smart-contract account (ERC-4337) does not inherently expose anything beyond what its *own* verification logic requires — which is exactly the lever PQ1 and the ERC-4337-PQ projects below use.

**The 2026 Ethereum protocol-level picture:**
- **EIP-7932 "Secondary Signature Algorithms"** (James Kempton, created 2025-04-12) defines a registry and a precompile so new signature algorithms, each with its own gas-cost multiplier relative to secp256k1, can be added to the protocol without a dedicated hard fork per algorithm `[23]`. As of late 2025/2026 it was in core-dev review, not yet live `[23]`.
- **EIP-8051** proposes an ML-DSA (FIPS 204) verification precompile at a cost "subject to benchmarking" `[23]`. **EIP-8164** proposes a competing gas price for essentially the same operation, roughly 11× higher than EIP-8051's figure — the two proposals have not converged as of this writing `[29]`. **[Open question — 2026]**
- **EIP-8141 "Frame Transactions"** (Vitalik Buterin et al., proposed 2026-01-29) is the broader vehicle: a new transaction envelope letting an account carry a classical *and* a post-quantum signature simultaneously during a transition window, moving toward "signature agility" at the account level rather than a single flag-day migration `[24]`. Reporting in 2026 is inconsistent about timing — Ethereum Foundation roadmap pages placed it in the "Hegotá" fork (2H-2026 target as of early reporting), while later 2026 coverage described a slip to a 2027 target `[24]`. **[Open question — 2026]** Treat any specific fork date for EIP-8141 as unconfirmed.
- **None of EIP-7932/8051/8052/8141 are live on Ethereum mainnet as of October 2026.** `[Observed, from the EIPs' own status fields as reported]` What *is* live today is account abstraction itself (ERC-4337, deployed since 2023, two audited EntryPoint versions v0.6/v0.7 `[27]`) plus EIP-712/ERC-1271/ERC-6492 signature-validation plumbing, which PQ1's own contracts confirm by integrating against EntryPoint v0.6 `[12]` — which is precisely the surface independent developers are using *right now* to bolt PQ verification onto smart accounts without waiting for a protocol change. This is why every live PQ-account project in §6 is an ERC-4337/ERC-7579 **module**, not a protocol fork.

**Bitcoin's 2026 picture: BIP-360.** Originally "Pay-to-Quantum-Resistant-Hash" (P2QRH), merged into the official `bitcoin/bips` repository on 2026-02-11 under the name "Pay-to-Merkle-Root" `[28]`. It is a **soft fork**: a new SegWit witness version (v2, `bc1z...` addresses) whose output commits only to a hash of the taproot leaf, removing Taproot's quantum-vulnerable key-spend path, without requiring any change to legacy address types `[28]`. Critically, **BIP-360 does not itself define a post-quantum signature scheme** — that work was explicitly split into a *future* BIP, expected to use new `OP_SUCCESSx` opcodes (e.g. a hypothetical `OP_CHECKMLSIG`) `[28]`. So even a wallet that adopts BIP-360 today gets hash-hiding (protection for *unspent* coins) but not yet a PQ *signature* for the spend itself — on-spend exposure remains until that follow-on BIP lands `[28]`.

**Hash-based escape hatch from the same seed.** Lamport signatures, WOTS+/XMSS, and SPHINCS+ (now standardized as **SLH-DSA, FIPS 205**) are all built from hash functions only — no number-theoretic or lattice assumption anywhere — making them the most conservative PQ choice, at the cost of large signatures and (for the stateful variants) a fatal one-time-use requirement. PQ1 chose a custom SPHINCS+-style parameter set it calls **C10** (`h=18, d=2, a=11, k=13, w=8, l=43, target_sum=205`): **first signature ≈3 s** (master + slot keygen + two signs), **cached signature ≈1.1 s**, **signature size 4,008 bytes**, with a hard cap of **65,536 uses per key** (and the on-chain contract enforces this cap) `[8]`. These figures are PQ1's own measured results on real B-U585I-IOT02A silicon, not a simulation `[8]`. For MCU-footprint context on the *standardized* schemes: **pqm4** is the standard benchmarking harness for NIST PQC on ARM Cortex-M4 (STM32F4 Discovery, 24 MHz, cycle counts for key generation/sign/verify for both KEMs and signatures) `[21]`; **liboqs** is the reference cross-platform library implementing ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) with pluggable backend implementations (`mlkem-native`, `mldsa-native`, `slhdsa-c`) and, notably, **dropped SPHINCS+-the-pre-standard in favor of SLH-DSA** starting at v0.15.0 `[22]` — a reminder that PQ1's own "C10" parameter set is *not* the standardized SLH-DSA and would need its own from-scratch cryptanalysis trust, which its own audit documentation flags (`sphincs-c10` is "written from scratch, no upstream reference for this parameter set" `[11]`).

**On-chain verification gas, L1 and L2 (2026 figures):**

| Scheme | Verification cost | Notes |
|---|---|---|
| ECDSA (secp256k1, today's baseline) | ~3,000 gas (native precompile) | For comparison only |
| ML-DSA-44, pure-EVM (no precompile) | ~13.5M gas `[29]` | Impractically expensive without a precompile |
| ML-DSA-44, optimized pure-EVM (Fireblocks, Sept. 2026) | **~1.23M gas** | A 6.6× improvement over the prior ZKNox ETHDILITHIUM state of the art (8.09M gas), achieved mainly by optimizing the SHAKE-256 hashing step `[29]` |
| ML-DSA-65, packed/experimental verifier (ZKNox) | ~1.54M gas `[29]` | Experimental |
| ML-DSA, proposed precompile (EIP-8051) | 4,500 gas | Not live; a competing EIP (8164) proposes ~11× higher `[23][29]` |
| Falcon-512, pure-EVM | ~6.6M gas `[29]` | For comparison |
| SLH-DSA-128s (hash-based, small variant) | ≥519,624 gas `[29]` | No EVM precompile proposal exists for SLH-DSA as of this writing |
| SLH-DSA-128f (hash-based, fast variant) | ≥1,110,472 gas `[29]` | Larger signature, faster signing, more verification gas |
| PQ1's custom SPHINCS+-style C10 verifier, real deployment (Base mainnet) | **180,306 gas for the verifier alone; 229,830 gas for the full `validateUserOp`** `[12]` | Measured by PQ1's own 2026-05-18 third-party audit; notably *cheaper* than the generic SLH-DSA figures above because C10 is a smaller, custom parameter set — which is also exactly why it carries unique, unreviewed cryptanalytic risk `[11]` |

On an L2 such as Base, these gas figures translate to a fraction of a cent to a few cents per transaction at typical 2026 L2 gas prices; on Ethereum L1 itself, even the cheapest current ML-DSA path (~1.23M gas) costs roughly 400× a plain ECDSA transfer, which is the practical argument for doing PQ verification on an L2 or inside an L1 smart account only when necessary, rather than for every transaction. `[Inferred from the gas figures above; $ conversion depends on live gas price and is not asserted here]`

---

## 6. Migration: from a standard wallet to a quantum-resistant one

**What exists today (October 2026), concretely:**

- **Ethereum, ERC-4337 account + PQ verifier module.** No canonical, audited "Safe PQ module" exists from the Safe Foundation itself. What exists is a cluster of independent, unaudited ERC-7579 validator modules: **Qanary** (tiered: an ML-DSA/Falcon root validator for sensitive operations, a hot ECDSA/passkey tier for small transfers; explicitly built for Safe 1.3.0/1.4.1, Kernel v3.3, and OpenZeppelin accounts) `[31]`; **PQ Wallet** (ZeroDev Kernel v3.3 + ZKNox on-chain verifiers, hybrid classical/PQ) `[31]`; **PQ Nexus** (Biconomy, a ~130-line validator requiring a SPHINCS-family signature only, live on Ethereum today via ERC-4337/ERC-7579 with no protocol change) `[31]`; **pq-evm-account** (hybrid SPHINCS-C13 ERC-4337 account, 105.7K gas, explicitly flagged by its own author as "research-grade... validated by testing, not review") `[31]`. **And PQ1 itself**: a working ERC-4337 v0.6 `PQSmartWallet` behind an ERC-1967 proxy, with a from-scratch SLH-DSA-style verifier, **deployed on Base mainnet** (not Ethereum L1) at `PQSmartWalletFactory 0xe8CE78CD976497447FF8B76c71b59aE42Af0d452`, with **source intentionally not published** for the deployed bytecode and the deployment explicitly marked `"verified": false` `[13]`. Its own third-party audit, dated 2026-05-18, found **three High-severity issues** (including a bug that permanently traps `msg.value` sent to an already-deployed wallet) and confirms **no Critical finding and no identified remote-fund-loss path for an arbitrary attacker** — but also that the audit is of the contracts only, that the firmware audit is a separate, incomplete engagement, and that **no PQ1 wallet anywhere holds real funds** `[8][11][12]`. **[Observed — this is the most mature PQ smart-account path found, and it is explicitly pre-production.]**
- **Safe modules, generally.** Safe{Core} + Rhinestone's ERC-7579 adapter (live, audited as a general modular-account mechanism, not PQ-specific) is the plumbing the above PQ modules attach to `[31]`. No Safe-maintained PQ module was found as of this writing. **[Open question — 2026]**
- **Bitcoin options and limits.** BIP-360/P2MR (merged 2026-02-11) gives hash-hiding for new Taproot-successor outputs, deployable as a soft fork with no change to legacy address types `[28]`. It does **not** yet define a PQ signature scheme for the spend itself — that is explicitly deferred to a future BIP using new `OP_SUCCESSx` opcodes `[28]`. **There is currently no way to make a Bitcoin *spend* post-quantum-safe; BIP-360 only protects unspent, not-yet-exposed outputs going forward.** A companion proposal (BIP-361, more speculative and contested) would force migration of exposed legacy coins and could freeze long-dormant addresses, including coins widely attributed to Satoshi Nakamoto — this remains an open, actively debated governance question, not a deployed mechanism `[28]`.

**Order of operations for a migration (Ethereum, BIP-39 seed in a classic hardware wallet):**

1. Inventory everything the old seed controls: ETH, every ERC-20 token, every NFT, any staked positions (and their withdrawal addresses/validators), ENS names, and every outstanding token approval.
2. Choose a PQ account path from the list above, understanding that **every one is unaudited-for-production or explicitly pre-production**. Test it on a testnet or with the smallest possible real amount first.
3. Deploy the PQ smart account (e.g. via the chosen factory's `createAccount`-style call). Record its address.
4. Send a dust amount from the old wallet to the new PQ account and confirm you can move it back out, before anything else.
5. Move ETH in a size you are comfortable losing to a configuration error, wait, confirm, then move the remainder.
6. Move ERC-20 tokens the same way, batch by batch.
7. Move NFTs — note that many marketplaces and NFT contracts assume EOA-style signing (EIP-712/ERC-1271/ERC-6492) and some older contracts may not recognize a smart-contract-account owner correctly; test with a low-value NFT first.
8. Unstake or redirect staked positions according to their specific unbonding/exit rules (which can take days to weeks and are chain/protocol specific — not covered further here, as this varies too much to generalize safely).
9. Transfer or re-point ENS names to the new address (ENS ownership and resolver records are standard on-chain state and can be updated like any other contract call once you control the old key).
10. **Revoke every outstanding token approval on the old address** before retiring it — a forgotten unlimited approval left on an exposed-pubkey address is a standing risk even after you've "moved," since the approval lets the *spender* contract move tokens the old key authorized, independent of whether you still use that key. Tools such as revoke.cash exist specifically for this, support 100+ EVM chains, and as of 2026 also offer an automated/scheduled revocation feature `[42]`; Etherscan's own Token Approvals page is a built-in alternative for Ethereum mainnet `[42]`.
11. Only after all of the above, treat the old seed as retired: do not sign anything further with it. Its public key is permanently exposed on-chain regardless of what you do next — **this cannot be undone**, which is the report's recurring point about what spending reveals.

**What moving reveals.** Every signature you have ever made with a secp256k1/Ed25519 key permanently publishes a recoverable public key. Migrating does not erase that history — it only stops adding to it. An attacker with a future CRQC who harvested your old signatures can still derive your old private key and spend anything left behind on the old address (hence step 10's urgency on approvals, and step 5–8's urgency on balances) `[Inferred from §1's HNDL framing]`.

**Gas costs.** Deploying a new smart account plus moving each asset class is a multiple of ordinary transaction costs (deployment alone is a contract-creation transaction; each asset move is a separate transfer). At current ML-DSA verification costs (~1.23M gas per PQ-validated operation on L1, per §5) versus ~21,000 gas for a plain ETH transfer, a full L1 migration with PQ verification active from the first transaction is materially more expensive than the legacy equivalent; doing the *migration* transactions themselves with the old ECDSA key (cheap) and only turning on PQ verification as the account's *ongoing* signer afterward is the cheaper order, where supported.

**Chains with no PQ option.** As of October 2026, outside of Ethereum/Base-style EVM chains with ERC-4337 support and the handful of experimental modules above, essentially no other major chain (Solana, most other L1s) has a deployed, even-experimental PQ account-abstraction path that this research could verify. **[Open question — 2026]** Treat any chain not explicitly named in this report as "no known PQ option today" rather than assuming one exists.

**Pre-authorizing a migration to execute the day the Canary trips.** This is the mechanism the Canary's `isTripped()` is designed to gate, and as of October 2026 it does not exist as an off-the-shelf, audited product. The shape is inferable from existing primitives: a Safe **Guard** or a 4337 account's **validator module** could, in principle, hold a pre-registered PQ public key in a dormant state and only accept a signature from it (or only allow an owner-rotation to it) once an external call to the Canary contract's `isTripped()` returns `true` `[40]`. **[Inferred — no implementation of this specific pattern was found in any repository surveyed for this report.]** Open questions this raises, unresolved as of 2026: who audits the guard/module itself; what happens on a false trip (the Canary's bounty balance could in principle drop for a reason unrelated to a real break, e.g. the bounty being swept by its own ownerless design or a contract bug); and whether "pre-authorize now, execute later" creates its own standing attack surface (a dormant PQ owner key is itself a target worth harvesting now). **[Open question — 2026]**

**Unaudited contracts vs. waiting for protocol changes — the decision table:**

| Your situation | Recommendation | Why |
|---|---|---|
| Large, long-term holdings (retirement-scale); low risk tolerance | **Wait**, but build and test a PQ path with dust *now* | No audited, production PQ account exists; moving real funds into an unaudited contract (3 High findings on the best-documented one `[12]`) trades a speculative future risk for a concrete present one |
| Active trading funds, frequently moved anyway | **Prepare**: deploy a PQ smart account, test thoroughly, keep it empty or near-empty, rehearse the move | Low cost to prepare; funds are already in motion so quantum exposure accrues regardless, and you've already absorbed migration friction as part of normal use |
| Exposed Taproot or re-used EOA addresses with meaningful balance | **Migrate now to a hash-hiding format** (new BIP-360 output / fresh EOA with no history) even without a PQ signature yet | §5's point: hiding the pubkey from being on-chain at all is available today and cheap; it buys time even where no PQ *signature* exists yet |
| Dormant, never-spent-from Bitcoin P2WPKH/P2SH holdings | **Wait** | The pubkey is not yet exposed; moving funds to "migrate" would itself be the spend that exposes the key, which is self-defeating |
| Developers/technical hobbyists wanting to validate the whole pipeline | **Prepare, with PQ1 or an equivalent** | This is exactly PQ1's stated audience and purpose — build it, read every line, understand the gap between what's proven and what isn't, before anyone's money depends on it `[9]` |
| Anyone holding assets on a chain with no PQ option at all | **Wait and watch**; there is nothing actionable to prepare yet | Preparing requires *something* to deploy; where nothing exists, the only lever is monitoring (e.g. the Canary itself) and advocacy for the chain to add one |

---

## 7. Recommended builds

All prices are approximate as of October 2026 and drift; **trust the linked product pages, not this column.**

### 7.1 Reference design (~150 EUR) — PQ1 bench rig

This is PQ1's own documented, as-shipped-in-the-repo bill of materials `[9]`, included here because it is the only build in this report with a working post-quantum *signer* behind it.

| Part | Role | Buy | Price |
|---|---|---|---|
| ST B-U585I-IOT02A Discovery kit | MCU: STM32U585 (TrustZone), HW SHA-256/SAES/TRNG, on-board ST-LINK | [Mouser](https://www.mouser.com/ProductDetail/STMicroelectronics/B-U585I-IOT02A) | ~$70 |
| Infineon OPTIGA Trust M Shield (`TRUSTMV3SHIELDTOBO1`) | Secure element #1 — holds XOR half of seed entropy | [Mouser](https://www.mouser.com/ProductDetail/Infineon-Technologies/TRUSTMV3SHIELDTOBO1) | ~$15 |
| NXP OM-SE050ARD-E dev kit | Secure element #2 — holds other half + silicon PIN counter | [Mouser](https://www.mouser.com/ProductDetail/NXP-Semiconductors/OM-SE050ARD-E) | ~$40 |
| NV3007 1.65″ IPS display, SPI breakout | Trusted display — PIN entry, seed words, tx rendering | [AliExpress](https://www.aliexpress.com/item/1005008894658602.html) · [reference module](https://www.buydisplay.com/1-65-inch-142x428-ips-tft-lcd-display-module-for-arduino-raspberry-pi) | ~$10 |
| 400-pt breadboard | Holds OPTIGA shield + buttons | [Mouser (BB400T)](https://www.mouser.com/ProductDetail/BusBoard-Prototype-Systems/BB400T) | ~$7 |
| Jumper wires (M–F + M–M packs) | Wiring | [Mouser (Adafruit 826)](https://www.mouser.com/ProductDetail/Adafruit/826) · [Mouser (Adafruit 758)](https://www.mouser.com/ProductDetail/Adafruit/758) | ~$9 |
| 2× 6mm tactile buttons | LEFT/RIGHT confirm input | [Mouser (Omron B3F-1000)](https://www.mouser.com/ProductDetail/Omron-Electronics/B3F-1000) | ~$1 |
| Micro-USB + USB-C cables | Flashing + power/HID | — | you likely own these |

**Total ≈ $150** `[9]`. **Firmware to fork:** [`EthereumPhone/PQ1`](https://github.com/EthereumPhone/PQ1), GPL-3.0 `[8]`. **Entropy pipeline:** STM32U5 TRNG + OPTIGA TRNG + SE050 TRNG, XOR-split and HKDF-mixed into a BIP-39 seed `[8]`. **What to verify at each stage:** §4's checklist, step-by-step, plus PQ1's own `make measure`/8-word boot fingerprint for firmware self-attestation `[8]`. **Residual risks:** pre-production firmware with documented regressions (TAMP log-only not wipe, un-rotated factory SE keys, no boot-time SE attestation yet `[11]`); custom, unreviewed SLH-DSA parameter set (`sphincs-c10`, "no upstream reference" `[11]`); on-chain contracts carry 3 unresolved/fixed-but-recently-found High findings and are explicitly not production-authorized `[12]`; **do not fund this build with real value.**

### 7.2 Budget variant (under 60 EUR) — dice-verified BIP-39 generator, no PQ signing

This variant optimizes for the cheapest *trustworthy entropy-generation* path, explicitly **not** a PQ signer — nothing at this price point signs with a post-quantum scheme as of October 2026.

| Part | Role | Buy | Price |
|---|---|---|---|
| Raspberry Pi Pico (bare, no Wi-Fi/BT silicon) | MCU — but see §2: do **not** rely on its on-chip RNG alone | [Pimoroni](https://shop.pimoroni.com) / [Adafruit](https://www.adafruit.com) listings | ~€5 |
| 0.96″ SSD1306 OLED (I2C) | Display for mnemonic words | [Adafruit PiOLED](https://www.adafruit.com/product/3527) or a generic SSD1306 module | ~€8–15 |
| 2× casino-grade d6 dice | **Primary entropy source** (99 rolls → 256 bits, per §2's math `[16]`) | any specialty game shop; avoid novelty dice | ~€5 |
| Breadboard + jumper wires | Wiring | [Mouser (Adafruit 826/758)](https://www.mouser.com/ProductDetail/Adafruit/826) | ~€10 |
| Micro-USB cable | Flashing/power | — | you likely own this |

**Total ≈ €30–40.** **Firmware to fork:** a minimal, auditable BIP-39 generator — the dice-handling logic in [`selfcustody/krux`](https://github.com/selfcustody/krux) (GPL-3.0) `[16]` is the best-documented reference for the exact base-6-to-hash conversion; porting its dice module to a bare MicroPython/CircuitPython build on the Pico is the realistic scope for a weekend project. **Entropy pipeline:** dice rolls → base-6 digit string → SHA-256 → BIP-39 mnemonic; the Pico's own RNG is **not** used as a trust anchor (§2). **What to verify:** re-derive the mnemonic from the logged roll sequence on a second machine (§4 step 6) — this is *more* important on a budget build precisely because there is no secure element and no measured-boot self-attestation to lean on. **Residual risks:** no air-gap enforcement beyond "don't plug in a network cable" — this build has no radio to remove in the first place but also no tamper resistance of any kind; it is an entropy-generation and backup tool, not a signing device, and should feed a separate signing wallet (software or a commercial hardware wallet) rather than hold keys itself.

### 7.3 Paranoid variant (~250–300 EUR)

Adds an independent, open-hardware physical-noise TRNG as a *third*, out-of-band entropy source beyond the reference design's on-chip and SE TRNGs, plus a Faraday enclosure and full metal-backup kit.

| Part | Role | Buy | Price |
|---|---|---|---|
| Everything in §7.1 (PQ1 reference build) | PQ signer + dual-SE seed storage | (see above) | ~$150 |
| Infinite Noise TRNG or ChaosKey (open hardware, avalanche/reverse-biased-junction noise) | Independent third entropy source, generated and mixed in *before* flashing the device, by hand-entering the extra entropy as an additional dice-equivalent input where the firmware's seed wizard allows a mixed/advanced entropy mode | [Crowd Supply — Infinite Noise TRNG](https://www.crowdsupply.com/leetronics/infinite-noise-trng) (approx. $35) or [ChaosKey via Tindie/awesome-hwrng list](https://github.com/atoponce/awesome-hwrng) (approx. $40) `[41]` | ~€30–40 |
| Faraday bag or small enclosure | Defense against RF exfiltration during generation, not a cryptographic control but a physical-layer one | any RF-shielding bag retailer | ~€20 |
| Stainless steel seed-backup plate kit (2×, for geographically separated storage) | Metal backup, §4 step 8 | any metal-seed-backup retailer | ~€40–60 |
| 2× casino-grade dice sets | Extra independent entropy, cross-checked against the TRNGs | as §7.2 | ~€10 |

**Total ≈ €250–300.** **Entropy pipeline:** STM32U5 TRNG ⊕ OPTIGA TRNG ⊕ SE050 TRNG ⊕ external avalanche-noise TRNG ⊕ user dice, all hashed together before derivation — maximizing the number of *independent* sources any single one of which being compromised does not compromise the whole, per §2's mixing argument `[3]`. **What to verify:** everything in §7.1, plus independently test the external TRNG's raw output with `dieharder`/`ent` before trusting it as an input (§2's caveat about what statistical tests do and do not prove still applies). **Residual risks:** same firmware/contract caveats as §7.1 — more entropy sources do not fix an unaudited signature verifier or a pre-production firmware regression; this variant hardens step 2 of the threat model (entropy) without changing the state of step-5/6 (PQ signature scheme) maturity at all.

### 7.4 PQ1 BOM as a standing option

Identical to §7.1 — listed separately per the assignment because it is simultaneously the reference design *and* the only option in this report with a real PQ signature path; a reader choosing "build the PQ1" should re-read §3's audit-status row and §6's "do not fund this" caveat before treating it as more than a research/learning build.

### 7.5 Which suits which user

- **Technically curious, wants to understand entropy and backups, no interest in PQ signing yet:** §7.2 (budget).
- **Wants a working, inspectable PQ smart-contract-wallet signer to learn from and test with dust, standard hobbyist budget:** §7.1/§7.4 (PQ1 reference).
- **Wants the strongest entropy assurance achievable at hobbyist cost, is willing to pay for it:** §7.3 (paranoid).
- **Wants a production-ready device to actually hold savings today:** none of the above — see §6's decision table; the honest answer in October 2026 is a mature commercial product (Coldcard, Trezor Safe) for *classical* custody, combined with the hash-hiding and approval-hygiene steps in §6, while treating PQ migration as "prepare," not "migrate now."

---

## 8. Where the Quantum Canary fits

The Canary (`QuantumCanary`, verified contract `0x626517225096671868609c1bbf9c1b416a4efd9a`, Ethereum mainnet `[39]`) holds a derived address funded to a 1 ETH threshold; `poke()` lets anyone check whether that balance has dropped below its recorded high-water mark, and `isTripped()` returns true the moment it has — the contract's own stated premise is that such a drop, from an address whose key was never otherwise touched, "warns that... a quantum computer has broken secp256k1" `[39]`. It is intentionally minimal and ownerless: it does not hold your funds, migrate anything, or make any decision on your behalf. It is a **signal**, not an action.

This report is the action side of that pairing. What the Canary's `isTripped()` can trigger, once the pieces in §6 mature past "unaudited and pre-production":

- A **dormant, pre-registered PQ owner key** sitting in a Safe guard or ERC-4337 validator module, inert until `isTripped()` returns true (§6, "pre-authorizing a migration") — not available off-the-shelf today, but the primitive pieces (ERC-7579 modules, Safe guards, external contract calls) all exist now.
- A **rehearsed, dust-tested migration procedure** (§6's order of operations) that a holder has already run once, so that when the signal fires, executing it for real is a repeat of a known-good drill, not an improvisation under panic.
- An **offline-generated, independently-verified seed** (§4) feeding whichever signing path — classical today, PQ tomorrow — the holder has chosen, so that the one irreplaceable asset (real entropy, generated and backed up correctly) is already secured regardless of which signature scheme ultimately wins the migration race.

**Draft "Prepare" section text for the Canary site** (matching the Canary's own terse, dark, monospace register — see `quantum-canary.sites.imd.fun`'s styling, e.g. "An ownerless alarm for a break in secp256k1" `[40]`):

> **Prepare**
>
> The Canary doesn't move your funds. It watches one address and tells you the day secp256k1 breaks — `isTripped()`, true or false, nothing else.
>
> What you do with that signal is not this contract's problem. It's yours, and it starts before the trip, not after.
>
> **The DIY guide** — [Quantum Canary · Prepare](#) — covers what the alarm can't: how to generate a seed offline with entropy you can verify twice, what a hash-based signature actually costs you in milliseconds and gas, and the exact order of operations to move ETH, tokens, NFTs, and ENS off an exposed key before the exposure matters. It names the one project that has a post-quantum signer running on real silicon today (PQ1 — no funds on it yet, and it says so itself), and the one Bitcoin proposal that hides a key before you spend from it (BIP-360 — not yet a post-quantum signature, and it says so too).
>
> Read it before the balance moves. Not after.

---

## References

1. BIP-39, "Mnemonic code for generating deterministic keys," `bitcoin/bips`. https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
2. SLIP-0039, "Shamir's Secret-Sharing for Mnemonic Codes," SatoshiLabs. https://github.com/satoshilabs/slips/blob/master/slip-0039.md ; reference implementation: https://github.com/trezor/python-shamir-mnemonic
3. NIST SP 800-90B, "Recommendation for the Entropy Sources Used for Random Bit Generation." https://nvlpubs.nist.gov/nistpubs/SpecialPublications/nist.sp.800-90b.pdf
4. NIST SP 800-22, "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications." https://csrc.nist.gov/publications/detail/sp/800-22/rev-1a/final
5. NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), finalized 2024-08-13. https://csrc.nist.gov/pubs/fips/203/final ; https://csrc.nist.gov/pubs/fips/204/final ; https://csrc.nist.gov/pubs/fips/205/final
8. EthereumPhone/PQ1, README.md. https://github.com/EthereumPhone/PQ1/blob/master/README.md
9. EthereumPhone/PQ1, DIY.md. https://github.com/EthereumPhone/PQ1/blob/master/DIY.md
10. EthereumPhone/PQ1, SECURITY.md. https://github.com/EthereumPhone/PQ1/blob/master/SECURITY.md
11. EthereumPhone/PQ1, FIRMWARE_AUDIT_INTAKE.md. https://github.com/EthereumPhone/PQ1/blob/master/FIRMWARE_AUDIT_INTAKE.md
12. EthereumPhone/PQ1, `contracts/smart-wallet/AUDIT_2026-05-18.md`. https://github.com/EthereumPhone/PQ1/blob/master/contracts/smart-wallet/AUDIT_2026-05-18.md
13. EthereumPhone/PQ1, `contracts/smart-wallet/deployments/base-mainnet.json`. https://github.com/EthereumPhone/PQ1/blob/master/contracts/smart-wallet/deployments/base-mainnet.json
14. EthereumPhone/PQ1, Issue #704 ("TRNG runs RM0456 configuration C, not NIST-certifiable configuration A"). https://github.com/EthereumPhone/PQ1/issues/704
15. SeedSigner/seedsigner, GitHub repository and documentation. https://github.com/SeedSigner/seedsigner
16. selfcustody/krux, GitHub repository and documentation (dice entropy math). https://github.com/selfcustody/krux ; https://selfcustody.github.io/krux/getting-started/usage/generating-a-mnemonic/
17. cryptoadvance/specter-diy, GitHub repository. https://github.com/cryptoadvance/specter-diy
18. Blockstream, Jade hardware wallet product page and help documentation (entropy sources, No-Radio firmware). https://blockstream.com/jade/ ; https://help.blockstream.com/blockstream-jade/faq
19. Keystone, blog post on triple secure-element architecture and dice entropy. https://blog.keyst.one/inside-the-vault-how-keystone-3-pro-secures-your-crypto-with-triple-se-chips
20. Trezor Safe 7 / Coldcard comparison coverage, 2026 (TROPIC01 open-hardware secure element; Coldcard dual-vendor SE). https://cryovaultsolutions.com/blog/trezor-safe-7-review-2026 ; https://www.pipeflare.io/compare/coldcard-vs-trezor
21. Kannwischer, Rijneveld, Schwabe, Stoffelen, "pqm4: Testing and Benchmarking NIST PQC on ARM Cortex-M4." https://eprint.iacr.org/2019/844 ; repository: https://github.com/mupq/pqm4
22. Open Quantum Safe, liboqs. https://github.com/open-quantum-safe/liboqs ; algorithm status: https://openquantumsafe.org/liboqs/algorithms/
23. EIP-7932, "Secondary Signature Algorithms." https://eips.ethereum.org/EIPS/eip-7932 ; EIP-8051, "Precompile for ML-DSA signature verification." https://eips.ethereum.org/EIPS/eip-8051
24. EIP-8141, "Frame Transactions," and 2026 reporting on its status/timing. https://bex.co/blog/2026/03/03/ethereum-quantum-defense-roadmap-eip-8141 ; https://ethereum.org/roadmap/security/quantum-resistance/
27. ERC-4337, "Account Abstraction Using Alt Mempool." https://eips.ethereum.org/EIPS/eip-4337
28. BIP-360, "Pay-to-Quantum-Resistant-Hash / Pay-to-Merkle-Root," merged into `bitcoin/bips` 2026-02-11. https://bip360.org/ ; discussion: https://delvingbitcoin.org/t/proposing-a-p2qrh-bip-towards-a-quantum-resistant-soft-fork/956
29. Fireblocks, "Post-Quantum Ethereum Signatures: 6.6× Cheaper Gas" (Sept. 2026); ZKNoxHQ/ETHDILITHIUM; survey gas-cost table for SLH-DSA. https://www.fireblocks.com/blog/post-quantum-signatures-ethereum-cheaper-gas ; https://github.com/ZKNoxHQ/ETHDILITHIUM
31. Independent ERC-7579/4337 PQ module repositories: Qanary, PQ Wallet, PQ Nexus, pq-evm-account. https://github.com/RaYYeR220/qanary ; https://github.com/krzysu/pq-wallet ; https://github.com/bcnmy/pq-nexus-demo ; https://github.com/lvingsarcophagus/pq-evm-account
32. Espressif ESP32 hardware RNG behavior (true-random only with RF subsystem or `bootloader_random_enable()` active). https://docs.zephyrproject.org/latest/build/dts/api/bindings/rng/espressif,esp32-trng.html
33. RP2040 datasheet language on ring-oscillator RNG unsuitability for security use; RP2350 TRNG addition. https://github.com/zephyrproject-rtos/zephyr/pull/120946 ; https://dmo.page/2022/10/02/rp2040-randomness-and-ring-oscillator/
34. STMicroelectronics, AN4230 and STM32U5 TRNG NIST SP 800-90B certification configuration notes. https://www.st.com/resource/en/application_note/an4230-introduction-to-random-number-generation-validation-using-the-nist-statistical-test-suite-for-stm32-mcus-and-mpus-stmicroelectronics.pdf
35. Nordic Semiconductor, nRF52840 Product Specification and CryptoCell-310 infocenter documentation (TRNG, NIST SP 800-90A/90B, FIPS 140-2 compliance). https://infocenter.nordicsemi.com/topic/ps_nrf52840/cryptocell.html
36. Mosca's inequality / harvest-now-decrypt-later framing; Global Risk Institute Quantum Threat Timeline Report 2025. https://quantakrypto.com/blog/moscas-theorem-post-quantum ; https://www.encryptionconsulting.com/education-center/harvest-now-decrypt-later/
39. Etherscan, `QuantumCanary` verified contract source and ABI. https://etherscan.io/address/0x626517225096671868609c1bbf9c1b416a4efd9a#code
40. Quantum Canary site. https://quantum-canary.sites.imd.fun/
41. Comparison of open-hardware USB TRNGs (Infinite Noise TRNG, ChaosKey, OneRNG). https://github.com/atoponce/awesome-hwrng ; https://www.crowdsupply.com/leetronics/infinite-noise-trng
42. revoke.cash, token-approval revocation tool and 2026 feature updates. https://metamask.io/news/revoke-cash-auto-revoking-token-approvals ; ERC-6492 signature validation for predeploy contracts, https://eips.ethereum.org/EIPS/eip-6492

*Numbering follows citation order of first use; some reference numbers (6, 7, 25, 26, 30, 37, 38) correspond to background sources (Shor's/Grover's algorithm general mechanics, EIP-7980/8052 companion precompiles, NIST PQC program overview) consulted during research but not quoted with a standalone claim above, and are omitted here to avoid citing a source for a sentence it does not support.*