# 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-07-28T14:02:37.326Z
## 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://agentcheckout-pbar72i7jq-uc.a.run.app 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
*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**.
## “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
---
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 research on gas-efficient on-chain SPHINCS verifiers (the [SPHINCs⁻ project](https://github.com/nconsigny/SPHINCs-)), which 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™.
---
## 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**. Every Cowswap and most safe transactions intent is 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™.
## 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.
## 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).** Every cowswap and most safe transactions read as a human-readable trade 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.
---
