Trezor Eyes Stateless Signatures as Default If Bitcoin Adopts SHRINCS

Trezor would make stateless signatures the default on its Bitcoin wallets if the network adopts SHRINCS. The stateful alternative would move into advanced settings. The plan comes straight from Trezor's CTO, Tomáš Sušánka, who argues that managing one-time signature keys is a job for the wallet maker, not the customer.

"It shouldn't be the user's job," Sušánka said of tracking signature state. His concern is practical. A stateful scheme forces wallet software to keep a precise record of which one-time keys have been used, and to handle edge cases when something goes wrong.

What is SHRINCS, exactly?

SHRINCS is a proposed hash-based signature design from Jonas Nick, director of research at Blockstream, and cryptographer Mikhail Kudinov. It offers two modes. Stateless signatures can be reused without penalty. Stateful signatures rely on one-time keys arranged in a tree.

The tree structure is where the danger lives. Accidentally reusing a one-time key can leak information that lets an attacker forge a valid signature and spend the wallet's funds. Wallet software would need to track those keys carefully across every signing operation, a burden Sušánka considers too heavy to place on users.

Stateless signatures sidestep the reuse hazard entirely. But they come with a cost: size. Sušánka said stateful signatures are "10 times smaller," a difference he considers significant because larger signatures slow signing and push up transaction fees and related efficiency measures.

Why does Trezor favor the safer default?

The reasoning is about failure modes. A user who mishandles state loses funds. A user who accepts bigger signatures loses a little efficiency. Trezor judges the second outcome far more tolerable at scale.

Sušánka also raised a problem specific to Trezor's own product design. Two Trezor devices can share the same recovery seed. In a stateful system, both devices need an aligned record of which keys have been used. If they drift apart, the wallet slides back into the key-reuse risk the scheme was meant to manage.

He described SHRINCS as a conservative choice on cryptographic grounds, because it relies on assumptions also used by SHA-256, the hash function already underpinning Bitcoin's security today. No novel cryptographic trust is required.

What about quantum threats?

Most signing devices today rely on quantum-vulnerable cryptography for functions such as firmware verification and device authentication. Trezor is already shipping the Trezor Safe 7 with post-quantum cryptography for wallet authentication.

That protection stops at the device. It does not make Bitcoin transactions quantum-secure. Transactions would gain post-quantum protection only after Bitcoin itself upgrades its signature system — and no such upgrade has been agreed. Bitcoin's quantum-resistance proposals remain in draft stage.

So what does this change for holders? For now, nothing operationally. The decision is conditional: it takes effect only if SHRINCS or a similar hash-based scheme reaches adoption in a Bitcoin upgrade, which requires broad consensus among developers, miners and users.

What happens next?

Sušánka urged developers to build migration options early, because moving potentially millions of users to new signature schemes will take considerable time. He said the transition may require compromises to make progress at all — a nod to the tension between optimal cryptography and shippable engineering.

For Trezor, the preparation is already visible. Defaulting to stateless signatures while burying the stateful option in advanced settings would trade a tenfold size penalty for a large reduction in catastrophic user error. That trade reflects a wider industry pattern: hardware wallet makers increasingly design for the weakest realistic user behavior rather than the strongest theoretical setting.

The timeline remains open-ended. Until a quantum-resistant signature proposal moves from draft to an actual Bitcoin soft fork or activation path, Trezor's plan stays a contingency — one that signals how wallet vendors expect the migration question to land on their desks well before consensus forms on-chain.