Is Usual Quantum Safe?
Is Usual quantum safe? It's a question that matters more each year as quantum computing hardware edges closer to practical threat thresholds. Usual (USUAL) is an EVM-based stablecoin protocol that, like every Ethereum-native token, relies on the Elliptic Curve Digital Signature Algorithm (ECDSA) to authorise transactions and secure wallets. This article breaks down exactly what that means for USUAL holders, when the threat becomes real, what Usual's development team has said about migration, and how lattice-based post-quantum cryptography differs from the standard Ethereum stack.
What Cryptography Does Usual Currently Use?
Usual is deployed on Ethereum mainnet. That single fact determines its entire cryptographic posture, because Ethereum's protocol layer mandates the signing scheme used for every transaction on the network.
ECDSA on the secp256k1 Curve
Every Ethereum account, including those holding USUAL tokens or interacting with Usual's USD0 stablecoin contracts, uses ECDSA over the secp256k1 elliptic curve. When you sign a transaction, your private key generates a signature that any node can verify against your public key without ever learning the private key itself. The security rests on the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP): deriving a private key from a public key is computationally infeasible for classical computers.
Usual's smart contracts also inherit Ethereum's broader cryptographic stack:
- Keccak-256 hashing for address derivation and storage slot computation
- EIP-712 structured signing for permit-style approvals, which is still ECDSA underneath
- ABI-encoded calldata verified on-chain using standard EVM opcodes
None of these components were designed with quantum adversaries in mind. They were designed to resist classical computers, which is a fundamentally different threat model.
Why the Smart Contracts Themselves Are a Secondary Concern
A common misconception is that "quantum-proofing" a DeFi protocol means auditing its smart contract logic. In reality, Solidity bytecode running on the EVM is not directly threatened by quantum algorithms. The threat is narrower and more specific: a sufficiently powerful quantum computer running Shor's algorithm can derive an ECDSA private key from its corresponding public key. That means the attack surface is user wallets and EOA (externally owned account) signatures, not the contract bytecode itself.
If an attacker could forge a valid ECDSA signature for any wallet holding USUAL, they could drain that wallet's tokens without knowing the seed phrase. The protocol's audit history, governance design, or collateral model becomes irrelevant once the signing layer is compromised.
---
Understanding Q-Day and Shor's Algorithm
Q-Day is the colloquial term for the future date when quantum computers can run Shor's algorithm at scale against real-world cryptographic keys. Shor's algorithm, published in 1994, reduces the time to solve ECDLP from exponential (classical) to polynomial (quantum), meaning a large enough quantum computer could crack a 256-bit elliptic curve key in hours or minutes rather than billions of years.
Current Quantum Hardware vs. the Threat Threshold
Breaking secp256k1 at the 128-bit security level is estimated to require roughly 2,000 to 4,000 logical qubits running fault-tolerant circuits. As of mid-2025:
| Quantum System | Logical / Physical Qubits | Est. ECDSA Threat Capability |
|---|---|---|
| IBM Condor (2023) | ~1,121 physical (noisy) | None — NISQ era, high error rate |
| Google Willow (2024) | ~105 logical-equivalent | None — below threshold |
| Microsoft / Quantinuum targets | Roadmap to 1,000+ logical | Emerging but not imminent |
| Theoretical fault-tolerant requirement | ~2,000–4,000 logical | Sufficient to break secp256k1 |
The gap between today's hardware and the threat threshold is meaningful but closing. Cryptographers broadly agree that "harvest now, decrypt later" (HNDL) attacks are already rational. Adversaries record encrypted data or signed transactions today and decrypt them once quantum hardware matures. For blockchain, this translates to collecting public keys from on-chain transaction history and deriving private keys retroactively.
Which Wallets Are Most Exposed?
Not all Ethereum wallets carry the same quantum exposure. The risk profile depends on whether a public key has been revealed on-chain:
- Wallets that have never sent a transaction reveal only their address (a Keccak-256 hash of the public key). The public key is not directly visible. Quantum attackers would first need to invert the hash function, which even Grover's algorithm only weakens to ~128-bit equivalent security. This is still considered manageable with longer hashes.
- Wallets that have sent at least one transaction expose their full public key in the transaction signature. These are the primary ECDSA targets for Shor's algorithm.
- Contract wallets (ERC-4337 smart accounts) may use different verification logic but ultimately still rely on ECDSA-signed UserOperations in most current implementations.
USUAL holders who regularly interact with the protocol, claim rewards, or move tokens between addresses fall squarely into category two. Their public keys are permanently recorded on-chain.
---
Has Usual Published Any Quantum Migration Roadmap?
As of mid-2025, Usual's public documentation, governance forum, and GitHub repositories contain no formal post-quantum cryptography (PQC) migration plan. This is not unusual (no pun intended) for EVM-native DeFi protocols. The absence reflects a broader industry dynamic: most Ethereum projects are deferring PQC migration to the protocol layer, waiting for Ethereum core developers to implement quantum-resistant signing at the network level.
Ethereum's Own PQC Timeline
Ethereum's long-term roadmap does include quantum resistance. Vitalik Buterin and other researchers have discussed:
- EIP proposals for STARK-based transaction validity as a stepping stone to PQC-friendly account abstraction
- Stateless client work that could accommodate alternative signature schemes
- EIP-7560 (native account abstraction) which opens the door to plugging in lattice-based signature schemes at the account level
However, none of these are scheduled for imminent mainnet deployment, and a full ECDSA-to-PQC migration for existing EOAs would require unprecedented coordination across wallets, exchanges, and protocols.
The practical implication for Usual holders: PQC migration for USUAL is entirely dependent on Ethereum's timeline, not Usual's own development team. Usual cannot unilaterally change the signing scheme used to control wallets holding its tokens.
---
Lattice-Based Post-Quantum Cryptography: How It Differs
Post-quantum cryptography encompasses several mathematical families, each with different performance and security trade-offs. The NIST PQC standardisation process, which concluded its primary selections in 2024, settled on lattice-based schemes as the primary recommendation.
NIST-Selected PQC Standards
| Standard | Type | Primary Use | Security Basis |
|---|---|---|---|
| ML-KEM (CRYSTALS-Kyber) | Key Encapsulation | Key exchange | Module Learning With Errors (MLWE) |
| ML-DSA (CRYSTALS-Dilithium) | Digital Signature | Transaction signing | Module Learning With Errors |
| SLH-DSA (SPHINCS+) | Digital Signature | Transaction signing | Hash-based (stateless) |
| FN-DSA (FALCON) | Digital Signature | Compact signatures | NTRU lattice |
For blockchain wallets, the relevant standards are the digital signature schemes: ML-DSA, SLH-DSA, and FN-DSA. These replace ECDSA in the signing pipeline.
Why Lattice Problems Resist Quantum Attacks
Shor's algorithm exploits the mathematical structure of discrete logarithm and integer factorisation problems. Lattice problems, specifically the Shortest Vector Problem (SVP) and Learning With Errors (LWE), have no known efficient quantum algorithm. Even with a fault-tolerant quantum computer, solving LWE at cryptographic parameter sizes is believed to require exponential time, preserving the security guarantee that ECDSA loses against quantum adversaries.
The trade-offs are real:
- Signature size: ML-DSA signatures are roughly 2,400–3,300 bytes vs. ECDSA's 64–72 bytes. This increases on-chain calldata costs.
- Key size: Public keys are larger, adding storage overhead.
- Computation: Lattice operations are more CPU-intensive, though still fast on modern hardware.
For a purpose-built post-quantum wallet, these trade-offs are acceptable design parameters. For retrofitting an existing EVM chain, they represent significant engineering work.
---
Practical Risk Assessment for USUAL Holders
Short-Term (2025–2028)
Quantum hardware is not yet a credible threat to secp256k1. The near-term risks for USUAL holders are conventional: smart contract vulnerabilities, oracle manipulation, and collateral concentration in USD0's backing. Quantum attack is not a realistic near-term concern.
Medium-Term (2028–2033)
This window carries the most uncertainty. Quantum hardware scaling is non-linear, and cryptographically relevant quantum computers could emerge faster than current roadmaps suggest. HNDL attacks during this period mean that public keys already exposed on-chain are being catalogued now. Holdings in wallets with exposed public keys accumulate quantum risk over time even before a practical attack is feasible.
Long-Term (2033+)
If Ethereum has not completed a PQC migration and quantum hardware has crossed the threshold, wallets with exposed public keys become vulnerable. USUAL tokens, like all ERC-20 balances controlled by standard EOAs, would be at risk of unauthorised transfers by any party with access to a sufficiently powerful quantum computer.
Mitigation Options Available to Holders Today
Waiting for protocol-level fixes is one strategy, but holders can take steps independently:
- Use a wallet that has never sent a transaction and move holdings there. The public key remains hidden until you next sign a transaction.
- Monitor Ethereum's PQC EIPs and migrate to ERC-4337 smart accounts with PQC-compatible validation modules as they become available.
- Segment holdings: keep large balances in "cold" addresses that have never broadcast a transaction signature.
- Adopt dedicated post-quantum wallets where available. Projects like BMIC.ai are building wallets designed around NIST PQC-aligned lattice cryptography from the ground up, rather than retrofitting existing ECDSA infrastructure.
---
What Would a Real Quantum Migration for Usual Look Like?
If Ethereum adopts a PQC-compatible signing scheme, the migration path for USUAL holders would involve several steps:
- Ethereum network upgrade introduces a new transaction type supporting ML-DSA or equivalent signatures.
- Wallet software updates generate fresh lattice-based key pairs.
- Users create new PQC accounts and transfer USUAL balances from old ECDSA accounts to new PQC accounts in a time-bounded migration window.
- Protocol governance may need to whitelist new account types for reward accrual, staking, or voting if those functions gate on address identity.
- Old ECDSA accounts are sunset or restricted to receive-only once the migration window closes.
This process is manageable but requires broad coordination. Exchanges must support new address formats. Hardware wallets must update firmware. DeFi protocols, including Usual, must ensure their contracts interact correctly with both account types during transition.
The complexity underscores why proactive planning at the infrastructure level, rather than reactive migration under time pressure, is the preferred approach among cryptographers.
---
Summary
Usual (USUAL) is not quantum safe in its current form, nor is any other EVM-native protocol running on standard ECDSA-secured Ethereum wallets. The threat is not imminent given today's quantum hardware, but the cryptographic exposure is structural and well-understood. Holders with public keys already exposed on-chain are accumulating long-term quantum risk with each passing year. Usual has no independent PQC roadmap; its quantum posture is entirely a function of Ethereum's own upgrade timeline. For holders who treat quantum risk as a portfolio consideration worth managing now rather than later, the options range from disciplined cold wallet hygiene to adopting infrastructure built on post-quantum cryptographic primitives from inception.
Frequently Asked Questions
Is Usual (USUAL) quantum safe?
No. Usual is an EVM-native protocol and relies on Ethereum's standard ECDSA secp256k1 signing scheme. ECDSA is vulnerable to Shor's algorithm running on a sufficiently large fault-tolerant quantum computer. Usual has not published an independent post-quantum migration roadmap.
When does quantum computing become a real threat to USUAL holders?
Cryptographers broadly estimate that breaking 256-bit elliptic curve keys requires 2,000 to 4,000 logical fault-tolerant qubits. Current hardware is well below this threshold, making the threat medium-term rather than immediate. However, 'harvest now, decrypt later' attacks mean exposed public keys are at risk retroactively once the threshold is crossed.
Which USUAL wallets are most exposed to quantum attacks?
Wallets that have sent at least one transaction expose their full ECDSA public key on-chain, making them the primary target for Shor's algorithm. Wallets that have never sent a transaction reveal only a Keccak-256 hash of the public key, which provides some additional protection, though not indefinite security.
What is lattice-based post-quantum cryptography and how does it differ from ECDSA?
Lattice-based schemes like ML-DSA (CRYSTALS-Dilithium) and FN-DSA (FALCON) base their security on mathematical problems such as Learning With Errors, for which no efficient quantum algorithm is known. Unlike ECDSA, their security does not collapse under Shor's algorithm. The trade-off is larger signature and key sizes compared to ECDSA.
Can Usual's development team independently make the protocol quantum safe?
Not in a fundamental sense. Because the signing scheme is enforced at the Ethereum protocol layer, Usual cannot unilaterally change how user wallets authenticate transactions. A full PQC transition requires Ethereum network upgrades, wallet software updates, and broad ecosystem coordination.
What can USUAL holders do right now to reduce quantum risk?
Practical steps include: keeping large holdings in wallet addresses that have never broadcast a transaction (hiding the public key), monitoring Ethereum PQC EIPs for smart account migration paths, and considering dedicated post-quantum wallet infrastructure built on NIST PQC-aligned cryptography for long-term storage of significant holdings.