NewsCryptoJoseph Gabriel Mattia III Says Multisig Won’t Stop Quantum Attacks

Joseph Gabriel Mattia III Says Multisig Won’t Stop Quantum Attacks

Author: Metaverse Post·

Key Takeaways

  • Many cryptography experts now estimate Q-Day could arrive in the late 2020s, within roughly the next four years.
  • Mattia said a major stablecoin’s administrative key would be a more attractive quantum target than a visible Bitcoin wallet because it could affect an entire ecosystem.
  • He said quantum readiness requires publicly verifiable disclosure of where vulnerable cryptography still exists, including transaction authorization, P2P links, consensus systems, bridges, and privacy layers.
  • He noted that hardware wallets protect against physical theft but cannot stop quantum attacks on exposed public keys, and that wallet-level protection alone cannot make a network post-quantum.
  • All top 20 crypto assets tracked by migration.fail are currently listed as vulnerable at the signature level, according to the interview.
Joseph Gabriel Mattia III Says Multisig Won’t Stop Quantum Attacks

The cryptographic foundations of the internet were built for a world that no longer exists — or, more precisely, for a world that is quietly running out of time. Q-Day, the point at which a quantum computer becomes powerful enough to crack modern public-key encryption, is no longer a theoretical horizon. According to many veterans in cryptography, it is a late-2020s problem. That places it closer than most institutional roadmaps suggest, and much closer than the average crypto user has been led to expect. The mechanism at stake is Shor’s algorithm, published in 1994: a sufficiently large, error-corrected quantum machine could use it to derive the private keys behind RSA and elliptic-curve cryptography, the schemes that secure most internet traffic and virtually all of crypto. No computer that exists today can run the algorithm at that scale, which is why the debate among experts centers on the arrival date rather than the underlying math.

Joseph Gabriel Mattia III, COO of Quantus — the company integrating post-quantum cryptography into hardware wallet infrastructure — has been examining what that transition looks like at the protocol level, the custody level, and for the ordinary holder who learned everything they needed to know about security from a hardware wallet box. His answers are less reassuring than the industry’s current posture suggests they should be. A stablecoin’s administrative key worries him more than Satoshi’s wallet. Multisig, he argues, offers no meaningful resistance against a quantum attacker — only more locks of the same broken kind. And every major crypto asset tracked by migration.fail, a public readiness tracker, is currently listed as vulnerable at the signature level.

What follows is a conversation about the threat the industry is not yet taking seriously enough, why waiting for proof of concept may already be too late, and what quantum readiness actually has to look like — not as a marketing label, but as something verifiable, auditable, and built into the stack by default.

When do you estimate “Q-Day” will arrive — the threshold at which a quantum computer can break modern public-key cryptography? Which systems, data, assets, protocols, or infrastructure would adversaries target first? Why?

Most likely sometime in the late 2020s. There’s still debate over the exact year, but many cryptography veterans believe it will happen within the next four years.

As for the first targets, I don’t expect Satoshi’s Bitcoin to be one of them, even though that’s where people’s minds tend to go.

If an adversary had this capability, targeting something visible would announce it to the whole world and destroy a huge strategic advantage. They’d probably focus on keys that provide the most control or value while attracting as little attention as possible.

In crypto, something like a major stablecoin’s administrative key would worry me more. One compromised key could affect the entire ecosystem, which makes it a much bigger target than any single wallet.

Outside crypto, I’d look at classified government communications, military networks, and intelligence systems, where breaking public-key cryptography could expose highly sensitive data.

Many projects today claim “quantum resistance,” yet without a unified, auditable checklist, such assertions are impossible to verify. In your view, what constitutes the minimum threshold of quantum readiness?

For me, the minimum threshold is that a project should be able to show exactly where quantum-vulnerable cryptography still exists in its stack. Using a post-quantum-secure authorization mechanism is a good start, but it does not make the entire network quantum-ready.

Transaction authorization should rely on a recognized post-quantum-secure mechanism, and the project should publicly document what protects its P2P connections, consensus, zero-knowledge systems, privacy layer, bridges, and any other critical infrastructure.

There also needs to be a clear distinction between what is live today and what is only on a roadmap.

Most importantly, those claims need to be auditable. Anyone should be able to see which algorithms and parameter sets are being used, inspect the implementation, and verify that the security is not based on an opaque or unverifiable scheme or a marketing label.

If you can’t point to the exact cryptography protecting each critical part of the system, I don’t think “quantum-ready” means very much.

Who should be responsible for establishing unified, verifiable criteria for quantum readiness? What must be included in them?

I’d keep NIST as the reference point for the cryptography itself. Their post-quantum process brought in researchers from around the world and made it hard for any one government or company to steer the outcome. That process — an open, multi-year competition launched in 2016 — produced its first finalized standards in August 2024: ML-KEM for key establishment, alongside the ML-DSA and SLH-DSA signature schemes.

For blockchains, the next layer must be built by protocol teams operating in the open, with room for researchers and auditors to rigorously challenge the design and its outcomes.

The criteria then need to reflect how the network operates today. That starts with the cryptography used to authorize transactions and with whether post-quantum protection is the default. Any remaining reliance on vulnerable signatures needs to be clearly disclosed.

Migration has to be part of that picture too, because a network can support post-quantum keys while most of its users are still sitting on old ones.

Hardware wallets protect keys against physical theft, but not against quantum attacks on public keys. How do you assess current user awareness of this distinction? Is there a secure storage model available to the average user today, or does the industry require a new wallet paradigm?

There is still a big misconception around what a hardware wallet protects you from. It keeps your private key isolated from your laptop or phone, which is extremely useful. But a quantum attacker would not need to touch the device. Once a vulnerable public key is exposed, a quantum attacker can go after the cryptography directly without ever touching the hardware wallet.

That does not make hardware wallets obsolete. We have already integrated post-quantum support into Keystone for Quantus, so the hardware model can evolve. The limitation is that a wallet cannot make Bitcoin or Ethereum post-quantum on its own — the underlying network has to support new signatures too.

A better model builds post-quantum protection into both the wallet and the network by default. Users should not have to know when the cryptography underneath them has become outdated.

Multisignature schemes increase attack complexity only linearly, not exponentially. Does this mean that institutional custody architectures built on multisig create a false sense of security?

Multisig is still extremely useful, and I would not want institutions to abandon it. It protects against the threats custody systems deal with today, like one stolen key or one compromised signer.

Where it becomes dangerous is when people start treating more keys as protection against quantum attacks. A 3-of-5 setup built entirely on the same vulnerable signature scheme still has the same underlying weakness. A quantum attacker may need to recover several keys, but they are solving the same kind of problem each time. Five locks do not help much if they all share the same vulnerable mechanism.

So yes, multisig can create a false sense of security if institutions assume redundancy equals quantum resistance. The better path is to keep distributed custody, but replace the vulnerable authorization underneath it with something that can hold up against a quantum attacker.

Are major exchanges and custodians prepared for a scenario in which a quantum computer can derive a private key from a public key in minutes? What about ordinary users?

Most major exchanges are good at defending against the attacks we know today. I have not seen much evidence that they are ready for an attack where a private key can be reconstructed without touching their infrastructure at all.

We track this via migration.fail, a public readiness tracker that assesses whether major blockchain networks still rely on quantum-vulnerable cryptography. Right now, all of the top 20 crypto assets it covers are listed as vulnerable at the signature level.

A serious response plan needs to account for which operational keys are exposed and how quickly funds could be moved once one becomes suspect. A malicious transaction may still look perfectly valid on-chain, which makes an early response harder.

Ordinary users are further behind. Most will only learn they need to migrate when a wallet or exchange tells them, so any realistic plan has to make that move simple enough to complete safely.

Why is the “harvest now, decrypt later” threat relevant today — long before the arrival of large-scale quantum computers?

First, I would separate this from the quantum threat to blockchain signatures, because they are often lumped together. A Bitcoin transaction is already public. There is nothing an attacker needs to record today and decrypt ten years from now.

But that cannot be said for banks, governments, and other institutions whose encrypted data may — and probably will — still be sensitive years from now. Someone can collect that traffic today and hold onto it until the technology catches up.

Signal, iMessage, and Cloudflare have already moved parts of their systems to post-quantum protection — Signal turned on post-quantum key agreement for new chats in 2023, Apple rolled out its PQ3 protocol across iMessage in 2024, and Cloudflare has enabled hybrid post-quantum key agreement across its network — and most users barely noticed. That is probably how this transition should look.

Sensitive data should not stay on quantum-vulnerable encryption until someone proves a quantum computer can break it. By then, years of traffic may already be sitting in someone else’s archive.

Blockchain data is immutable and public. Is there anything that can be done about already recorded transactions, or is that data compromised forever?

Recorded blockchain data is permanent, but permanence does not mean every old transaction suddenly becomes dangerous after Q-Day. Most of it was already public on a transparent chain anyway.

Public keys are the exception because Bitcoin already records exposed ones permanently. Standard Bitcoin addresses publish only a hash of the public key until coins are spent from them, but the network’s earliest pay-to-public-key outputs — and every reused or already-spent address — display the public key outright. An attacker does not need to build some private archive today or intercept anything in advance. Years from now, they can go back through the same public ledger and target any exposed key that still controls something valuable.

Moving funds to post-quantum keys can remove the value from that old exposure, but it cannot clean up the historical record.

For private transactions, the problem is a little different. The data is still sitting on-chain years later, so if the cryptography protecting it is eventually broken, information that was hidden at the time could become visible after the fact.

What measurable, enforceable standards of quantum readiness should the industry establish within the next 12 to 24 months?

One useful benchmark is what the U.S. government is doing now, with federal agencies required to map their cryptographic exposure and put specific people in charge of the migration. Those requirements trace to National Security Memorandum 10 and follow-on budget-office guidance, and NIST’s draft transition plan proposes deprecating RSA-2048 and elliptic-curve cryptography by 2030 and disallowing them entirely by 2035. High-value systems have firm deadlines to migrate to post-quantum cryptography, and work is underway on a cryptographic bill of materials to make those dependencies easier to track.

Crypto needs its own version of that discipline over the next 12 to 24 months. Major protocols should publish where vulnerable cryptography is still in use and attach dates for completing the transition away from it. Exchanges and custodians should disclose how much value is held behind legacy keys.

Once those numbers are public, listing reviews and security audits can start using them too. That gives the industry something concrete to measure.

What is the single greatest obstacle to implementing those standards at scale? How should the industry address it in the immediate term?

The hardest part is getting millions of independent holders to move when there is no central switch anyone can flip. A protocol can add post-quantum support, but coins held in cold storage for years still have to be moved by their owners.

Immediate work must focus on making the migration as simple as possible. Wallets need flows that guide users onto safer keys with minimal friction, while exchanges and custodians need procedures they have already tested under load. At the protocol level, we also have to avoid simply replacing one vulnerable system with something that creates unacceptable bandwidth, storage, or privacy costs. That constraint is not abstract: NIST’s ML-DSA signatures run to a few kilobytes, dozens of times the size of the 64-to-72-byte elliptic-curve signatures common on blockchains today, and hash-based alternatives carry their own signature-size and state-handling trade-offs. Waiting to design those systems until the threat feels urgent would leave little room for mistakes.

Dormant assets make the problem even harder. Some owners will never show up to migrate, so networks also need to decide how they handle vulnerable coins that remain behind.