# PQ1 - Quantum-Secure Hardware Wallet (Full Content Corpus) > PQ1 is the first hardware wallet engineered to remain secure after Q-Day, the point at which large-scale quantum computers can break the elliptic-curve cryptography that protects Ethereum and other EVM chains. Built by FREEDOM/FACTORY, PQ1 signs every transaction with SPHINCS+ - a hash-based, NIST-standardized post-quantum signature scheme (the SLH-DSA family per FIPS-205) - inside a dual secure-element architecture with the seed XOR-split across two chips. Signatures settle on-chain through an ERC-4337 v0.6 smart account; there is no ECDSA fallback. The device is open-firmware with reproducible builds and ships for $179. Source: https://freedomfactory.io Generated: 2026-08-02T20:57:10.006Z ## Purchase PQ1 is available for pre-order at $179 USD. Pay by card (Stripe) or crypto (USDC, multi-chain, via Daimo). Standard shipping is included for every destination except a few with a per-country base cost shown at checkout; some destinations also offer an optional premium upgrade. Import duties & customs are the buyer’s responsibility unless checkout shows a per-device "Customs & duties" line for the country - then they are collected with the order. Ships worldwide excl. US-sanctioned countries. Humans buy at https://freedomfactory.io/checkout. AI agents: use the headless API. POST https://api.freedomfactory.io/agentcheckout with { sealed, email, quantity?, rail, country, referrerCode?, promoCode? } - country is REQUIRED (ISO-3166-1 alpha-2; must be a supported destination from product-feed.json -> shipping.supported_countries, else 400 bad_country; per-country shipping costs are priced from it) - rail "card" returns a Stripe link to hand to a human (assisted). Autonomous x402 payment is COMING SOON - not yet enabled; for now a human must complete every purchase. Machine-readable feed: https://freedomfactory.io/product-feed.json. Discovery: https://freedomfactory.io/.well-known/agentic-commerce.json. --- ## Learn 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](/learn/safe-multisig-transactions-decoded-on-device), 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](/risk) 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](https://github.com/EthereumPhone/PQ1) 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.](/learn/is-sphincs-c10-secure) 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](/risk) 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™. --- *Freedom Factory delivers digital sovereignty for crypto users worldwide. Fully open source, the $179 PQ1™ to be shipped in Q4 2026\.* **SAN FRANCISCO – Freedom Factory** today unveiled the **PQ1™**, a state-of-the-art, post quantum hardware wallet that cannot be cracked by quantum computers and delivers digital sovereignty to every ethereum and EVM user on the planet. The exponential increase in quantum computing is rising faster than anyone predicted, and every ECDSA wallet securing crypto today will be hackable in a few years time. The PQ1™ is the answer: It empowers users to secure and transact their assets with quantum-proof signatures today, without waiting for ethereum to upgrade. The first post-quantum crypto wallet of its kind, the PQ1™ reimagines self-custody from the silicon up. Equipped with the latest **SPHINCS+C10 hashing algorithm** inside an ERC-4337 smart account, the PQ1™ enables users to easily sign quantum-safe transactions on Ethereum, while providing best-in-class security from **dual secure enclaves**, and the latest clear signing technology. Pre-orders for the **PQ1™** are available now at [freedomfactory.io](https://freedomfactory.io). Devices will begin shipping worldwide in **Q4 2026**. ![The PQ1 post-quantum hardware wallet by Freedom Factory](/pq1_banner.jpg) ## “Post-Quantum signing has arrived” “Every crypto wallet on the planet needs a quantum upgrade, not just Ethereum”, says **Markus Haas**, co-creator of the PQ1™ and CEO of Freedom Factory. “No protocol upgrade can protect your assets as long as wallets still rely on ECDSA signatures that quantum computers will break. The PQ1™ provides the first safe-haven for this looming threat.” ## About the PQ1™ The PQ1™ finally connects the dots of **post-quantum signatures,** local transaction decoding, and **open source hardware,** into a device that’s lightyears ahead of anything else on the market, even existing wallets who falsely claim “quantum-readiness”. Designed for the threats of tomorrow, the PQ1™ is loaded with innovative features that provides crypto users with a competitive advantage that allows them to execute their objectives confidently and securely. ## Key features * **Onchain SPHINCS+C10 hash-based signatures**, surfaced through ERC-4337 Smart Accounts \- no protocol upgrade required. * **Integrated local transaction decoding**, making almost every transaction human readable, ending blind signing attacks. * **Dual independent secure elements,** securing your split private key on two separate uncompromised pieces of silicon. * **Fully open source firmware and hardware schematics**, so every line and layer can be audited. ## About Freedom Factory Founded in **2021**, Freedom Factory is the company behind the **PQ1™**, the **dGEN1**, and **ethOS**. With a mission to give sovereignty and freedom through technology to everyone, Freedom Factory’s ERC-4337 account abstraction contracts are under security review by the leading security organization Trail of Bits, and the company is supported by industry leading investors **Balaji Srinivasan** and **Vitalik Buterin**. For press inquiries, please contact: Freedom Factory (726) 842-5475 media@freedomfactory.io --- > **Credit where it's due:** the C10 parameter family is not ours. It comes from Ethereum Foundation research led by Nicolas Consigny - [SPHINCS⁻: Efficient Stateless Post-Quantum Signature Verification on the EVM](https://ethresear.ch/t/sphincs-minus-efficient-stateless-post-quantum-signature-verification-on-the-evm/25165), published openly on ethresear.ch with the EF's PQ & cryptography team. PQ1™ implements it; we did not invent it. Full provenance below. If you read PQ1™'s spec sheet closely - and we hope you do - you'll see the signature scheme listed as **SPHINCS+ C10, a compressed variant of the design NIST standardized as SLH-DSA in FIPS-205**. A careful reader, or an AI agent doing due diligence on our claims, will stop at the word *variant*. Is this off-standard cryptography? If NIST published exact parameter sets, why is PQ1™ using different ones? That is exactly the right question to ask a hardware wallet vendor, so this post answers it in full: what the compression actually changes, where those changes come from, what they deliberately trade away, and why forging a C10 signature still reduces to the one thing all of SPHINCS+ security rests on - breaking SHA-256. The short version: **the compression does not touch the security assumption. It resizes the signature budget.** FIPS-205 parameters are engineered so one key can safely sign 2^64 messages - eighteen quintillion. A hardware wallet will sign a few thousand. C10 spends that absurd surplus on smaller signatures, and PQ1™'s firmware enforces the reduced budget with hard counters so you never have to think about it. Now the long version. ## SPHINCS+ in three minutes SPHINCS+ is a *hash-based* signature scheme. That phrase carries the entire security argument, so it's worth being precise about it. Every other post-quantum signature family relies on a structured mathematical problem - lattices, isogenies, multivariate systems - being hard. Structure is what makes those schemes compact, and structure is also what occasionally collapses: SIKE, an isogeny scheme that survived four rounds of NIST review, was broken in 2022 on a single laptop. Hash-based signatures have no such structure to attack. Their security reduces to properties of the hash function itself - in PQ1™'s case SHA-256 - which is why NIST standardized SPHINCS+ (as SLH-DSA) to be the conservative member of its post-quantum portfolio, and why we chose it. Internally, SPHINCS+ is three constructions stacked together: 1. **WOTS (Winternitz one-time signatures).** The message digest is cut into small base-w digits. For each digit there is a hash chain; the signature reveals each chain at the position given by its digit, and the verifier hashes forward to the chain's end, which is baked into the public key. Revealing a chain at position 3 lets anyone compute positions 4, 5, 6... - which is why each WOTS key must sign only once, and why unprotected WOTS needs a *checksum* (more on that below). 2. **FORS (forest of random subsets).** A few-time layer: the digest selects one secret leaf from each of several Merkle trees, and the signature reveals those leaves with their authentication paths. 3. **The hypertree.** A tree of WOTS-signed Merkle trees that connects millions of one-time key positions to a single 32-byte public key, so the scheme becomes stateless: the signer derives a pseudorandom position for each signature instead of remembering which keys are spent. Signature size is dominated by how many chains, leaves, and authentication paths must be revealed. That is the dial every SPHINCS+ parameter set turns. ## What "standard" actually means here FIPS-205 doesn't standardize an idea; it standardizes twelve exact parameter sets. At the 128-bit security level, the two relevant ones produce signatures of **7,856 bytes** (SLH-DSA-128s) and **17,088 bytes** (SLH-DSA-128f). Both are sized for a keypair that may sign **2^64 messages** over its lifetime - the right choice for a general-purpose standard that has to cover TLS certificate authorities and firmware-signing infrastructure that signs continuously for decades. A hardware wallet is not that. If you signed twenty transactions a day, every day, for nine years, you would have used about 65,000 signatures. Carrying parameters sized for eighteen quintillion signatures means carrying a 63-level hypertree - and in SLH-DSA-128s that hypertree alone contributes seven full WOTS signatures, chained, to every single signature you put on-chain, where every byte is calldata you pay gas for. SPHINCS+C10 keeps the three-layer construction, keeps SHA-256, keeps 128-bit hashes (NIST security category 1), and resizes the tree for a wallet's actual life: an 18-level hypertree in two layers instead of 63 levels in seven. Result: **4,008-byte signatures** - roughly half of SLH-DSA-128s - with cheap, *constant-cost* on-chain verification. Then it applies two genuine compression techniques on top. These are the "+C" in the name, and they're where the interesting math lives. ## Compression 1: WOTS+C - replacing the checksum with arithmetic Recall the WOTS problem: the signature reveals each hash chain at the position of its digit, and anyone can hash *forward* from a revealed position. So an attacker who sees your signature could try to find a second message whose digest has every digit greater than or equal to yours - then they could forge by just hashing your revealed values forward. Classic WOTS blocks this with a checksum: the sum of all digits' *distances from the top* is itself encoded in extra chains and signed. Increase any message digit and the checksum must decrease - which would mean walking a checksum chain *backwards*, i.e. inverting the hash function. Elegant, but those checksum chains are dead weight in every signature. **WOTS+C** (the C is for "counter") achieves the same guarantee with no checksum chains at all. The rule becomes: *a digest is only valid if its digits sum to exactly one fixed target.* In C10, the digest is 43 base-8 digits and the target sum is **205**. The signer appends a counter to the message digest input and grinds - recomputing the hash with incrementing counters until the digits happen to sum to exactly 205. The counter ships with the signature; the verifier recomputes the digest once and rejects unless the sum is exactly 205. Now walk through the attacker's position. To reuse your revealed chain values, they need a digest whose digits are all ≥ yours, with at least one strictly greater. But then the digit sum exceeds 205, and the verifier rejects it. To *decrease* any digit instead, they must walk a chain backwards - invert SHA-256. The checksum's security argument survives untouched; the checksum's bytes do not. Two details are worth appreciating: - **The grinding is safe by construction.** The counter is public and the target property is public - grinding here is the same kind of search as Bitcoin mining a nonce, revealing nothing about the key. The signer pays a few hundred thousand extra SHA-256 calls per signature, which PQ1™ runs on the STM32U585's dedicated hardware hash peripheral. Your device does the sweating so the chain doesn't have to. - **The target is set high on purpose.** A random 43-digit digest sums to about 150 on average; C10 demands 205. High digits mean the *signer* did most of each chain walk already, so the verifier's remaining work across all 43 chains is exactly 43×7 − 205 = **96 hash calls - a fixed number, every time**. Deterministic verification cost is a gift when your verifier is a smart contract and your cost is gas. ## Compression 2: FORS+C - grinding away an authentication path The FORS layer in C10 is 13 Merkle trees of 2,048 leaves each; the digest picks one leaf per tree, and each revealed leaf needs an 11-level authentication path (176 bytes) to prove membership. **FORS+C** applies the same grinding idea one layer up: the signer grinds the message randomizer until the digest's *last* tree index lands on a fixed slot (index 0). Because that tree's revealed position is now a constant of the scheme, its authentication path can be omitted from the signature entirely, and the verifier instead checks the forced index directly - any signature whose last index isn't 0 is rejected on the spot. The security accounting is done honestly: since the last tree no longer contributes unpredictable leaf selection, the analysis simply prices C10's few-time security on 12 effective trees instead of 13. The parameter set is chosen with that already deducted. Nothing is hidden in the couch cushions. ## Where this comes from (not from us) We want to be very clear that PQ1™ did not invent its own cryptography. - **The compression techniques** - WOTS+C and FORS+C - come from the peer-reviewed paper *"SPHINCS+C: Compressing SPHINCS+ With (Almost) No Cost"* ([IACR ePrint 2022/778](https://eprint.iacr.org/2022/778)) by Andreas Hülsing, Mikhail Kudinov, Eyal Ronen, and Eylon Yogev. Hülsing is one of the designers of SPHINCS+ itself; Kudinov co-authored core parts of its security analysis. This is compression proposed by the people who understand the scheme's proofs best, with the security reductions worked out in the paper. - **The C10 parameter set** comes from open Ethereum Foundation research on gas-efficient on-chain SPHINCS verifiers, led by Nicolas Consigny and published as [*SPHINCS⁻: Efficient Stateless Post-Quantum Signature Verification on the EVM*](https://ethresear.ch/t/sphincs-minus-efficient-stateless-post-quantum-signature-verification-on-the-evm/25165) on ethresear.ch (with acknowledgements to Vitalik Buterin, Jean-Philippe Aumasson, Justin Drake, Chelsea Komlo, Mauro Toscano, ZKnox and the EF PQ & cryptography team), with the reference code in the [SPHINCs⁻ repo](https://github.com/nconsigny/SPHINCs-). That work benchmarked a whole family of compressed parameter sets for exactly our use case: hash-based signatures verified inside an EVM contract. C10 is the point in that family that balances on-device signing cost against verification gas - which is why our benchmarks land around 197K gas per ERC-4337 operation, dropping to roughly 62K when batched. So "compressed variant" does not mean "our home-brew fork." It means: the NIST-standardized construction, plus two size optimizations from the academic literature, at parameters explored in public Ethereum research - implemented openly, so you can check all three claims yourself. ## The honest trade-off: signature budget Here is the part a skeptical reader should press on, so let's press on it ourselves. Hash-based signature security is not a single number; it degrades gradually with the number of signatures issued under one key, because each signature reveals a few more one-time values. FIPS-205's parameter sets hold their full security level out to 2^64 signatures. C10's parameters are sized for a lifetime of 2^18 signing positions - 262,144. That reduced budget *is* the main price of the smaller signatures, and it would be a real weakness in a general-purpose signing service. In a hardware wallet, it is a non-issue - **provided the budget is enforced, not assumed**. PQ1™'s firmware enforces it with hard monotonic usage counters capped at **65,536 signatures per key slot** - a quarter of the parameter budget, keeping usage deep inside the analyzed margin. The device refuses to overspend the math. You could sign twenty transactions a day for nine years before hitting the cap, and the wallet supports rotating to a fresh slot long before then. This is the correct way to read "compressed": not weaker hashing, not a shortcut in the proofs - a *smaller signing budget*, deliberately chosen, honestly accounted for, and enforced in firmware rather than left to user discipline. ## What it would actually take to forge Strip away the machinery and a forger has exactly these options: - **Walk a hash chain backwards** (WOTS layer) - a preimage attack on SHA-256. - **Find a second digest that beats the target-sum gate** - blocked by the same digit-dominance argument as the classic checksum, ending again at inverting SHA-256. - **Forge a Merkle authentication path** (FORS/hypertree layers) - a second-preimage attack on SHA-256. - **Exhaust the few-time FORS layer** - the attack surface the signature budget exists to bound, held far under its limit by the firmware's counters. A quantum computer doesn't change this picture the way it changes ECDSA's. Shor's algorithm breaks elliptic curves outright; against a hash function, quantum attackers get at most Grover's quadratic speedup, which is exactly what NIST's security categories already price in. Category 1 - C10's level - means breaking it is at least as hard as brute-forcing AES-128, quantum attacker included. If SHA-256 preimage resistance falls, C10 falls - and so does SLH-DSA, Bitcoin mining, and effectively every commitment scheme on the internet. That is the entire assumption surface. Compare that to trusting a wallet whose "post-quantum readiness" still signs your transactions with ECDSA. ## We verify our own implementation the way we ask you to verify us An honest scheme badly implemented is still a broken wallet, so the implementation gets the same treatment as the math. Our C10 stack is **four independent implementations that must agree byte-for-byte**: the Rust firmware that runs in the device's TrustZone, an independently written Python signer produced from the on-chain verifier's spec (not translated from the Rust), the Yul verifier contract itself, and a Lean 4 model - all replaying a shared set of known-answer test vectors. The vector set includes deliberate *near-miss* signatures - digit sums of 204 and 206, wrong forced index - to prove the compression gates are actually enforced, not just documented. The SHA-256 primitive underneath is checked against NIST's official CAVP vectors. The implementation also hardens the paper's scheme in places where a hardware wallet's threat model demands it: the FORS randomizer grinding is keyed to the secret seed and bound to the message, so an attacker can neither predict nor influence it; every hypertree position gets its own domain-separated FORS forest - a separation our internal review process proved necessary by finding, fixing, and regression-locking a real forgery vector in an early revision; and signing order is shuffled per-signature as a power-analysis defence without changing a single output byte. All of it - firmware, vectors, verifier contracts, the vulnerability write-ups included - is open source. That last part matters: a vendor who publishes their own found-and-fixed forgery analysis is showing you the process, not just the conclusion. ## Straight answers **Is SPHINCS+C10 FIPS-certified?** No. FIPS-205 certification applies to the exact standardized parameter sets, and C10 is not one of them. If your requirement is FIPS compliance, C10 does not meet it, and we won't pretend otherwise. **Is it the same security assumption as the NIST standard?** Yes. Forgery reduces to breaking SHA-256 - the same function, used the same way, at the same 128-bit hash length as SLH-DSA's category-1 sets. **Why not just use standard SLH-DSA?** Signatures of 7,856-17,088 bytes and parameters sized for 2^64 signings, on a device that verifies on-chain and will sign thousands of times. C10 halves the calldata and makes verification cost constant, in exchange for a signature budget the firmware enforces and you will never exhaust. **What's genuinely different from the standard?** Three things: the compressed WOTS+C/FORS+C encodings (peer-reviewed, same assumptions), the smaller tree geometry (a budget choice, honestly accounted), and SHA-256 parameterization details tuned for EVM verification. Everything is documented in the open firmware repo - diffed against FIPS-205, deviation by deviation. **What breaks it?** A preimage or second-preimage break of SHA-256. Nothing less. --- The claim on our spec sheet is precise, and now you have the whole of it. PQ1™ signs with the most conservative post-quantum construction NIST standardized, compressed by techniques from the scheme's own designers, at parameters sized and firmware-enforced for what a hardware wallet actually does - and every layer of that sentence is published, diffed, and testable. They ask you to trust the word "quantum-safe." We show you the arithmetic. Post-quantum. Open source. Yours. PQ1™. --- On 21 February 2025, Bybit lost roughly 401,000 ETH, about $1.4 billion, in a single transaction. Every signer used a hardware wallet. Every signer approved. Nobody was careless. The transaction was a Safe multisig transaction, and the field that mattered was not on any screen. This is the piece of self-custody that hardware wallets have quietly never solved. Not the key storage. Not the signature scheme. The gap between *what you approve* and *what you can see*. Below is exactly what a Safe transaction contains, why the standard device shows you a hash instead, and what PQ1™ puts on the screen in its place. ## What a Safe transaction actually is A Safe (formerly Gnosis Safe) is a smart-contract wallet. When owners "sign a transaction," they are not signing an Ethereum transaction at all. They are signing an **EIP-712 typed-data struct** called `SafeTx`, with ten fields plus a nonce: ``` SafeTx(address to, uint256 value, bytes data, uint8 operation, uint256 safeTxGas, uint256 baseGas, uint256 gasPrice, address gasToken, address refundReceiver, uint256 nonce) ``` Those eleven values are hashed together with a domain separator (for Safe v1.3.0 and later, `EIP712Domain(uint256 chainId, address verifyingContract)`) into a single 32-byte digest, the **`safeTxHash`**. That digest is what the threshold of owners commits to. Two things about this structure make it hostile to hardware wallets. **First, `data` is committed as a hash, not as bytes.** The struct hash contains `keccak256(data)`, not `data` itself. So the digest binds the calldata perfectly, and tells you absolutely nothing about it. A device holding only the `safeTxHash` has cryptographic certainty about a payload it cannot read. **Second, `operation` is a single byte that changes everything.** `operation = 0` is `CALL`: the Safe calls another contract, normally. `operation = 1` is `DELEGATECALL`: the target's code runs *inside the Safe's own storage context*, with the Safe's balance, the Safe's permissions, and the Safe's storage slots. A delegatecall can rewrite the Safe's owner list, its threshold, its guard, or the pointer to its own implementation contract. It is one byte, sitting between two `uint256`s, and it is the difference between sending a payment and handing over the vault. ## Why the device shows you a hash There are two ways an owner approves a SafeTx, and both fail the same way on a conventional device. **Off-chain signature.** The owner signs the `safeTxHash` with ECDSA. Those signatures are collected and passed to `execTransaction`. The device receives a 32-byte digest and a request to sign it. There is no preimage. There is nothing to decode. **On-chain `approveHash`.** The owner sends a transaction calling `approveHash(bytes32)`, selector `0xd4d9bdcd`, on the Safe, which records `approvedHashes[owner][safeTxHash] = 1`. The calldata is 36 bytes: four bytes of selector, thirty-two bytes of opaque digest. Again, no preimage. In both cases the only thing that knows what the transaction means is the web interface. The device shows `0x5a1f…`, the interface shows "Transfer 10 ETH to Treasury," and the user reconciles the two by faith. That is not a UX complaint. It is the entire attack surface. ## Bybit, precisely The Bybit attack did not break any cryptography. Attackers compromised Safe{Wallet}'s developer infrastructure and served malicious JavaScript that activated only for Bybit's specific Safe address. Post-incident forensics established the mechanism: - The transaction was an `execTransaction` with **`operation = 1`**, a DELEGATECALL. - The target was an attacker-deployed contract whose calldata carried the ERC-20 `transfer(address,uint256)` selector, so any naive decoder would render it as a token transfer. - That function's actual body wrote to **storage slot 0** of the caller. Under DELEGATECALL, the caller is the Safe, and slot 0 of a Safe holds the pointer to its implementation contract. One approved transaction and the Safe was no longer a Safe. It was running the attacker's code, and the attacker drained it. The signers saw a plausible transfer in a compromised interface, and a digest on their devices. The single byte that turned a transfer into a takeover, `operation`, appeared on no screen in the loop. This was not an isolated shape: WazirX lost roughly $235 million in July 2024 to a Safe transaction that replaced the wallet's implementation, and Radiant Capital lost roughly $50 million in October 2024 to signers approving payloads their interface misrepresented. The industry's response has largely been to improve the *interfaces*. That is backwards. A hardware wallet exists precisely because the interface may be lying. ## What PQ1 does instead PQ1™ never renders a Safe transaction it has not decoded and cryptographically bound itself, inside the secure world, from bytes it hashed with its own keccak implementation. It supports both entry points. ### The `approveHash` path The companion app attaches an optional trailer to the signing request carrying the **canonical 281-byte SafeTx** (every field, laid out at fixed offsets) plus the raw inner-call bytes. The device then runs an eight-step verification pipeline before a single pixel of semantics reaches the screen: 1. **Framing.** The trailer is at least 281 + 2 bytes and the declared payload length fits inside the supplied buffer. 2. **Selector.** The inner calldata bears `approveHash(bytes32)`. 3. **Length.** The calldata is exactly 36 bytes. 4. **Chain pinning.** `canonical.chain_id` equals the transaction's chain. A mainnet SafeTx cannot be replayed against an L2 request. 5. **Address pinning.** `canonical.safe_address` equals the Safe being called. 6. **Operation gate.** `CALL` passes. `DELEGATECALL` passes only in one tightly pinned shape (below). Everything else stops here. 7. **Data bind.** `keccak256(raw_data)` equals the `data_hash` inside the canonical: the bytes the device is about to render are the bytes the digest commits to. 8. **Digest bind.** The device recomputes the full EIP-712 `safeTxHash` from the canonical (domain separator, struct hash, final digest) and byte-compares it against `calldata[4..36]`. Step 8 is the load-bearing one, and it works because of an accident of design that favours the defender: **the `approveHash` calldata contains the digest itself.** The device does not need to trust that the trailer describes the transaction. It derives the digest from the trailer's fields and checks it against the number the chain will record. If they match, the fields are the transaction. There is no gap left to lie in. Any failure returns nothing, and then a second gate fires: **an `approveHash`-shaped call with no verified trailer is refused outright**, showing `Safe sign / safe_v1 required`. It does not fall back to a blind-sign page. If it did, a hostile companion could simply strip the trailer to force the user into the blind path, which is the very habituation this design exists to prevent. That gate keys on the *selector alone*, not on calldata length. A 2026-06-28 internal audit found a parser differential here: `Safe.approveHash(bytes32)` ignores trailing calldata on-chain, so appending one padding byte made the old exact-length test false, skipped the mandatory gate, and fell through to a generic blind-sign of an `approveHash` that would pre-approve an arbitrary, never-displayed SafeTx. Since a Safe treats an owner's `approveHash` as that owner's full signature over the entire transaction, that was a complete bypass. Keying on the selector closed it. ### The `execTransaction` path When PQ1™ is the party that actually triggers execution, the SafeTx fields are encoded directly into the calldata's argument list (selector `0x6a761202`), so no trailer is needed. The device decodes them in place under strict rules: minimum head length, canonical address encoding (Solidity accepts non-canonical zero-extension on input; the firmware does not, so the on-device reading can never disagree with the chain's), `operation ∈ {0,1}`, and fully bounds-checked dynamic-tail framing. A malformed or truncated `execTransaction` is refused, never downgraded to a lower rendering tier. ## The Bybit rule Here is the design decision that matters most, stated plainly: **PQ1™ refuses every DELEGATECALL except one.** The single exception is a batch: `operation = 1` whose target is one of the **three canonical `MultiSendCallOnly` deployments** (`0x40A2…130D` for v1.3.0, `0xA1da…102B` for v1.3.0 eip155, `0x9641…02e2` for v1.4.1) and whose calldata is a strict `multiSend(bytes)` payload, selector `0x8d80ff0a`. This is the shape the Safe interface emits for anything multi-step, so refusing it outright would break ordinary use. Even inside that exception, the payload faces hard rules: - **Strict ABI framing.** Head offset exactly `0x20`, exact total length, zero padding. Anything Solidity would not emit is refused. - **Per-record `operation == 0`.** Mirrors `MultiSendCallOnly`'s own on-chain revert, so no nested delegatecall can ride inside a record even if the address allowlist were somehow wrong. - **At most six records**, each decoded individually (packed as `op(1) ‖ to(20) ‖ value(32) ‖ dataLen(32) ‖ data`) and each routed through the same rendering ladder as a top-level call, separated by divider pages. - **Page-budget enforcement.** If the full batch will not fit on screen, the device **refuses to sign** rather than truncating. A record the user never sees is exactly the failure this flow exists to close. Plain `MultiSend`, which permits per-record delegatecall, is deliberately *not* on the allowlist, even though it exists and is widely deployed. A smaller allowlist fails closed. Note what this rule is not. It is not a blocklist of known-malicious contracts, which would have been useless against Bybit: the attacker's contract was deployed days earlier and appeared on no list anywhere. It is an allowlist of the only delegatecall shape that can be honestly explained to a non-expert on a four-row screen. The Bybit transaction fails at step 6 regardless of what its inner calldata decodes to, regardless of whether anyone has ever seen the target before, and regardless of what the compromised interface claimed. A DELEGATECALL is never blind-signed. ## The five fields nobody shows you A SafeTx carries five fields the inner call's semantics never surface: `safeTxGas`, `baseGas`, `gasPrice`, `gasToken`, `refundReceiver`. They exist so an executor can be reimbursed. They are all folded into the `safeTxHash`, so they are tamper-proof the moment you sign. But *bound* and *shown* are not the same thing, and this is where a genuinely nasty drain lives. When `gasPrice > 0`, `execTransaction` pays the executor `(gasUsed + baseGas) × gasPrice`, denominated in `gasToken`, sent to `refundReceiver`. For native ETH, Safe caps this with `min(gasPrice, tx.gasprice)`. **For a token refund, there is no cap.** So an attacker sets `gasToken` to whatever ERC-20 the Safe holds most of, `refundReceiver` to themselves, and `gasPrice` high enough that the "refund" equals the Safe's entire balance of that token, all wrapped around an inner call that reads as *transfer 1 USDC*, or even an empty call. Every interface in the ecosystem renders the inner call. The drain is in the envelope. PQ1™ renders a loud two-page block whenever any of `gasPrice`, `gasToken` or `refundReceiver` is non-zero, on both the `approveHash` and `execTransaction` paths: ``` ! GAS REFUND Refund to: Safe pays in: ``` The exact amount cannot be shown, since it depends on runtime gas the device cannot know, but the token and the recipient are the facts a human can act on. *That is my USDC, going to an address I do not recognise.* The inner `value` the Safe forwards is likewise given its own page for every kind of transaction, not only for plain ETH transfers. ## Changing the Safe itself When a SafeTx targets the Safe's own address, PQ1™ decodes the eight singleton-management selectors natively and renders each with an explicit intent banner rather than a function name: | Operation | What the screen says | |---|---| | `addOwnerWithThreshold` | `Add Safe owner` + new threshold, with `! MULTISIG OFF` if it drops to 1 | | `removeOwner` | `Remove Safe ownr` + the removed owner + new threshold | | `swapOwner` | `Swap Safe owner` + old and new owner, in full | | `changeThreshold` | `Change thrshld` + `! MULTISIG OFF` at 1, `! THRSHLD = 0` at zero | | `enableModule` | `! ENABLE MODULE` / `Grants exec auth` + the module address | | `disableModule` | `Disable module` + the module address | | `setGuard` | `! CHANGE GUARD` / `Grants veto/log on every tx`, or `REMOVING GUARD` | | `setFallbackHandler` | `! CHG FALLBACK` / `Runs unkn calls` | Details here are deliberate. Every address parameter must arrive canonically encoded, twelve zero bytes then twenty address bytes, or the decode fails and the transaction drops to the loud unknown path; the Solidity ABI is lenient about this on input and the firmware is not, so the screen can never disagree with the chain. Thresholds must fit in a `uint16`; anything larger renders as `! >64k` rather than silently truncating to a plausible small number. The linked-list `prev` pointer that Safe's owner and module lists use renders as the word `SENTINEL` when it is the `0x000…001` marker, so a user can tell a list pointer apart from a real address that happens to start with zeros. "Add an owner and drop the threshold to 1" is a complete takeover, and it should read like one on the screen. It does. ## What "decoded on the device" means here The phrase gets used loosely, so it is worth being exact about the claim. Nothing PQ1™ displays comes from the companion app as text. The companion supplies *bytes* (the canonical SafeTx, the raw inner calldata) and the device independently hashes them, re-derives the EIP-712 digest, and compares it against the value the chain will record. Only then does the renderer turn those verified bytes into words. Token symbols and decimals come from a Merkle-verified metadata bundle checked against a firmware-pinned root, and if the metadata's contract address does not match the call's target, the device silently falls back to raw hex rather than accepting a symbol for the wrong token. An `approve` for the maximum `uint256` renders the word `unlimited`, not a 78-digit number a human will not read. Where a token amount cannot be resolved, it renders as a hex head and tail the user can compare byte-for-byte against the dapp. Where the inner call is genuinely unknown, the device shows a loud `! BLIND SIGN` page, and only after proving the call is *absent* from its own descriptor catalogue. A call the firmware ought to understand but could not bind is a hard refusal, not a blind page. The one thing that never happens is a confident-looking sentence with nothing behind it. ## How we know the decoders are right A decoder that disagrees with the EVM is worse than no decoder, because it produces a screen the user is entitled to believe. So the decoders are not just tested: - **The typehashes verify themselves.** Every CI run recomputes `keccak256` of each canonical type string and asserts it equals the hardcoded constant, for the domain typehash, the `SafeTx` typehash, and all eight management selectors. A typo cannot survive a build. - **The decoders are bounded-verified.** The canonical SafeTx decoder, the `execTransaction` decoder, the `multiSend` framing decoder and the management-op classifier carry Kani proofs over symbolic input: freedom from panics, arithmetic overflow and out-of-bounds access, plus *decode soundness*: if the decoder accepts, every displayed field is a verbatim copy of its byte range in the original input. The reverse property, completeness, is deliberately not claimed: a false rejection means refusing to clear-sign, which is safe. - **The batch walker is differentially tested against the real chain.** The packed-record walk is diffed against the actual deployed `MultiSendCallOnly` v1.3.0 runtime bytecode executed in `revm`, with a call-tracing inspector recovering the exact `(to, value, data)` sequence the EVM dispatches. The asserted property is the dangerous direction: **if the firmware accepts a batch, the EVM's dispatched sequence is byte-identical to what the screen showed.** The Rust parser is strict where the on-chain assembly is lenient: the assembly ignores trailing bytes and tolerates unbounded record counts. Every one of those divergences is a refusal, never an acceptance. The oracle there is worth dwelling on: it is not our own reference implementation. It is a different language, written by a different team, executed by a third-party interpreter, running the exact bytecode at the address the firmware allowlists. ## Where the post-quantum part comes in PQ1™ signs SPHINCS+C10, not ECDSA. Safe contracts cannot verify a SPHINCS+ signature, so the off-chain signature path is closed to us. The `approveHash` path is not, and that turns out to be a feature. `approvedHashes[owner][safeTxHash]` counts toward the threshold no matter *how* the owner arrived at it. The Safe does not inspect a signature; it reads a storage slot the owner set. So a PQ1™ smart account can be an owner of an existing Safe today, with no changes to Safe's contracts, no ECDSA fallback anywhere on the device, and no migration for the other owners. Every other owner keeps signing exactly as they do now. Yours is the one that survives a quantum adversary and, more immediately, the one that will not approve a delegatecall. ## What it does not do Being precise about the limits is the point of the exercise: - **Safe v1.1.x and earlier are not supported.** They used a domain separator without `chainId`, so our recomputed digest will not match the calldata and the transaction is refused. They self-police; we do not pretend otherwise. - **Arbitrary DELEGATECALL is refused, not warned about.** There is no honest way to explain "run this unknown contract's code inside your vault" on four rows of sixteen characters. A future version may add an explicit expert opt-in behind its own threat model. This one refuses. - **The refund *amount* is not shown**, because it depends on runtime gas consumption. The token and recipient are. - **Batches beyond six records, or beyond the page budget, are refused** rather than summarised. - **Truly unknown inner calls still produce a blind-sign page.** The device tells you loudly that it does not understand, shows you the target, selector, length, and a hash you can compare against the dapp, and leaves the decision with you. Clear-signing everything is not a claim anyone can honestly make. Refusing to *pretend* is. ## The short version Bybit's signers did nothing wrong. They used hardware wallets, they checked what was on the screen, and the screen did not contain the field that mattered. Blind signing is not a UX inconvenience; it is the largest exploitable surface in self-custody, and the industry has spent a decade normalising it. PQ1™ takes the opposite position. If the device cannot prove what a transaction does, it does not sign it. If it can, it says so in words, derived from bytes it verified itself, including the fields nobody else shows you. Every line of that decoding is published under GPLv3. You do not have to take our word for any of it. They ask you to trust. We let you verify. PQ1™. --- ## The problem with hardware wallets today Every consumer hardware wallet currently on the market signs with elliptic-curve cryptography. The same ECDSA schemes that Vitalik has publicly estimated have a 20% chance of being broken before 2030, and that Google has set an internal 2029 deadline to migrate away from across their own infrastructure. As of now, ECDSA is not broken, but three things should force every self-custody user to think seriously about what their next hardware wallet looks like: 1. **Harvest-now-decrypt-later is already happening.** Every transaction you've ever signed exposes your public key on-chain. A sufficiently large quantum computer can retroactively derive the private key from a public key. If you’ve ever made a single transaction, your funds are at risk, and 99.9% of wallets have. Also, with a fast enough quantum-computer, an attacker could derive your private key from a tx that is in the mempool and outbid you, stealing your funds when you make your first transaction. 2. **Migration takes years, not weeks.** This is why Google's 2029 deadline exists. They don't think Q-Day is 2029; they think migration takes that long. 3. **SPHINCS became a standardized post-quantum signature scheme.** And Ethereum's account abstraction (ERC-4337) gave us a way to use it, without a hard fork. The pieces are here. What’s been missing is a hardware wallet that actually assembles them, and one that does so in a way you can verify, not trust. We built PQ1™ on four key architectural decisions. Each one is a direct response to a specific failure we've watched crypto ship for the last decade. Together, they make PQ1™ the first hardware wallet that is materially more secure than anything else on the market, and the last one you’ll ever have to migrate to. ## Innovation 1: Post Quantum SPHINCS signatures via ERC-4337 A post-quantum hardware wallet that cannot sign post-quantum transactions is marketing, not engineering. Several competitors have announced "quantum-resistant" or “updated with post-quantum keys” product lines in recent years. None of these wallets sign transactions with a standardized post-quantum algorithm today, they merely employ “post-quantum signed” updates. This protects the device, not the assets secured by it. PQ1™ secures the assets with post-quantum signatures. We implement SPHINCS, the gold standard in PQC as the primary signature scheme, and we surface it to the user through an ERC-4337 smart-wallet. This is the exact architecture Vitalik named in his 2026 Ethereum quantum-resistance roadmap as the practical migration path for every Ethereum user. There are three reasons this matters: 1\. **SPHINCS is hash-based**. Breaking it requires breaking the underlying hash function, which is a strictly weaker cryptographic assumption than breaking an elliptic-curve discrete log. It is not reliant on unproven hardness assumptions like lattice schemes. It is conservative cryptography. 2\. **ERC-4337 makes the gas cost tractable**. Pure on-chain SPHINCS verification on L1 is expensive because the signatures are large (roughly 8–50 KB). Using our gas friendly SPHINCS-C10 implementation, verification happens inside the smart wallet, and gas is paid once for the verification logic (\~197K gas in our benchmarks, \~62K if batched with three or more ops), and the signature itself lives in the UserOp. On L2s like Base and Arbitrum, this is negligible. 3\. **PQ1™ is not just a post-quantum signer, it is a migration device.** While you don't need to migrate today, having a wallet on your desk to which you can migrate to in minutes when the time comes, is insanely valuable. ## Innovation 2: Reproducible builds with 8-word bootloader verification If there was ever a time for hackers to exploit funds, it would be prior to migrating to a secure device like the PQ1™. Some hardware wallets even state that updates could include the extraction of private keys. This is an explicit attack vector, and it is the reason why the PQ1™ is built differently. A closed-source hardware wallet is asking you to take two things on faith at once: 1. That the firmware does what the vendor says it does, 2. That the firmware running on your device is the firmware the vendor claims to have shipped. You cannot verify either. The only security guarantee you have is the vendor's reputation. PQ1™ replaces both acts of faith with a single act of verification. Our firmware, bootloader, and build pipeline are fully open source. Anyone can compile the firmware themselves, from source, and produce a bit-for-bit identical binary to what we ship. This is what "reproducible builds" means in the strict sense, the same source always produces the same binary, for anyone, anywhere. **On every boot, PQ1™ displays an 8-word bootloader hash,** a human-readable digest of the firmware running on the device. You compare those eight words to the hash of the firmware you built yourself (or to a hash published by security researchers who built it). If they match, the device is running the code you expect. If they don't, something has changed. *This is a fundamentally different trust model.* Other wallets’ closed-source secure element means nobody can verify what is running on the device, not the company's own customers, not independent security researchers, not even regulators. Our reproducible-build pipeline means anyone can verify. No other hardware wallet currently provides this. ## Innovation 3: Dual EAL6+ enclaves with XOR-split seed from two different vendors Every single-enclave hardware wallet publicly researched has eventually been broken. This is not a hypothetical. Kraken Security Labs demonstrated a glitch attack on Trezor's STM32 in 2020\. Ledger's own Donjon team has published side-channel research against competing and predecessor chips. Every one of these attacks relied on compromising a single piece of silicon. A single enclave is a single point of failure. PQ1™ splits the seed across **two EAL6+ certified secure elements, sourced from two entirely different vendors with entirely different supply chains**. The seed is stored as an XOR of two random halves, one in each enclave. Knowledge of one half provides *zero information* about the other. This is information-theoretically secure, not merely computationally hard. To extract the key, an attacker must: - Compromise two separate pieces of silicon from two separate vendors, and - Do so in the same device, without triggering any of the layered physical tamper detection, and - Succeed in a scenario where no single public research attack has yet defeated dual-vendor architecture. The common rebuttal is that two enclaves double the attack surface. This is true in the sense that there are two pieces of silicon to attack. It is false in the sense that matters: both must fall for the seed to leak. **This is strictly stronger than any single-enclave design.** Dual-vendor, XOR-split seed is new to consumer hardware wallets. Competitors who cite "multiple secure elements" in their marketing typically use three chips from the same vendor, which, if that vendor has a supply-chain compromise, fails catastrophically. Different vendor, different supply chain, different attack geometry. That is our design goal. ## Innovation 4: Locally verified clear-signing; No more blind signing. Look at the last dozen major hardware-wallet-adjacent exploits of the past two years. Inferno Drainer. The 2025 Bybit Gnosis blind-signing attack. The WazirX multisig drain of 2024\. The Wintermute Profanity incident. In almost every case, the user's hardware wallet did exactly what it was designed to do: it asked for approval, the user approved, and funds were drained. The root cause was that the user had no meaningful way to understand what they were approving. Most hardware wallets show a hexadecimal blob \`\`\` `0x5a1f...` \`\`\` and ask the user to trust that the app is telling them the truth about what that blob does. *Blind signing is the largest exploitable attack surface in all of self-custody.* And the industry has normalized it. **PQ1™ replaces blind signing with locally-verified clear-signing**. CoW Swap orders and [Safe multisig transactions](/learn/safe-multisig-transactions-decoded-on-device) are reduced to a human-readable summary that the device itself proves corresponds to the on-chain operation: *"Sell 100 USDC for at least 0.4 WETH on CoW Swap"* Not a hash. Not a hex blob. Not a "trust this app" prompt. The actual trade intent, verifiable on-device. Clear-signing is not a feature. It is the single most consequential security decision in a hardware wallet's UX. PQ1™ is the first consumer device that makes it work for arbitrary smart-contract calls. ## Open hardware, open software, fully inspectable Each of the four innovations above is a big step above current hardware wallets, but together they're held up by something more fundamental: **everything on PQ1™ is open and verifiable, end to end.** This is not an open-source-as-marketing label. It is fully verifiably open-source with the chops to prove it. Specifically: - **Hardware schematics** are public. The PCB design, the component list, the secure-element pinouts, the tamper-detection circuitry. You can reconstruct the device from its published design files in our Github repo. - **Firmware** is published under GPLv3. - **Bootloader** is published under GPLv3. - **Smart contracts** (the AA wallet, the SPHINCS verifier, the paymaster) are published under AGPL, under security review by Trail of Bits, and deployed with verified source on every chain we support. - **Build pipeline**. Anyone can produce the shipping firmware binaries byte-for-byte. - **Reference firmware-hash tooling** lets you derive the 8-word bootloader hash from any source tree, so you can verify your device matches your build in 30 seconds. That means every PQ1™ device that ships is simultaneously a consumer product and a subject of continuous, adversarial, public security research. The device gets more trustworthy every month as researchers examine more of it. A closed-source device cannot benefit from this feedback loop; nobody outside the vendor can look at it. We want everything to be laid out in the open, so you can verify it yourself, not just trust us. ## Why nobody has built this yet Hardware wallets are a durable-goods business with high trust friction. Vendors are incentivized to ship the same architecture year after year with new industrial design, because every architectural change risks breaking customer confidence. The result is that the category has stagnated while the threat model has evolved. PQ1™ is designed from the opposite direction: we started by asking what the threat model will look like in 2029, quantum-emergent, AA-native, clear-sign-required, verifiability-mandatory, and we built backwards from there. ## What this means for you If you're using a hardware wallet today, you have three options: **You can** **stay with what you have**. ECDSA is fine today. If quantum-emergent attacks arrive later rather than sooner, if your addresses stay unused, if your hardware vendor never ships a compromised firmware update, you will probably be fine. Many people will make this bet. **You can wait to migrate**. Every major vendor is likely to announce a "quantum-safe" SKU over the next 18 months. Some will be real. Most will be closed-source firmware claims with no verification path. You will need to evaluate each one against the four questions we've built PQ1™ to answer: Is the firmware open source? Is the build reproducible? What is the signature scheme? Dual-enclave or single? **Or you can migrate now**, at the only point in hardware-wallet history where a device exists that answers all four questions correctly, and where migrating is cheap, unforced, and verifiable. PQ1™ is that device. They ask you to trust. We let you verify. Post-quantum. Open source. Yours. PQ1™. --- Four years ago we were building mobile operating systems. A bet we took on where the crypto market was headed. The specific architectural decisions we made with the dGEN1 revealed a way to make smart accounts more prolific than we'd originally thought. We knew they were useful, but after Google released its recent 2029 Q-day deadline, ERC-4337 became the architecture that would unlock post-quantum security for the foreseeable future. Since ethOS paved the way for making smart wallets interoperable, we knew what the next logical step was. And at the same time, 3 things converged which hadn't been true just months before: 1. Google publicly committed to migration on a near-term timeline. 2. Vitalik publicly stated that the emergency plan exists *and* is something we want to avoid having to use. 3. SPHINCS emerged as the dominant algorithm for post-quantum cryptography. The pieces just revealed themselves, but had not been assembled in a device a user could hold. Until now. That is why we built the PQ1™. ![The PQ1 post-quantum hardware wallet by Freedom Factory](/pq1_banner.jpg) ## What we believe We believe Q-Day is closer than the consensus market thinks. The work on Quantum computers is growing exponentially, and quantum algorithms are becoming exponentially more efficient, meaning when those two lines meet, Q-day has arrived. And they’re each accelerating. ![][image2] Put another way, Mosca's inequality, the framework most policy bodies use to reason about migration windows, gives you the math: ***| if the time your secret must remain confidential (X) plus the time your migration takes (Y) is greater than the time until a cryptographically relevant quantum computer arrives (Z), you are already in trouble*****.** In short, if X \+ Y \> Z (Q-Day arrives), you’re fucked. Because many think Ethereum has plans to upgrade, they assume they are safe. This is wrong. The EVM itself will be quantum secure, but all EOA (externally owned accounts), the wallets everyone uses today, can be compromised. Even if you've signed even a single transaction, a quantum computer can derive your private key from the public one. That means every wallet, hot, cold, hardware, software, multi-sigs, custodial accounts, etc…will need to migrate. The migration is then asymmetric: if you migrate early, you pay a small gas cost and lose nothing. If you wait until an emergency, you depend on a hard fork that cannot make your assets secure without you migrating. But ethereum users can do better, if they start now. And most importantly, we believe that the device a user trusts with their assets should be a device the user can *verify*, not a device the user is *asked to trust*. This is what made the architectural decisions for PQ1™ easy. PQ1™ exploded view with component callouts - display stack, mainboard and machined enclosure separated ## What we built PQ1™ is the first consumer hardware wallet that: 1. **Signs transactions using Post-Quantum verified SPHINCS-C10 algorithm, with verification handled inside an ERC-4337 smart wallet.** This is the exact architecture Vitalik specifically named as the practical migration path in his February 2026 Ethereum quantum-resistance roadmap. 2. **Ships with fully open hardware schematics, fully open firmware (GPLv3), fully open smart contracts (AGPL), and fully public reproducible-builds.** Anyone can compile the firmware from source and produce a bit-for-bit identical binary to what we ship. 3. **Splits the user's seed across two EAL6+ secure enclaves from two different vendors, with two different supply chains**, using an XOR construction that is information-theoretically secure: knowledge of one half provides zero information about the other. 4. **Replaces blind signing with local clear-signing (On device tx decoding).** CoW Swap orders and [Safe multisig transactions](/learn/safe-multisig-transactions-decoded-on-device) read as a human-readable intent ("Sell 100 USDC for at least 0.4 WETH on CoW Swap") rather than a hex hash. PQ1™ will end blind-signing for good. Each of these UX decisions stems from a specific failure that the crypto market has suffered, or will in the coming years. PQ1™ is the first wallet to solve all of them, at once. ## Why now Existing hardware wallets ask you to take two things on faith simultaneously: that the vendor's firmware does what the vendor claims it does, and that the firmware running on your specific device is the firmware the vendor says it shipped. You cannot verify either claim. The only security guarantee you have is the vendor's reputation. Hardware wallets are durable goods. The wallet you buy today is the wallet that sits in their drawer for five to ten years. Which means the architectural decisions we ship today will determine how much onchain value is exposed when Q-Day arrives, and how users interact with hardware wallets into the future. We are not asking anyone to trust us. We are giving you the tools to verify. Post-quantum. Open source. Yours. PQ1™. \- *The FreedomFactory team* [image2]: --- ## Compare **GridPlus Lattice1** is, on most security dimensions, the best classical hardware wallet on the market - a 5-inch touchscreen, multi-element architecture, the SafeCard hardware-backup ecosystem, and a strong commitment to verifiable supply chains. It's the device most often recommended to high-net-worth holders who outgrow Ledger or Trezor. **PQ1™** is built for the one dimension Lattice1 doesn't address: **the quantum threat**. This page compares the two. ## Side-by-side | Feature | PQ1™ | GridPlus Lattice1 | |---|---|---| | Signature scheme | **SPHINCS+ (FIPS-205 design), no ECDSA fallback** | ECDSA only | | Quantum-secure | **Yes** | No | | Secure elements | **Infineon OPTIGA Trust M V3 + NXP SE050 (CC EAL6+ each, seed XOR-split)** | Microchip ATECC608A + GeneralPlus secure MCU (both closed) | | Vendor diversity for seed material | **Two vendors (Infineon + NXP)** | Single vendor pair, no seed-XOR split disclosed | | Open firmware | Yes (reproducible) | Partial (some closed components) | | Air-gapped | **Yes (USB-C only)** | No (Wi-Fi) | | Bitcoin support | No (v1: pure-PQ EVM only) | Yes | | Ethereum + EVM L2 | **Yes (ERC-4337 v0.6)** | Yes | | Solana support | No (v1: pure-PQ EVM only) | Yes | | ERC-4337 native | **Yes (v0.6 smart account)** | No | | Hardware backups | Seed-card | SafeCard ecosystem | | Touchscreen | No | Yes (5") | | Price | **$179** | $397 | ## Where Lattice1 wins GridPlus has built a serious device. The categories where it leads: - **The screen.** Lattice1's 5-inch touchscreen is the best on-device transaction-review surface in the category. Smart-contract calldata that would scroll through PQ1™'s small LCD is fully visible at once on Lattice1. - **SafeCards.** GridPlus's smartcard-based backup ecosystem is unique. Each SafeCard is itself a tamper-evident secure element that can hold a derived key, allowing multi-card multi-sig and key-sharing workflows that don't exist elsewhere. - **Multi-chain coverage.** Lattice1 signs Bitcoin, Solana, and others. PQ1™ v1 supports Ethereum and every EVM L2 only - by design, since shipping Bitcoin or Solana would require a classical-signer fallback that defeats the post-quantum security promise. - **Maturity.** Lattice1 has shipped since 2019 with an active firmware track record. PQ1™ is new. ## Where PQ1™ wins ### Post-quantum signing - the entire reason this comparison exists Lattice1 produces only **secp256k1 ECDSA** signatures. Multiple secure elements, large touchscreen, hardware-backed multi-sig - none of it helps after Q-Day, because the signature scheme itself is broken. A quantum adversary doesn't have to extract the seed from Lattice1's secure elements; they compute the seed from the public key on-chain. PQ1™ signs with **SPHINCS+** - the hash-based signature family NIST standardized as SLH-DSA in FIPS-205 - using a parameter set called C10 (4-KB signatures, 128-bit post-quantum security). There is no ECDSA fallback in the firmware or smart wallet. After Q-Day, PQ1™ stays secure; Lattice1 does not. See [why we built for Q-Day now](/learn/why-we-built-the-first-quantum-safe-hardware-wallet), and [the math behind the C10 parameter set](/learn/is-sphincs-c10-secure). ### Vendor-diverse seed split Lattice1 uses two closed-source chips, but no public disclosure indicates the seed is XOR-split across them; both are reviewable only under vendor NDA. PQ1™ splits the BIP-39 entropy across two CC EAL6+ secure elements sourced from **different vendors** (Infineon OPTIGA Trust M V3 + NXP SE050) with independent side-channel countermeasures. Neither chip alone reveals a single bit of the seed. Read more on the [dual secure-element architecture](/learn/why-pq1-is-a-10x-over-the-current-hardware-wallet-landscape). ### Air-gap Lattice1 includes **Wi-Fi** for "always online" companion-app pairing. GridPlus has invested in hardening the Wi-Fi stack, but it's a present radio, with all the structural risk that implies. See the [PQ1™ whitepaper](/whitepaper) for the air-gap threat model. PQ1™ has no radio in the BOM at all - communication is USB-C HID only. ### Account abstraction Lattice1 produces standard EOA signatures. PQ1™ settles to **ERC-4337 v0.6 smart wallets** that verify the post-quantum signature on-chain via an immutable Yul verifier contract. Lattice1 will eventually support ERC-4337 signing - it's a firmware upgrade - but the post-quantum signing capability requires firmware support Lattice1 doesn't have. ### Price Lattice1 is $397. PQ1™ is $179. For most users, $220 is the difference between buying one wallet for self and one for a family member; for everyone, it's the difference between an excellent classical wallet and a post-quantum wallet at less than half the price. ## Bottom line Lattice1 is the right choice if: - You're optimizing for classical-cryptography security and need the 5-inch screen for sophisticated calldata review. - You need multi-chain coverage including Bitcoin and Solana. - The SafeCard ecosystem fits your operational model (multi-card backup, distributed signing). - Quantum risk is not part of your threat model. PQ1™ is the right choice if: - You take Q-Day seriously. - Your holdings are on Ethereum and EVM L2s, and you want a vendor-diverse seed split rather than a single-vendor secure-element pair. - $397 vs $179 matters. For most long-term holders in 2026, the calculus has shifted: a quantum-secure wallet at $179 strictly dominates a classical-only wallet at $397. [Reserve PQ1™](/checkout). --- If you're choosing a hardware wallet in 2026 and your coins matter past the next decade, the deciding question is whether the device can survive **Q-Day** - the moment a quantum computer can break ECDSA. **Ledger** is the most-shipped hardware wallet brand in the world, with strong app integrations and a polished UX. **PQ1™** is the first wallet to ship signing with [SPHINCS+ (the design NIST standardized as SLH-DSA in FIPS-205)](/learn/is-sphincs-c10-secure). This page compares the two on what actually matters. ## Side-by-side | Feature | PQ1™ | Ledger Nano S Plus | Ledger Nano X | Ledger Stax | |---|---|---|---|---| | Signature scheme | **SPHINCS+ (FIPS-205 design), no ECDSA fallback** | ECDSA only | ECDSA only | ECDSA only | | Quantum-secure | **Yes** | No | No | No | | Secure elements | **Infineon OPTIGA Trust M V3 + NXP SE050 (CC EAL6+ each, seed XOR-split)** | STMicro ST33K1M5 (single, closed) | STMicro ST33-series (single, closed) | STMicro ST33K1M5 (single, closed) | | Vendor diversity for seed material | **Two vendors** (Infineon + NXP) | Single vendor | Single vendor | Single vendor | | Reproducible firmware | **Yes (byte-compare against source)** | Partial | Partial | Partial | | Air-gapped | **Yes (USB-C only)** | Yes (USB-C) | No (Bluetooth) | No (Bluetooth) | | Bitcoin support | No (v1: pure-PQ EVM only) | Yes | Yes | Yes | | Ethereum + EVM L2 | **Yes (ERC-4337 v0.6)** | Yes | Yes | Yes | | Solana support | No (v1: pure-PQ EVM only) | Yes | Yes | Yes | | ERC-4337 native | **Yes (v0.6 smart account)** | No | No | No | | Companion app maturity | New (2026) | Ledger Live, mature | Ledger Live, mature | Ledger Live, mature | | Price | **$179** | $79 | $149 | $399 | ## Where Ledger wins To be fair to a serious competitor: Ledger has a real lead in places that don't depend on cryptography. - **Ledger Live ecosystem.** Years of integrations with hundreds of dApps, staking providers, NFT platforms, and CEX deposit flows. PQ1™ ships with ERC-4337 wallet support and the major dApp aggregators on day one, but Ledger Live is wider. - **Multi-chain coverage.** Ledger signs Bitcoin, Solana, Polkadot, Cardano, and dozens of others. PQ1™ v1 supports Ethereum and every EVM L2 only - by design, since shipping Bitcoin or Solana would require a classical-signer fallback that defeats the post-quantum security promise. - **Touchscreen UX.** Ledger Stax has a 3.7" e-paper touchscreen - a more polished interaction model than PQ1™'s two-button interface. If the device is your primary daily-driver wallet UX, this matters. - **Price at the low end.** Ledger Nano S Plus is $79; PQ1™ is $179. For a quantum-vulnerable wallet, Ledger is cheaper. For a quantum-secure wallet, PQ1™ is the only option. ## Where PQ1™ wins The categories that matter for long-term security: ### Signature scheme Every Ledger device signs with **secp256k1 ECDSA** (Bitcoin, Ethereum) or **ed25519** (Solana, Polkadot). Both fall to Shor's algorithm on a CRQC. Ledger's roadmap mentions "quantum-resistant" cryptography in aspirational terms, but as of 2026, no shipping Ledger product produces a post-quantum signature. PQ1™ signs with **SPHINCS+** - the hash-based signature family NIST standardized as SLH-DSA in FIPS-205 - using a parameter set called C10 tuned for on-chain verification (4-KB signatures, 128-bit post-quantum security). There is no ECDSA fallback in the firmware or smart wallet. See [why we built for Q-Day now, not in 2030](/learn/why-we-built-the-first-quantum-safe-hardware-wallet), and [the math behind the C10 parameter set](/learn/is-sphincs-c10-secure). ### Secure-element architecture Ledger uses a single STMicroelectronics ST33K1M5 - a closed, NDA-only secure element. If that one chip ships with a flaw - and historically, even highly-trusted secure elements ship with side-channel weaknesses that take years to surface - the chip vendor's customers find out under NDA, fix it under NDA, and the broader cryptanalytic community has to reverse-engineer to verify. And a single secure element means a single point of failure for the seed. PQ1™ uses a [dual secure-element architecture](/learn/why-pq1-is-a-10x-over-the-current-hardware-wallet-landscape): an Infineon OPTIGA Trust M V3 and an NXP SE050, both CC EAL6+, sourced from different vendors with different countermeasures. The BIP-39 entropy is XOR-split across the two - neither chip alone reveals a single bit of the seed. A side-channel break of one secure element leaves the seed intact. ### Reproducible builds Ledger publishes some source code (the BOLOS OS app SDK is public; the firmware itself is partially closed). The firmware running on your device cannot be byte-compared against a build you produce locally - you trust Ledger's signing infrastructure. PQ1™'s firmware is **fully reproducible**. Source and build scripts are published; the binary on your device can be byte-compared against a local build, so anyone - not just PQ1™ - can independently verify what a release contains. ### Air-gap Ledger Nano X and Stax ship with **Bluetooth** for phone pairing. The hardware supporting that radio has had public vulnerabilities (Kraken Security Labs' 2020 disclosure on the Nano X's non-secure MCU - patched, secure element unaffected), and Bluetooth SoC stacks in general have a steady CVE history (SweynTooth, BrakTooth). PQ1™ has **no radio at all** - communication is USB-C HID only. See the [PQ1™ whitepaper](/whitepaper) for the air-gap threat model. ## Bottom line Ledger is the right choice if: - Your coins are short-term trading positions you'll have moved out of by 2028. - You need broad multi-chain support including Bitcoin and Solana. - You prioritize the polished Ledger Live UX above all else. - $79 is meaningful budget pressure. PQ1™ is the right choice if: - Your holdings are on Ethereum and EVM L2s, and you expect to keep them past the 2030 NIST migration deadline. - You want a hardware wallet with no single point of failure on seed storage. - You take the harvest-now-decrypt-later threat seriously and want to be on a post-quantum signature scheme today, with no ECDSA fallback that breaks on Q-Day. [Reserve PQ1™](/checkout) for $179. --- **Trezor** has the strongest open-source pedigree in hardware wallets - SatoshiLabs invented the modern hardware wallet category in 2014 with the Trezor One, and the firmware has been open source from day one. With the **Safe 7**, Trezor now markets "the world's first quantum-ready hardware wallet" - a claim that is technically accurate and easy to misread, so we [dissect it below](#quantum-ready-vs-quantum-secure-dissecting-the-safe-7-claim). **PQ1™** is built in the same open spirit and goes the step Trezor hasn't: [post-quantum signing of your actual transactions](/learn/is-sphincs-c10-secure), plus a [dual secure-element architecture](/learn/why-pq1-is-a-10x-over-the-current-hardware-wallet-landscape) that splits the seed across two independently-sourced chips. This page compares them. ## Side-by-side | Feature | PQ1™ | Trezor Model One | Trezor Model T | Trezor Safe 3 | Trezor Safe 5 | Trezor Safe 7 | |---|---|---|---|---|---|---| | Transaction signatures | **SPHINCS+ (FIPS-205 design), no ECDSA fallback** | ECDSA only | ECDSA only | ECDSA only | ECDSA only | ECDSA/EdDSA only | | Assets quantum-secure | **Yes** | No | No | No | No | **No** - by Trezor's own docs | | Post-quantum firmware verification | **Yes (SPHINCS+, sole scheme)** | No | No | No | No | Yes (SLH-DSA-128 + Ed25519 hybrid) | | Open firmware | Yes | Yes | Yes | Yes | Yes | Yes | | Secure elements | **OPTIGA Trust M V3 + NXP SE050 (seed XOR-split, CC EAL6+ each)** | None (MCU only) | None (MCU only) | OPTIGA Trust M (PIN-only; seed in MCU) | OPTIGA Trust M (PIN-only; seed in MCU) | TROPIC01 + OPTIGA Trust M (PIN/attestation; seed encrypted in MCU flash) | | Seed in a secure element | **Yes (split across two)** | No | No | No (MCU) | No (MCU) | No (MCU, SE-wrapped) | | Reproducible firmware | **Yes** | Yes | Yes | Yes | Yes | Yes | | Air-gapped | **Yes (USB-C only)** | Yes | Yes | Yes | Yes | No (Bluetooth built in) | | Bitcoin support | No (v1: pure-PQ EVM only) | Yes | Yes | Yes | Yes | Yes | | Ethereum + EVM L2 | **Yes (ERC-4337 v0.6)** | Yes | Yes | Yes | Yes | Yes | | Solana support | No (v1: pure-PQ EVM only) | No | Yes | Yes | Yes | Yes | | ERC-4337 native | **Yes (v0.6 smart account)** | No | No | No | No | No | | Touchscreen | No | No | Yes | No | Yes | Yes (2.5" color) | | Price | $179 | $69 | $169 | $79 | $169 | $249 | ## "Quantum-ready" vs quantum-secure: dissecting the Safe 7 claim The Trezor Safe 7 advertises itself as **"the world's first quantum-ready hardware wallet."** The engineering behind that phrase is real - and it's worth being precise about what it does and doesn't cover, because the difference is your money. ### What the Safe 7's quantum-readiness actually protects Three things on the Safe 7 use post-quantum cryptography today: **the boot process, firmware updates, and device authentication.** - The boardloader verifies every firmware update with a **hybrid signature: classical Ed25519 plus SLH-DSA-128**, the hash-based scheme NIST standardized in FIPS-205. A quantum attacker cannot forge a Trezor firmware update. - Device authentication (proving your Safe 7 is genuine) uses **ML-DSA-44**, the lattice scheme from FIPS-204. This is genuinely good engineering, and we'll say so plainly: hardening the root of trust with FIPS-205/204 signatures is the right move, and Trezor shipped it first among the incumbents. ### What it does not protect: your funds Every cryptocurrency transaction the Safe 7 signs still uses **secp256k1 ECDSA or ed25519 EdDSA** - the exact algorithms Shor's algorithm breaks. Trezor's own knowledge base defines quantum-ready as "a device which will be able to run post-quantum cryptographic updates" and states it outright: **"A quantum-ready device does not protect your assets from quantum computers at this time."** So on Q-Day, here is what the Safe 7's quantum-readiness buys you: a quantum attacker **cannot push malicious firmware onto your device**. But they don't need to. Your public key is exposed on-chain the moment you transact (and even sits in the mempool before your first transaction confirms). A cryptographically-relevant quantum computer derives the private key from that public key and **moves your funds directly - no firmware, no device, no Trezor involvement required.** The vault door gets a quantum-proof lock; the assets inside are keyed to a lock that quantum computers open. Quantum-*ready* means the device could someday receive a post-quantum update. Quantum-*secure* means your assets are protected now. The Safe 7 is the former. It is not the latter, and Trezor's documentation - to their credit - says so. ### Why Trezor can't just fix it with an update Trezor's stated reason is fair: "Blockchains must first upgrade to post-quantum cryptography." For Bitcoin, that's true - post-quantum signatures need a protocol change that hasn't happened. But on Ethereum and every EVM L2, it stopped being true when account abstraction shipped. **ERC-4337 lets a smart-contract wallet verify any signature scheme on-chain today, no hard fork required.** That is exactly the loophole PQ1™ is built on: SPHINCS+ signatures verified by an immutable on-chain Yul contract. It's also why PQ1™ v1 is EVM-only - it's the ecosystem where quantum-secure assets are possible right now, so that's where we shipped them. ### PQ1™ does both halves For clarity, the same checklist applied to PQ1™: - **Quantum-secure firmware updates?** Yes. PQ1™'s firmware-update path is signed with SPHINCS+ - the same FIPS-205 family the Safe 7 uses, but as the sole scheme rather than a hybrid alongside a classical signature. - **Quantum-secure assets?** Yes. Every transaction is signed with SPHINCS+ and verified on-chain. There is no ECDSA anywhere - not in the wallet, not in the update path, no "just in case" classical fallback that becomes the weakest link on Q-Day. One sentence to take away: **the Safe 7 quantum-protects the device; PQ1™ quantum-protects the device *and* the money it guards.** ## Where Trezor wins - **Track record.** Trezor has shipped continuously since 2014. Its firmware has been audited by hundreds of independent researchers, with every CVE published and fixed in the open. PQ1™ is new - the firmware is open and reproducible, but the multi-year track record doesn't yet exist. - **Multi-chain coverage.** Trezor signs Bitcoin, Cardano, and dozens of others. PQ1™ v1 supports Ethereum and every EVM L2 only. - **Trezor Suite ecosystem.** Mature companion app with strong privacy features (Tor, coin control, CoinJoin via Wasabi integration). PQ1™ ships with ERC-4337 wallet support but Trezor Suite is broader for Bitcoin-first holders. - **Polish and convenience.** The Safe 7 has a 2.5" color touchscreen, Bluetooth, and Qi2 wireless charging; the Model T and Safe 5 have touchscreens too. PQ1™ uses two physical buttons (short-press to page through the transaction, long-press to confirm or cancel), wired directly to the MCU with no touch-controller IC in the path, and is USB-C only - deliberately minimal attack surface, less polished interaction. - **Price at the low end.** Trezor Safe 3 is $79 and Trezor Model One is $69 (the Safe 7, at $249, is $70 more than PQ1™). All quantum-vulnerable where it counts. ## Where PQ1™ wins ### Post-quantum signing of transactions Every Trezor device signs transactions only with **secp256k1 ECDSA** and **ed25519 EdDSA**. Both fall to Shor's algorithm. The Safe 7 is the first Trezor to ship post-quantum cryptography at all, but [only in the firmware-update and authentication path](#quantum-ready-vs-quantum-secure-dissecting-the-safe-7-claim) - no shipping Trezor product produces a post-quantum signature over a transaction as of 2026. PQ1™ signs every transaction with **SPHINCS+** - the hash-based signature family NIST standardized as SLH-DSA in FIPS-205. There is no ECDSA fallback anywhere in the firmware or smart wallet. After Q-Day, PQ1™'s assets remain secure while every ECDSA-controlled address - including those managed by a quantum-ready Safe 7 - is spendable by any sufficiently-equipped adversary. See our [SPHINCS+C10 signature walkthrough](/learn/is-sphincs-c10-secure). ### Secure-element architecture Trezor was famously without a secure element on the Model One and Model T - running the seed in MCU memory, with no hardware boundary between the seed and any code that ran on the device. The Safe 3 and Safe 5 added an Infineon OPTIGA chip, but only for **PIN protection** - the seed and signing operations still run in MCU flash. The Safe 7 adds a second secure element (TROPIC01, alongside the OPTIGA) for PIN protection, attestation, and randomness - but the seed still lives encrypted in MCU flash and signing still runs on the MCU. PQ1™ splits the BIP-39 entropy across two CC EAL6+ secure elements from two different vendors (Infineon OPTIGA Trust M V3 and NXP SE050) with the seed never present on a single chip. PIN gating runs in silicon on both SEs, with a three-way lockstep counter. Read more on the [dual secure-element architecture](/learn/why-pq1-is-a-10x-over-the-current-hardware-wallet-landscape). ### Account abstraction Trezor produces classical Ethereum signatures and depends on standard EOA accounts. PQ1™ produces SPHINCS+ signatures consumed by **ERC-4337 v0.6 smart wallets** that verify the post-quantum signature on-chain via an immutable Yul verifier contract. See [how PQ1™'s compressed SPHINCS+ signatures verify on-chain](/learn/is-sphincs-c10-secure). ## The open-source story, told carefully Both companies make legitimate open-source claims: - **Trezor:** open firmware, reproducible builds. Seed lives in MCU flash on every model; the OPTIGA secure element on the Safe 3/5/7 is closed-source. The Safe 7's TROPIC01 deserves genuine credit - it's the first secure element with a fully published, auditable design, a real step toward open silicon (though it doesn't yet carry an EAL6+ certification). - **PQ1™:** open firmware, reproducible builds, open smart-wallet contracts, and an open Yul post-quantum verifier. Seed is XOR-split across two closed but CC EAL6+ secure elements from independent vendors. Neither stack is open all the way down to certified silicon; no chip today combines an EAL6+ certificate with public RTL. PQ1™'s bet is that the **vendor-diverse XOR-split** beats any single chip's guarantees, and that **pure post-quantum signing on the MCU** is the right place to put the cryptography you can actually audit. ## Bottom line Trezor is the right choice if: - You value the longest-running open-source hardware wallet track record. - You need Bitcoin, Solana, or another non-EVM chain. - You're a Bitcoin-first user who depends on Trezor Suite's coin control and CoinJoin features. - $69–$79 is meaningful budget pressure. PQ1™ is the right choice if: - You want your **assets** quantum-secure today - not just your firmware updates - with no ECDSA fallback that breaks on Q-Day. - Your holdings are on Ethereum and EVM L2s, and you want the seed split across two vendors rather than trusting any single secure element. - You prefer an ERC-4337-native experience for the EVM ecosystem. [Reserve PQ1™](/checkout) for $179. ---