MarsBit has published a long-form market analysis by IOSG contributor 0xjacobzhao arguing that quantum computing should not be viewed as an instant doomsday switch for crypto networks, but as a slow-moving and systemic security stress test for the foundations of Web3. The article centers on Q-Day, defined as the point at which a fault-tolerant quantum computer becomes practically capable of breaking widely used public-key cryptography. In that framework, the core question is no longer whether post-quantum algorithms exist, but whether the crypto ecosystem can coordinate migration before quantum attacks become both technically and economically feasible.
Q-Day is framed as a shrinking security window rather than a single date
The analysis says Q-Day should be understood as a probability range, not a fixed day on the calendar. Its timing depends on hardware progress, quantum error correction, algorithmic optimization, and even the opacity of state-backed research programs. Most mainstream expectations still place the window around 2035 to 2045, while more aggressive scenarios compress that timeline into 2030 to 2035. Anything before 2030 is described as a low-probability tail risk, but not something the industry can dismiss outright.
That timeline matters because migration itself may take many years. The article highlights Mosca’s inequality, X + Y > Z, where X is how long data must remain secure, Y is how long migration takes, and Z is the time remaining before Q-Day. If the lifespan of sensitive data plus the transition period exceeds the remaining runway, then systems are already behind schedule. In crypto, where transaction history is permanently public and cannot be clawed back, “harvest now, decrypt later” is not a theoretical concern but an architectural vulnerability.
Shor and Grover create very different categories of risk
The piece separates the quantum threat into two broad classes. Shor’s algorithm is the existential one for public-key systems because it can undermine the mathematical assumptions behind RSA, elliptic-curve cryptography, and pairing-based schemes such as BLS. By contrast, Grover’s algorithm acts more like a quadratic speedup for brute force search against symmetric cryptography and hash functions. That still weakens security margins, but the standard response is relatively straightforward: increase key sizes, hash output lengths, or other security parameters.
From that perspective, the immediate blockchain problem is not primarily SHA-256 or RIPEMD-160. The article argues that the real fault lines run through account signatures, validator signatures, commitment schemes, and proof systems that still depend on elliptic curves or related public-key constructions. It also stresses that quantum risk will not arrive evenly. Instead, it is expected to propagate through five layers: assets, protocols, infrastructure, applications, and governance. In practice, exchanges, custodians, and bridges may face pressure earlier than base-layer protocols.
Post-quantum cryptography is presented as the main migration path
The report describes post-quantum cryptography, or PQC, as the most realistic and scalable route for digital infrastructure. Current implementation and standardization efforts are concentrated around two main families: lattice-based cryptography and hash-based signatures. On the lattice side, the article points to ML-KEM and ML-DSA as the leading standardized candidates, while SLH-DSA represents the conservative hash-based signature route. It also notes that code-based HQC was selected by NIST in March 2025 as a fifth PQC algorithm, intended as a non-lattice backup to ML-KEM.
On the standards front, the article cites NIST’s August 2024 publication of three core standards: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA. That package effectively set the baseline allocation of roles for post-quantum migration: one key encapsulation mechanism and two signature standards. But the piece argues that adoption cannot stop at standard names. Real deployment also requires hybrid modes, crypto-agility, secure hardware, and architectural flexibility so systems can replace or roll back algorithms if new weaknesses appear.
Bitcoin’s quantum exposure depends heavily on whether public keys are already visible
For Bitcoin, the article argues that risk is highly uneven and should not be generalized across all BTC. The highest-risk coins are those whose public keys are already permanently exposed on-chain. That includes early P2PK outputs, Taproot outputs under certain conditions, and reused addresses in P2PKH or P2WPKH formats that still retain balances. Once a cryptographically relevant fault-tolerant quantum computer exists, those exposed keys could in principle be targeted directly with Shor-style attacks to derive private keys and forge valid signatures.
By comparison, unspent and non-reused P2PKH or P2WPKH outputs currently reveal only public-key hashes. Their quantum exposure is narrower and tied more to the short interval between transaction broadcast and confirmation, where a “quantum frontrun” could become relevant. Coins that eventually migrate to post-quantum addresses would face significantly lower risk. Still, the article emphasizes that this is not a simple wallet-level patch. A viable Bitcoin migration would require synchronized adaptation across wallets, full nodes, miners, exchanges, custodians, and hardware wallet vendors.
Signature bloat and the soft-fork route are Bitcoin’s engineering constraints
The author says Bitcoin’s governance culture makes a clean hard-fork replacement of ECDSA or Schnorr politically difficult. A more plausible route would be a soft fork that introduces new quantum-safe output types. The article references ongoing discussions such as BIP-360 and P2MR, or Pay-to-Merkle-Root, while stressing that none of these are close to broad consensus or activation.
The engineering burden is even more concrete. Today’s ECDSA and Schnorr signatures are only about 64 to 72 bytes. Candidate post-quantum signatures are far larger: roughly 2.4 to 4.6 KB for ML-DSA and as much as 7 to 49 KB for SLH-DSA, according to the article. That increase would ripple through the entire system by raising block weight and transaction fees, increasing bandwidth and storage costs for nodes, worsening UTXO management, and degrading wallet user experience. In short, the migration mechanism itself creates friction that could slow adoption.
Legacy UTXOs create Bitcoin’s deepest governance conflict
Even if post-quantum addresses become available, the article says Bitcoin still faces the unresolved question of what to do with legacy UTXOs that never migrate, especially long-dormant coins often associated by the market with the Satoshi era. If the network does nothing, those coins may become a windfall for whichever actor first controls practical quantum attack capability. If the community instead forces a freeze or invalidation, it collides directly with the principles of immutability, property rights, and the long-standing “Not your keys, not your coins” ethos.
The author presents a more pragmatic middle path in the form of a multi-year legacy sunset process. That would involve repeated deprecation warnings, gradually higher relay friction for spending older signature types, and eventually some soft-fork-level restrictions after prolonged coordination. Discussions like BIP-361 and the idea of a legacy signature sunset are framed as early attempts to map this path. The conclusion is that Bitcoin’s post-quantum challenge is not fundamentally a cryptographic one. The algorithms exist. The bottleneck lies in legitimacy, governance, and whether the community will agree on when an asset should be considered quantum-insecure.
Ethereum is approaching the problem as a full-stack cryptographic redesign
Ethereum is portrayed as taking a more proactive stance. According to the article, the Ethereum Foundation’s post-quantum team, working through open processes such as All Core Devs, is not trying to bet the network on a single new signature scheme. Instead, its strategy is to maximize cryptographic agility, so that account authentication, validator signatures, data commitments, and proof systems can be replaced over time without destabilizing the network.
The piece identifies four major zones of Ethereum quantum risk: EOA accounts using ECDSA over secp256k1, validator consensus built around BLS signatures, data availability mechanisms tied to KZG commitments, and parts of the zero-knowledge proof stack. To address those risks, the Ethereum roadmap described in the article follows a “Lean” approach that advances execution-layer, consensus-layer, and data-layer migration tracks in parallel.
Execution, consensus, and data layers are all part of Ethereum’s migration plan
On the execution layer, account abstraction is described as the main buffer. Mechanisms such as ERC-4337 and EIP-7702 can give smart contract wallets more signature flexibility, enabling hybrid schemes and gradual migration rather than a single forced cutover for the network’s large base of EOAs. Layer 2 networks, with more flexible governance and faster iteration cycles, are also presented as natural testbeds for early post-quantum deployments.
On the consensus layer, the goal is to move away from pairing-dependent BLS signatures. The article points to a proposed combination of hash-based leanXMSS and a minimalist zkVM called leanVM for SNARK aggregation. One of the central engineering claims is that leanVM could compress the otherwise bulky post-quantum signature data by roughly 250x, helping Ethereum preserve some of the scalability advantages of signature aggregation even after shifting to quantum-resistant designs.
For the data layer, the report treats Blob data availability and KZG commitments as a deeper, longer-horizon restructuring challenge. Under a future fault-tolerant quantum regime, the assumptions behind KZG would need to be revisited, with the likely endpoint being more post-quantum-friendly commitments or proof systems, such as hash-based STARK constructions or lattice-based commitments. The article does not frame this as an immediate breakage event, but as a multi-year protocol overhaul.
Bitcoin and Ethereum face different endgames under the same quantum countdown
The analysis also compares other networks and design paths. Solana is cited as an example of a high-throughput chain exploring the engineering cost of post-quantum signature verification, with community discussion around Falcon-512 and FN-DSA verification syscalls, though the article stresses that these are exploratory and do not amount to an official migration strategy. Starknet and the STARK family are presented as more quantum-friendly on the proving side because their proof systems rely more heavily on hash-based assumptions than pairing-based SNARK systems, but they still inherit migration work at the wallet, bridge, parameter, and settlement layers.
Native or near-native post-quantum chains such as QRL, Quantus, and Abelian are described as useful clean-slate technical examples rather than direct replacements for BTC or ETH. They demonstrate what a chain designed from day one for post-quantum security can look like, whether via hash-based signatures, NIST-era PQC narratives, or lattice-based privacy designs. But the article notes that these networks remain far behind Bitcoin and Ethereum in network effects, liquidity, and application ecosystems.
In conclusion, the author argues that while the broad preparation period may still span 5 to 15 years, the comfortable engineering window is likely only 5 to 8 years. Market repricing may also arrive before Q-Day itself if quantum resource estimates keep falling, hardware timelines accelerate, or regulators and major custodians begin imposing PQC requirements. Under that scenario, Bitcoin’s defining challenge is governance over legacy assets and property rights, while Ethereum’s is the technical complexity of replacing cryptography across accounts, consensus, data availability, and zero-knowledge systems without disrupting the network. The article’s bottom line is that post-quantum migration is ultimately a problem of social coordination and systems engineering, not a simple matter of swapping one algorithm for another.