25 quantum-wallet myths, answered from the source code

Last updated Jul 31, 2026

We announced PQ1™ and the replies arrived at speed. Some of them were right. Most of them were the same twenty-five claims, repeated with increasing confidence by people who had not read a line of the firmware, which is fair enough, because until recently there was nothing to read.

There is now. The firmware is GPLv3, the contracts are MIT, the whole wallet boots in QEMU with make play, and the bill of materials is $150 of off-the-shelf parts with Mouser links. So this post answers all twenty-five against the actual source, in order of how much they matter.

Four of them are correct, and we say so.

Part 1: what a quantum computer actually does

Most of the thread was arguing about the wrong attack.

Myth 5. Quantum computers attack by guessing or brute-forcing private keys.

They do not. Shor’s algorithm is not a faster search. It solves the discrete logarithm problem in polynomial time, which means that given an elliptic-curve public key, it recovers the private key directly. There is no guessing involved and no amount of entropy helps. Moving from secp256k1 to a 521-bit curve buys you nothing, because the attack scales with the logarithm of the key size, not the key size.

This is why “just use a longer key” is not a strategy, and why the whole industry has to change algorithms rather than parameters.

Myth 6. The vulnerable part is the seed phrase, not the signature algorithm.

The seed was never the quantum problem. A BIP-39 24-word mnemonic carries 256 bits of entropy. The best known quantum attack on a symmetric secret is Grover’s algorithm, which gives a quadratic speedup, so 256 bits of entropy becomes an effective 128 bits, which is not an attack, it is a rounding error. The same is true of every symmetric primitive in PQ1: the per-slot slot_entropy is a 256-bit SHA-256 output, and the AES and HMAC constructions are sized so that Grover leaves at least 128 bits standing.

What breaks is the signature. Every time an Ethereum EOA sends a transaction, it publishes an ECDSA signature from which the public key is recoverable. That public key is a permanent, public Shor target. Your words are fine. Your spend authority is not.

Myth 14. Quantum computers break every form of crypto equally, so a new wallet changes nothing.

This is the single most consequential misunderstanding in the thread, because if it were true, nothing would be worth building.

There are two quantum algorithms that matter and they are not remotely equivalent. Shor is catastrophic and specific: it destroys RSA, Diffie-Hellman, and every elliptic-curve scheme, completely. Grover is generic and mild: it halves the effective security of symmetric primitives and hash functions, and it parallelises badly, so real-world speedups are worse than the theoretical bound.

Hash functions are in the second category. That is the entire reason hash-based signatures exist. SPHINCS+ builds a signature scheme out of nothing but a hash function, so forging one reduces to breaking SHA-256, and SHA-256 against a quantum adversary is a 128-bit problem. There is no Shor structure in a Merkle tree to attack.

“Quantum breaks everything” is a sentence that sounds cautious and is actually the most dangerous claim in the thread, because it is an argument for doing nothing.

Myth 22. The seed is XOR-split across two secure elements, but that still does not stop a quantum attack on the public key.

Correct, and it was never meant to. These are two different problems and PQ1 solves them separately.

The XOR split addresses seed confidentiality. BIP-39 entropy is split so that half_O lives on the Infineon OPTIGA Trust M V3 and half_E on the NXP SE050, two chips, two vendors, two supply chains, both CC EAL6+. Either chip alone reveals literally zero bits. The reconstruction E = HKDF(half_O ⊕ half_E) happens only in secure SRAM, for microseconds, then is zeroized.

Spend authority is a separate question, and it is answered by the signature scheme. PQ1’s on-chain public key is a 32-byte SPHINCS+C10 key. Publishing it gives a quantum computer nothing to work with, because there is no hidden algebraic structure behind it, only a hash. The threat model puts it in one line: Shor against a classical signature in the trust path, mitigation, none exist.

If PQ1 signed with ECDSA, the dual secure element split would be exactly as useless as this objection claims. It does not.

Myth 25. People reposting this are spreading nonsense, because public-key exposure is the only real threat vector.

Half right, and the half that is right is our whole argument. Public-key exposure is the quantum threat vector. That is precisely why we changed the signature scheme rather than the key storage.

But “the only real threat vector” is wrong, and expensively so. On 21 February 2025, Bybit lost roughly $1.4 billion. Every signer used a hardware wallet, every signer approved, and no cryptography was broken at all. The attack was a single byte, operation = 1, that appeared on no screen in the loop. Blind signing has cost the industry more money than quantum computers ever will, at least so far. PQ1 decodes Safe transactions on the device and refuses every DELEGATECALL it cannot honestly explain, which has nothing to do with quantum computing and everything to do with why we built a device rather than a library.

Part 2: “just don’t reuse addresses”

This was the most upvoted family of replies, and it is the one that will cost people money.

Myth 2. The only way to be quantum-proof today is to use an address that has never sent a transaction.

This is technically true and practically a trap.

On Ethereum an address is the last 20 bytes of keccak256(public_key). If you have never sent a transaction, your public key has never been published, so a quantum adversary would need a hash preimage rather than a discrete log, which is infeasible. So far so good.

Now notice what you have actually bought. You have a vault you can never open. The moment you spend, the transaction carries a signature from which your public key is recoverable, and it sits in a public mempool for several seconds before it is mined. A quantum adversary fast enough to matter is a quantum adversary fast enough to derive your key from that mempool transaction and front-run you with a higher fee. Your protection expires at exactly the moment you need to use your money.

Worse, this advice only helps people who have never transacted. It says nothing to everyone whose public key is already on chain, permanently and irrevocably, which is essentially every active address in Ethereum’s history. You cannot un-publish a public key.

So the correct reading is: a never-used address is a stay of execution, not a solution. The solution is an account whose signature rule is post-quantum, so that publishing the public key costs you nothing at all.

Myth 23. A wallet that can only be used once, never reused, is a practical long-term solution.

It is a discipline, not a system, and disciplines fail at scale. One-time-use key management works exactly until a human is tired, or a wallet’s change logic is subtly wrong, or a contract needs to call you back at the same address, or you want a stable address that people can pay to.

It is worth being precise about the adjacent fact here, because it is the thing people confuse it with. SPHINCS+ is a few-time construction wrapped into a stateless one, and it does carry a usage budget. In PQ1’s C10 parameter set the hypertree holds 2^18 = 262,144 signing positions, and the on-chain contracts cap real usage far below that, at 65,536 per slot key per chain, deliberately, to keep a conservative margin on the birthday-style bounds. That is decades of use for a hardware wallet, and when a slot key is spent you rotate to a new one through the bootstrap key, at the same wallet address, without touching your 24 words.

A budget of 65,536 with automatic rotation is a system. “Never reuse an address” is a New Year’s resolution.

Myth 4. Any offline or air-gapped signing device is automatically quantum-proof because it is not connected to the internet.

Myth 15. Air-gapping alone is sufficient protection against a quantum attack on elliptic-curve signatures.

These are the same claim and it contains a category error worth naming clearly.

An air gap defends against exfiltration: malware cannot copy a key off a device that has no network path. That is a real and valuable property, and every hardware wallet, PQ1 included, is built around it.

A quantum attack does not need to exfiltrate anything. Your public key is already on a public blockchain, put there by you, on purpose, the first time you spent. The adversary downloads it like everyone else and does the mathematics on their own hardware. There is no packet to block, no cable to unplug and no perimeter to defend. The attack surface is Etherscan.

An air-gapped ECDSA wallet is an extremely well-protected copy of a key that a quantum computer no longer needs to steal.

Part 3: “you need a hard fork first”

Myth 3. Changing wallets cannot help. The blockchain protocol itself must upgrade to quantum-resistant cryptography first.

Myth 9. It is impossible to have quantum-resistant signatures on Ethereum today without a hard fork.

Myth 24. Quantum resistance is purely a software and protocol problem. Hardware changes are irrelevant.

This is the most confident wrong claim in the thread, and it is wrong for a specific, checkable reason: Ethereum already shipped the upgrade, in 2023, and called it account abstraction.

Under ERC-4337, an account is a smart contract, and the contract decides what a valid signature is. The EntryPoint calls validateUserOp on your account, your account looks at the bytes, and your account decides. Nothing in the protocol says that decision has to be secp256k1. That is the entire point of the standard, and it is why Vitalik named smart accounts as the practical migration path in the February 2026 quantum-resistance roadmap rather than proposing to fork the curve.

So PQ1’s account contract dispatches to SPHINCsC10Asm.sol, a stateless Yul verifier that walks a real SPHINCS+C10 signature using the EVM’s SHA-256 precompile. No fork, no new opcode, no consensus change, no permission from anybody.

This is not a whiteboard argument. The contracts are deployed on Base mainnet, at block 47241971 onwards, since 12 June 2026:

SPHINCsC10Asm  (verifier)  0xdDE4D290d646097ECeEA1e33Bf8C9Fa6dd589cbB
PQSmartWallet  (impl)      0x31e49D24370bFa487dF1D6687A1aca5a34183590
PQSmartWalletFactory       0xe8CE78CD976497447FF8B76c71b59aE42Af0d452
EntryPoint v0.6            0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789

An earlier deployment on Base Sepolia was driven end to end with genuine 4,008-byte signatures produced by the firmware’s own signing crate: account creation with a factory signature verified on chain, a UserOp signed by a slot key, and a bootstrap-key rotation installing a new slot. Then eighteen adversarial simulations were run against it, forged factory signatures, cross-chain replays, direct calls to validateUserOp, owner-minting through self-calls, and all eighteen were rejected with the specific error each defence is supposed to raise.

Here is the number people actually want. From test/PQSmartWalletRealSig.t.sol in the repo, run today against the real verifier with a real signature:

validateUserOp gas (real C10 sig, slot path):  229,399
c10Verifier.verify gas (isolated):             179,189

Post-quantum signature verification on the EVM costs about as much as a moderately complex DeFi interaction. Run the test yourself, it takes seventeen milliseconds.

On the hardware half of Myth 24: the software is what makes it quantum-resistant, correct. Hardware is what makes the quantum-resistant key survive everything that is not a quantum computer. A SPHINCS+ key on a laptop is a SPHINCS+ key one browser exploit away from being someone else’s. Hardware is also what makes it fast enough: C10 signing takes around 1.1 seconds on a cached slot only because the SHA-256 work is routed through the STM32U585’s hash peripheral. And hardware is what puts a screen you own between you and the transaction. None of that is quantum resistance. All of it is the difference between an algorithm and a wallet.

Myth 11. Using ERC-4337 smart accounts does not provide real quantum resistance.

Correct as stated, and this is the sharpest objection in the whole list.

ERC-4337 is a container, not a guarantee. The overwhelming majority of smart accounts deployed today validate secp256k1 signatures, or P-256 through WebAuthn and passkeys, and both of those are elliptic-curve schemes that Shor destroys just as thoroughly as an EOA. Being a 4337 account buys you exactly nothing quantum-wise. Anyone selling “smart account, therefore quantum-safe” is selling you a shipping container and calling it cargo.

What matters is what the validation function checks, and there are only two states worth having:

The PQ1 account has a single immutable c10Verifier wired to every dispatch path: Type 1 bootstrap signatures, Type 2 slot signatures, and EIP-1271 off-chain signatures all go to the same SPHINCS+ verifier. There is no secp256k1 code path in the contract, none in the firmware, and none in the bootloader. This is invariant #5 in the repo, it is enforced by a CI gate called make classical-crypto-boundary, and the reasoning is in the contract README: a wallet that accepts both ECDSA and a post-quantum scheme is exactly as secure as the weaker of the two. On the day Shor runs, every “hybrid” fallback path on chain becomes a free-money faucet. There is no upgrade-later story that works, because a signature valid under the old rules stays valid.

So: yes to the objection, and it is the reason the design has no fallback to be smug about.

Myth 10. SPHINCS+ cannot protect assets that are already on chain.

Half correct, and the half that is correct deserves stating plainly: no signature scheme retroactively protects assets sitting in an account whose spend rule is ECDSA. Not SPHINCS+, not lattices, not a fork. The account’s rule is the account’s rule.

The half that is wrong is the implied conclusion, that nothing can be done. What protects those assets is a transaction. You move them into an account whose spend rule is post-quantum. That transaction costs ordinary gas, works today, needs nobody’s approval, and after it confirms, the coins that were vulnerable are not. That is what migration is. It has always been what migration is.

Myth 20. Migration of already-exposed keys is impossible or completely unaddressed.

The first word is right and it matters more than anything else in this post. An exposed public key cannot be un-exposed. It is on a public, immutable ledger. There is no product, from us or anyone, that makes an old key safe again.

What exists is a window, and the window has a closing date nobody has published. Mosca’s inequality is the standard framing: if the time your assets must stay secure (X) plus the time your migration takes (Y) exceeds the time until a cryptographically relevant quantum computer arrives (Z), you are already late. For a self-custodied hardware wallet, X is measured in decades and Y is measured in however long it takes millions of people to individually move their funds.

The asymmetry is brutal and it is why we shipped now rather than later. Migrate early and you pay a gas fee. Migrate during an emergency and you are competing for blockspace with everyone else who waited, while a machine that can derive private keys from mempool transactions is already running.

One trap to name, because it is currently a popular non-answer: EIP-7702 does not fix this. Delegating an EOA to contract code makes it behave like a smart account, but the underlying secp256k1 key retains protocol-level authority and can sign a fresh authorization at any time. A quantum adversary who breaks that key owns the account regardless of what code it points at. Our own wallet risk checker classifies a 7702-delegated EOA as quantum-vulnerable for exactly this reason, and if that irritates people, it should irritate them at the EIP, not at the classifier.

Part 4: hardware and algorithm choices

Myth 7. Hardware wallets are inherently a security flaw for post-quantum use. Only software wallets can be truly quantum-safe.

There is no mechanism by which this could be true. A signature scheme’s security does not depend on the physical location of the key. What changes with location is everything else: whether the key ever touched a machine with a browser on it, whether you can see what you are signing, whether a wrong PIN is enforced by silicon or by a variable.

We think the real complaint underneath this one is legitimate, though: hardware wallets ask you to trust an opaque binary from a vendor. So PQ1 removes that ask. The firmware is GPLv3. The builds are reproducible, so the same git SHA produces a byte-identical image. At boot the device measures its own secure-world image and renders the hash as eight BIP-39 words on the screen, which you compare against the words the fwmeasure tool prints from a build you did yourself. And DIY.md in the repo lists the $150 bill of materials, with Mouser links, for building the entire wallet on four off-the-shelf boards, no custom PCB and no factory.

If you would rather not buy anything, make play boots the whole wallet in QEMU. That is a harder claim to make than “trust our software wallet,” not an easier one.

Myth 8. Trezor, Ledger, Tangem and friends are already quantum-ready or safer.

They are excellent devices and they sign with elliptic curves. secp256k1 for Ethereum and Bitcoin, ed25519 elsewhere. Both are Shor-breakable, completely, and no amount of secure-element quality changes that, because a secure element protects a key from extraction, which is not the attack. The attack derives your key from data you already published.

Several vendors have credible post-quantum roadmaps and we take them seriously, but a roadmap is not a device. Ask a very specific question of anything marketed as quantum-ready: what signature algorithm does this device produce, and what verifies it on chain? If the answer is ECDSA, everything else is a separate conversation.

Myth 21. Hash-based signatures like SPHINCS+ are weaker or less practical than lattice-based alternatives.

Weaker is backwards. Less practical is a fair trade we made on purpose.

On security, hash-based signatures have the most conservative assumption in post-quantum cryptography. Forging a SPHINCS+ signature reduces to breaking SHA-256, a function under continuous public cryptanalysis for over two decades and deployed in essentially every security system on earth. Lattice schemes rest on Learning With Errors, a beautiful and much younger assumption whose cryptanalytic track record is thinner. That is not a prediction that lattices will break. It is a statement about which assumption you want under money that has to survive thirty years, and the repo says it in one line: no lattice assumption appears anywhere in the shipping trust path.

On practicality, the trade is size. Falcon-512 signatures run around 666 bytes and ML-DSA-44 around 2,400, against C10’s 4,008. That is a real cost and it is why C10 exists at all: it is a compressed SPHINCS+ variant, using WOTS+C and FORS+C from peer-reviewed work co-authored by a SPHINCS+ designer, which shrinks the signature enough to verify affordably on chain without changing the security assumption. The full analysis of what C10 does and does not trade away is its own post.

There is also an implementation argument that matters on a microcontroller. Falcon needs Gaussian sampling and floating-point arithmetic, which are notoriously difficult to implement in constant time on embedded hardware. SPHINCS+ needs a hash function. On a device whose threat model includes someone with an oscilloscope, that simplicity is a security property, not an aesthetic preference.

Myth 17. The device looks like a simple USB stick, so it cannot contain serious post-quantum cryptography.

Inside 58 × 30 × 7 mm and 12 grams: an STM32U585 Cortex-M33 with TrustZone and a hardware SHA-256 engine, plus two secure elements from two different vendors, the Infineon OPTIGA Trust M V3 and the NXP SE050, each certified CC EAL6+ with AVA_VAN.5. The seed is XOR-split across them, PIN attempts are charged against three independent counters, and every transaction is decoded and rendered inside the secure world before you can confirm it with a physical button.

Post-quantum cryptography is not physically large. SPHINCS+ is a few thousand invocations of SHA-256 arranged in a tree. What it needs is a hash accelerator and careful memory handling, both of which fit comfortably in a part you can buy for a few dollars. The whole thing runs on the four dev boards in DIY.md, which is the most direct possible refutation: the size of the box is not the argument, and you can verify that with $150 and an afternoon.

Part 5: timing

Myth 18. Preparing now is pointless or premature, because large-scale quantum computers do not exist yet.

Three reasons this is wrong, in increasing order of how much they should worry you.

Hardware wallets are durable goods. The device you buy this year is in your drawer in five to ten years. The architecture shipped today determines how much value is exposed on the day it matters. You do not get to make this decision later on the hardware you already own.

Migration is not an event, it is a logistics problem. Every wallet, hot, cold, hardware, software, multisig and custodial, needs to individually move. That is millions of independent decisions by people who are not reading this. Coordinating that takes years, and the years have to happen before Q-Day, not during.

Exposure is retroactive. This is the one people miss. Your public key was published the first time you spent, and it stays published forever. An adversary does not need a quantum computer today to attack you today. They need one eventually to attack what you published years ago. The industry name for this is Harvest Now, Decrypt Later, and it means the clock started when you made your first transaction, not when the first quantum computer boots.

Then there is Google committing publicly to post-quantum migration on a near-term timeline. Organisations with that budget do not migrate cryptography for fun.

Myth 16. The $1.2 trillion figure is pure hype and the wallet cannot meaningfully protect existing assets.

Two claims. We will concede the first and contest the second.

On the number: any headline figure for “quantum-vulnerable crypto value” is a modelling exercise, and it moves with the price, with which chains you count, and above all with where you draw the line between exposed and unexposed public keys. Reasonable people produce very different totals. We would rather you not take our number or anyone else’s, so the site has a wallet risk checker where you can enter your own address and see how it classifies, along with what the classification is based on. Check one address you care about. The aggregate is an argument. Your own address is a fact.

On the second claim, see Myths 10 and 20. A post-quantum wallet cannot protect assets that stay where they are. It gives them somewhere to go.

Part 6: about us

Myth 12. It is vaporware. Units have not shipped and the audits are incomplete.

Both facts are true, and we published them ourselves before anyone said them to us.

No devices have shipped. No on-chain wallet holds funds. A Trail of Bits security audit is currently under way and has not been finalized, and the reviews under docs/audits/ are our own, not independent. Ship-blocking work is still open, including irreversible secure-element provisioning steps, tracked publicly in docs/STATUS.md with an evidence pointer per row. The repo’s own README carries a section titled “Early access, work in progress” that opens with the sentence “PQ1 is unfinished, not yet audited, and not ready to hold value.”

We open-sourced it early, while it is being built, instead of presenting it as finished afterwards. The predictable consequence is that people can read exactly how unfinished it is and say so on the internet. We prefer that to the alternative, which is a device you cannot inspect and a security claim you have to take on faith.

What is not vapor: firmware that boots on real silicon and in QEMU, contracts live on Base mainnet, signatures verified on chain, a machine-checked Lean 4 proof track over the on-chain verifier and the wallet’s theft-freedom theorems with a published axiom list, Kani proofs over the transaction decoders, and the batch walker differentially tested against real deployed bytecode executed in revm. You can run all of it.

Myth 13. “First quantum-proof hardware wallet” is false, because people built Falcon and SPHINCS prototypes at hackathons years ago.

The prior art is real and we credit it by name in our own README, unprompted. The Yul verifier PQ1 deploys is derived from SPHINCs-C10Sha256Asm.sol by Nicolas Consigny at the Ethereum Foundation, and the C10 parameter set itself originated in that work, from his Fluhrer-Dang security sweep. The Python reference signer our Rust crate was written against comes from the same source. Our contributions on top are narrower and we list them: the SHA-256 firmware-parity constraints, N-mask key-shape enforcement in the verifier, binding the FORS forest to the hypertree leaf position, and the per-chain use caps. The tamper-detection driver is a GPLv3 port from Trezor. The account shape is compatible with Coinbase Smart Wallet’s.

None of that is diminished by us building a consumer device around it, which is a different piece of work: dual secure elements, a trusted display, silicon PIN gating, reproducible builds, an on-device transaction decoder, and a supply chain. A verifier in a hackathon repo and a wallet you can hand to someone are not the same artifact.

And to be exact about the word: nothing has shipped yet. If you want to hold us to “first,” hold us to it on the day a unit arrives, and hold the claim to what it says, which is a consumer hardware wallet, not a proof of concept.

Myth 19. Backing by Vitalik and Balaji does not make the claims legitimate.

Completely correct, and we agree with the principle so strongly that it is the design brief for the whole product.

Balaji Srinivasan and Vitalik Buterin are investors in Freedom Factory. Investment is a bet on a company, not a cryptographic review, and nobody should treat it as one. An investor’s name on a landing page is precisely the kind of trust signal we built PQ1 to make unnecessary.

Read the firmware. Reproduce the build. Compare the eight words on the screen. Check the deployed bytecode against the audited pin. Run the gas test. If any of it fails, that is worth more than any endorsement, and we would like to hear about it.

Myth 1. The whole announcement is rubbish, a deliberate lie, and probably a scam.

There is a specific test for this one that does not require trusting us at all.

A scam needs you to buy something. PQ1’s firmware is GPLv3, its contracts are MIT, its builds are reproducible, its bill of materials is public with vendor links, and its assembly instructions are in the repo. You can build the entire wallet, post-quantum signer, dual secure elements, trusted display, PIN gating, for about $150 in parts, from our repo, and never send us a dollar. Or you can spend nothing and boot it in QEMU.

That is a strange thing for a scam to do.

What we are not claiming

The list would not be honest without this section.

• PQ1 cannot save an exposed key. Nothing can. It gives your assets a destination, not a rescue.
• Nothing has shipped and the external audit is not finished. Treat every security claim in this post as unconfirmed until Trail of Bits lands, and read docs/STATUS.md rather than our marketing.
• We do not defend against coercion, against an adversary with sustained physical access to a powered, unlocked device, or against a fundamental break of SHA-256. That last one is a civilization-scale event and our answer is a firmware update to a SHA-3 based scheme, which we say out loud rather than pretending it cannot happen.
• Clear-signing is not total. Genuinely unknown calls still produce a loud blind-sign page. We refuse to pretend otherwise.
• Values described as frozen can still change before first shipment. The parameter set, the domain tags, the CREATE2 salt. After the first device ships, changing any of them is a user-visible fork, which is exactly why they are being argued over now.

Some of the twenty-five replies were right. Myth 11 is right, and it is why there is no ECDSA fallback. Myth 20 is right about exposed keys, and it is why the timing matters. Myth 19 is right about endorsements, and it is why everything is published. Myth 12 is right about the audit, and we said it first.

The rest were confident.

Every line of this is in a public repository. You do not have to take our word for any of it.

They ask you to trust. We let you verify.

PQ1™.