Trezor Prepares Hardware Wallets for Post-Quantum Era Amid Complex Signature Dilemmas

Bitcoin custody has always involved navigating varying degrees of operational and technical risk, but as technology advances, hardware wallet manufacturers are forced to look far beyond today’s cryptographic standards. Companies like Trezor, which build physical devices designed to keep a user’s private keys securely isolated offline, are actively preparing for a post-quantum world where entirely new challenges will emerge. This transition requires rethinking not just how user transactions are signed, but how the very hardware devices themselves authenticate firmware and protect against sophisticated future threats.

The urgency stems from the evolving landscape of quantum computing, which threatens to undermine the foundational elliptic curve cryptography currently securing the Bitcoin network. To address this existential threat, the Bitcoin developer and research community has been exploring various cryptographic alternatives. Among them, SHRINCS has emerged as the leading candidate for a post-quantum signature scheme. Proposed late last year by Blockstream Research Director Jonas Nick and cryptographer Mikhail Kudinov, SHRINCS centers on a composite hash-based approach that gives users the flexibility to make transactions using either stateful signatures or stateless signatures.

However, implementing SHRINCS on a global scale introduces profound architectural dilemmas for wallet manufacturers, according to Trezor CTO Tomáš Sušánka. Because SHRINCS relies heavily on stateful signatures to achieve high efficiency, it requires rigid, meticulous state tracking. Without precise tracking, users risk reusing keys, which can lead to catastrophic security failures and the complete theft of funds.

The core of the challenge lies in the fundamental trade-off between the two signature types supported by the SHRINCS framework. Stateless signatures are quite large—a characteristic that could negatively affect blockchain transaction fees, signature speed, and other network efficiency metrics. At the same time, stateless signatures are inherently safe to reuse. Conversely, stateful signatures are much smaller and more efficient, but they come with severe security risks if they are reused beyond a strictly limited signing budget.

The stateful component of SHRINCS is made up of a complex tree of one-time signatures. If these keys are accidentally used more than once, enough cryptographic information is leaked into the public ledger for a malicious actor to forge that user’s signature and effectively drain their wallet. If Bitcoin successfully adopts SHRINCS as its post-quantum standard, maintaining an exact and uncorrupted count of a wallet’s state will become a critical responsibility for wallet developers, opening up numerous potential edge-case security risks that must be engineered out of existence.

Addressing these risks during a recent episode of MARA Foundation TV, Sušánka highlighted the user experience dangers inherent in stateful cryptography. "You’re giving them an option to mess up," Sušánka said in reference to state tracking. "It’s our job to make it in a secure way, right? It shouldn’t be the user’s job."

To mitigate this risk, Trezor is actively weighing various options for how to support a secure user experience in a post-quantum environment. For instance, Sušánka noted that the company is considering making the heavier, slower stateless signatures the default setting for all standard users. Under this potential setup, the riskier stateful option would be tucked away behind an advanced settings wall, reserved only for power users who understand the technical implications and mechanics of state management.

While Sušánka recognizes that SHRINCS may represent the most conservative cryptographic choice because it relies on the same core cryptographic assumptions as SHA-256, he remains conflicted about its practical implementation. He admitted that he is "kind of torn on the topic because maintaining the state is a burden."

Elaborating on the logistical hurdles of state management, Sušánka pointed out a major structural flaw in how users interact with hardware backups. "For example, you can have two Trezors with the same recovery seed. How do you share the state between those two? You really don’t," he explained.

Despite these daunting synchronization challenges, Sušánka emphasized that the debate ultimately comes down to balancing competing engineering priorities. "That being said, as it is with everything, this is about trade-offs," Sušánka continued. "The [stateful] signatures are 10 times smaller… That makes a big difference. So, I just don’t want to throw it off the table completely."

Beyond the transaction signature scheme itself, Sušánka shared insights into another critical layer of defense that is often overlooked in discussions about post-quantum migration. While many analysts and developers are intensely focused on Bitcoin’s migration path to post-quantum addresses and transaction signatures, hardware wallet devices will also need to be physically updated to achieve full quantum protection. Most signing devices currently rely on quantum-vulnerable cryptography for internal, hardware-specific security functions, such as firmware verification and device authentication.

If users want to ensure their physical assets remain secure in a post-quantum world, they will eventually need to transition to "quantum-ready" devices. These are hardware units that utilize post-quantum cryptography not just for blockchain interactions, but for internal device and firmware authentication processes as well.

In anticipation of these evolving industry needs, Trezor has already begun shipping products like the Trezor Safe 7, which incorporates post-quantum cryptography into internal wallet authentication processes. Of course, the developers acknowledge that transactions made on these advanced devices will only become truly quantum-secure once the broader Bitcoin network itself successfully upgrades its underlying consensus rules to support post-quantum security.

Nevertheless, Sušánka warned the broader developer community not to wait too long to provide users with clear migration options. He believes that coordinating the transition for potentially millions of users will require significant time, testing, and coordination across the entire ecosystem.

Concluding his thoughts on the arduous path ahead, Sušánka urged pragmatism among developers and users alike. "People should be ready to make compromises," Sušánka said. "If we’re all going to be very strict on what can and cannot be done, we’re not going to get anywhere."