Crypto-Agility for Digital Assets: Chains Are Planning One Post-Quantum Change When They Will Need Several

On May 29, 2026, Taylor Hornby, a security researcher auditing Zcash under contract to Shielded Labs, found a flaw in Orchard, the shielded pool at the center of Zcash’s privacy design. He reported it to the Zcash Open Development Lab (ZODL). A missing constraint in the circuit’s scalar-multiplication code let a malicious prover generate valid proofs for Orchard actions that should have been rejected. An attacker could have used it to mint unlimited ZEC, Zcash’s coin, inside the pool without detection. The bug had been present since Orchard launched in May 2022.

Zcash’s developers disabled Orchard with an emergency soft fork that activated at block 3,363,426 early on June 2 (UTC). On June 3 they restored it with a corrected circuit in network upgrade NU6.2, a hard fork that activated at block 3,364,600. ZEC’s price fell by about half after the disclosure, according to the Grayscale Zcash ETF’s SEC filing, and it had largely recovered by the time of that filing in late August. Orchard hides amounts and addresses, so nobody can prove the flaw was never exploited. On July 28, Zcash sealed Orchard and opened a new pool called Ironwood with its NU6.3 upgrade. Orchard then contained about 3.66 million ZEC. Coins can leave it only through a turnstile that caps withdrawals at the value verifiably deposited. Zcash changed its cryptography on mainnet twice in 60 days, first with a corrected circuit and then with a new pool, and no quantum computer was involved.

In most post-quantum proposals for Bitcoin and Ethereum, the change is a single move off elliptic curves. BIP-360, the Bitcoin Improvement Proposal for a new output type called Pay-to-Merkle-Root (P2MR), was merged as a draft on February 11 and has no activation date. P2MR removes the key-path spend that exposes a public key in Taproot outputs; it chooses no post-quantum signature scheme. The Ethereum Foundation’s Protocol cluster has committed to a quantum-resistant layer 1 by December 2029. On a shared ledger, crypto-agility has two halves. A chain can add a new signature algorithm in one upgrade. Retiring the old algorithm is harder. As long as a large share of coins still depends on it, a break of the old algorithm threatens the value of every coin on the chain, migrated or not, and ending that exposure means deciding what happens to coins whose owners never move them. Neither Bitcoin nor Ethereum has adopted a rule for that, although both now have draft plans for parts of it.

In my October 3 article, I argued that organizations should fund the ability to change cryptography on a date they choose, and treat the PQC migration as that capability’s first test. Here I apply the same argument to public blockchains and to the exchanges, custodians and funds that depend on them. Unless I say otherwise, every proposal below is a draft or a mailing-list design, and every status is as of early October 2026.

Six Reasons Chains Will Change Their Cryptography Again

My October article gave six reasons why organizations will change algorithms again. All six apply to public blockchains, where responding to most of them requires a consensus change.

Cryptanalysis of New Signature Schemes

Every post-quantum signature scheme proposed for Bitcoin or Ethereum is younger than secp256k1, the curve that has secured Bitcoin since 2009. NIST published ML-DSA (formerly CRYSTALS-Dilithium) and SLH-DSA (formerly SPHINCS+) in August 2024. FN-DSA (formerly Falcon) is still being standardized as FIPS 206. SHRINCS, the hash-based scheme Blockstream researchers designed for Bitcoin, reached a draft BIP in August, and its formal security proof is still pending.

New candidates have been broken quickly before. Wouter Castryck and Thomas Decru broke SIKE, a key-encapsulation candidate, 25 days after NIST advanced it in 2022. The designers of HAWK, a signature candidate in NIST’s additional process, withdrew it on July 29, 2026, a day after an AI-assisted attack on it went public.

On a chain, a signature scheme has to protect outputs that may go untouched for decades. Mikhail Kudinov, a Blockstream researcher who co-designed SHRINCS, compared Bitcoin with Cloudflare on February 27, in a Bitcoin development mailing-list discussion of algorithm agility. Cloudflare settled for ML-DSA-44 partly because it can reissue certificates if attacks improve, he pointed out, and Bitcoin cannot switch parameters so easily. He concluded that a lattice scheme for Bitcoin needs a larger security margin. At that margin, public key and signature together take at least 3,073 bytes for Falcon at NIST level 5 and 5,261 bytes for ML-DSA at level 3. A chain that cannot change its algorithm easily has to choose larger parameters from the start, and on Bitcoin every extra byte reduces the number of transactions that fit in a block.

Faster Cryptanalysis With AI Tools

Hornby found the Orchard flaw during an audit in which he used Anthropic’s Claude Opus 4.8, released the day before, for a targeted review of the circuit, according to the Shielded Labs disclosure he co-wrote. With the model’s help, he also wrote an exploit that minted counterfeit ZEC in a local test environment. In July, Anthropic disclosed that Claude Mythos Preview, in a research setup run by Zygimantas Straznickas and Stephen Weis, had found the symmetry behind the attack that led to HAWK’s withdrawal. The same disclosure reported a less-than-tenfold improvement against Poseidon, a hash that was then part of the Ethereum Foundation’s post-quantum roadmap.

When Ethan Heilman, one of BIP-360’s authors, proposed algorithm agility for Bitcoin in February, he listed an unexpected AI-driven breakthrough in mathematics among the risks he was designing against.

Implementation Flaws in Circuits, Verifiers and Libraries

The Orchard flaw was an implementation error in halo2_gadgets, a library that supplies circuit components, and not a flaw in the Halo 2 proof system itself. In March, OtterSec, a blockchain security firm, disclosed the same Fiat-Shamir transcript-binding failure in six separate zero-knowledge virtual machine (zkVM) codebases. Bitcoin Core verifies signatures with one library, libsecp256k1. Post-quantum projects already reuse one another’s code. The KyberSlash timing flaws were in the official reference code for Kyber, the algorithm NIST standardized as ML-KEM, and in several libraries that had copied it.

Some bugs in node software can be fixed quickly. Bitcoin Core patched CVE-2018-17144, a consensus-critical validation bug, within days in 2018, because the fix restored the rules the software was meant to enforce. A flaw in something the consensus rules themselves verify, such as a proof circuit, takes a consensus change to fix, and a flaw that leaks keys requires every affected holder to move coins.

National Algorithm Choices on Global Ledgers

China is selecting its own post-quantum algorithms in its NGCC competition, South Korea chose four of its own in January 2025, and European agencies differ on hybrid deployment. A national regulator can require an exchange to change what it runs in its own systems. A public ledger runs one set of algorithms for every holder in every country, and a regulated exchange in Seoul cannot make Bitcoin verify a Korean signature scheme. I found no discussion of how national algorithm requirements would apply to globally shared ledgers in Bitcoin’s or Ethereum’s proposal processes.

Deprecation Schedules

NIST’s draft transition schedule proposes deprecating today’s quantum-vulnerable public-key algorithms at 112-bit security after 2030 and disallowing all of them after 2035. It is written for US federal agencies and their suppliers. No authority can impose a schedule like it on a public chain’s consensus rules. Regulators can still place obligations on the regulated firms that hold coins on a chain, as the EU already has.

The Ethereum Foundation’s Protocol cluster has set its own date, December 2029, and will reassess it with outside experts in January 2027. On a chain, a deprecation date takes effect only through a consensus change, and its authors have to specify what happens to coins whose owners do not act.

Quantum Computing

Quantum computing is the only one of the six reasons that depends on a machine being built. In March, Google Quantum AI estimated an attack on 256-bit elliptic curves at 1,200 to 1,450 logical qubits on fewer than 500,000 physical superconducting qubits. A full run would take 18 to 23 minutes depending on the variant, or 9 to 12 minutes from a primed state. IonQ’s September paper compiled the secp256k1 attack to 1,457 logical qubits on a modeled trapped-ion machine of 19,397 physical ions, at 25.7 days per attempt with an estimated 63% chance of success. In July, Luo and colleagues narrowed the circuit to 835 logical qubits at the cost of more gates. Nobody has built a fault-tolerant machine capable of these attacks.

A cryptographically relevant quantum computer of that kind could derive the private key behind any exposed public key on the attacked curve and forge the signatures that every node accepts. I call that risk Trust Now, Forge Later (TNFL). The Ethereum Foundation’s Protocol cluster plans for attacks as early as 2030 and calls that assumption deliberately aggressive.

How Long a Cryptographic Change Takes on a Public Chain

In my October article I defined time-to-change as the time an organization needs to assess its exposure, decide, change and verify. Public chains have a record of their own, which I assembled from public dates:

The fast entries were coordinated emergency responses: a small group of developers wrote the rule change, the network adopted it within days, and holders then moved at their own pace. IOTA’s users had to upgrade their wallets and move tokens to new addresses around the fork. On October 2, about 377,500 ZEC, roughly a tenth of what was sealed in Orchard, had still not left it, according to ZODL’s migration tracker. The slowest entries, SegWit, Taproot and BIP-360, are all planned changes to the rules Bitcoin’s nodes enforce.

Five things make a planned cryptographic change on a public chain slow:

• Consensus. Bitcoin’s recent rule changes have been soft forks, activated through miner signaling and node upgrades. A soft fork tightens validation, so nodes running older software still accept the new blocks. Ethereum uses hard forks, which those nodes would reject, so every client and node operator has to upgrade before activation. In the Digital Assets Extension of my PQC Migration Framework, I track four populations on four schedules: activation, enforcement by validating nodes, support in signers and adoption in wallets.
• Holder action. Only whoever controls the private key can move coins to a new output type. About 1.7 million BTC are in early pay-to-public-key outputs that have not moved since they were created.
• Published keys. Pay-to-public-key outputs, Taproot outputs and reused addresses expose public keys on the ledger permanently.
• Backups. BIP-32 key derivation, which most wallets have used since 2012 to derive keys from a seed, depends on secp256k1. A new signature algorithm therefore requires new wallet standards for deriving and backing up keys.
• Block space. A Schnorr signature is 64 bytes. Counting signature bytes alone, FN-DSA-512 at 666 bytes is about 10 times larger, ML-DSA-44 at 2,420 bytes about 38 times and SLH-DSA-SHA2-128s at 7,856 bytes about 123 times. Blockstream’s model puts Bitcoin’s throughput at about 6.5 transactions per second with Schnorr signatures only, roughly half a transaction per second with ML-DSA at NIST level 3, and 0.36 with SLH-DSA. A team at Tectonic Labs found the same bottleneck on a chain compatible with the Ethereum Virtual Machine (EVM), where block size, not computation, limited post-quantum throughput.

Marin’s Law states that the effort required to change cryptography in a system is inversely proportional to the agility built into that system from the start. By that measure, Bitcoin is slow by design, and Kudinov’s argument for wider margins shows what the slowness costs in block space.

Adding a Second Signature Algorithm

This year, Ethan Heilman for Bitcoin, James Kempton for Ethereum and a team at Tectonic Labs have each proposed treating agility as a design goal in its own right. Ethereum has also scheduled a mechanism that delivers part of it.

Heilman’s Everyday and Backup Signatures for Bitcoin

Ethan Heilman, a cryptographer who now works at Cloudflare, is one of BIP-360’s three authors, with Hunter Beast and Isabel Foxen Duke. In 2017 he was among the researchers who found collisions in Curl-P, the signature hash IOTA then replaced. On February 9, on the Delving Bitcoin forum, he proposed building algorithm agility into Bitcoin. He cited the IETF’s RFC 7696, which tells protocol designers to expect advances in computing or cryptanalysis to make any algorithm obsolete eventually. He set the goal at one human lifetime: a holder should be able to bury a seed phrase in a coffee can and spend the coins 75 years later. In the same post, he wrote that he was confident in Bitcoin’s current algorithms and knew of no immediate threat to them.

His design gives Bitcoin two signature algorithms, each with its own CHECKSIG opcode, the Script instruction that verifies a signature. The two are placed in separate leaves of a BIP-360 output, and each leaf is an alternative way to spend the coins. The first algorithm is efficient and used for every spend, and today that would be Schnorr. The second is expensive and conservative, SLH-DSA-SHA2-128s in his example, and exists only to move coins to a new everyday algorithm if the first one breaks. If the replacement, chosen in haste, also fails, the backup still works.

An unused backup leaf adds 32 bytes to a spend’s witness data. An SLH-DSA signature runs to about 8 KB and would get no witness discount beyond the existing one. Holders would pay that cost only when nothing else is safe, and Heilman counts this as a feature. The design assumes that holders never reuse a key and that the everyday public key stays unexposed until the coins are spent. It offers no protection if both algorithms break at once, so the two must be based on different mathematical assumptions.

Heilman named the two roles “everyday” and “backup” algorithms on February 10, replying to Jonas Nick, a Blockstream researcher, in the Bitcoin development mailing-list discussion of algorithm agility. If everyday algorithms need replacing about every 40 years, he wrote, backup signatures will be a tiny share of all signatures. In his view, the likeliest user of a backup signature is an estate moving coins that nobody has touched for decades. Nick had argued that the cost of verifying signatures across the network should count for more in the design than existing support for a standardized scheme. He favored more efficient hash-based schemes.

Brandon Black suggested letting users build their own backup scripts, so that algorithms could change without further soft forks. Heilman liked the idea of moving between algorithms without a fork but wanted a vetted standard, because a recovery agent working for an estate must be able to rebuild the backup script from the seed phrase alone.

Deploying Heilman’s proposal would require an activated BIP-360, a new CHECKSIG opcode for SLH-DSA and wallet standards to replace BIP-32 extended public keys. None of the three exists yet. In March, the Bitcoin Optech newsletter summarized the agility discussion as reaching “no firm conclusions” on how Bitcoin could move from one cryptosystem to another.

The most concrete step since then is a specification. In late August, Nick published a draft BIP for SHRINCS, a hash-based scheme he designed with Kudinov that pairs a compact stateful signing path with a stateless fallback under one public key. The SHRINCS Working Group, which includes Heilman, specifies only the cryptography. Deploying SHRINCS would need at least one new output type and a separate BIP. Nick described SHRINCS as “not intended to be Bitcoin’s ‘final’ signature scheme.” As I noted in June, one P2MR output can contain ML-DSA, SHRINCS and SLH-DSA leaves together, the structure Heilman proposed for his everyday and backup algorithms.

Ethereum’s Declined Signature Registry and Scheduled Frame Transactions

James Kempton’s Ethereum Improvement Proposal EIP-7932 would have created one registry and one interface for additional signature algorithms, with each new algorithm specified in its own EIP. Ethereum’s developers declined it for the Glamsterdam upgrade, along with EIP-8051, a precompiled contract for ML-DSA verification. In a February post on the Ethereum Magicians forum, Kempton compared the field of post-quantum transaction proposals to Tokyo’s Shibuya Crossing, with too many proposals doing the same thing in different ways, and asked how to stop his registry from becoming one more competing pathway. One reply described the underlying problem as crypto-agility, which is broader than the post-quantum migration itself.

Other drafts propose different mechanisms. EIP-8202 would add each new signature scheme as a new identifier inside one transaction envelope, and EIP-8164 would let an account permanently replace its secp256k1 key with an ML-DSA-44 key, with room for later schemes.

The mechanism Ethereum has scheduled is EIP-8141, Frame Transactions, a design for native account abstraction, in which the rules for authorizing an account’s transactions are written in the account’s own code. Its authors describe it as “a native off-ramp” from elliptic-curve authentication. On September 7, the Protocol cluster graded it S-tier, its must-ship grade, for Hegotá, the upgrade after Glamsterdam, and core developers list it as scheduled for inclusion in EIP-8081, the Hegotá meta-EIP, which is the last status before mainnet in Ethereum’s process and still carries no activation date. EIP-8141 defines three signature schemes, two that the protocol verifies itself (secp256k1 and P-256) and an arbitrary scheme whose signature the account’s own contract code checks. It reserves identifiers 3 through 255 for later schemes.

Smart-contract wallets can already verify custom signatures under ERC-4337. Through the arbitrary scheme, an account could use a post-quantum algorithm natively by implementing its verification in the account’s own code, at the gas cost of running that verification in the EVM. Pure-EVM benchmarks cited by the Tectonic Labs researchers put that cost at about 6.6 million gas for one Falcon-512 signature and 13.5 million for ML-DSA-44, against 2,800 gas for a secp256k1 signature the protocol verifies itself. The draft’s public-mempool rules cap signature checks and validation at 100,000 gas, so a transaction verified that way would not propagate through the public mempool without cheaper verification or a different inclusion path.

EIP-8141 is still a draft, specifies no post-quantum scheme and has no activation date on any network. Ethereum’s developers declined the standalone registry and scheduled a transaction format with scheme identifiers of its own, so the fragmentation Kempton described is still unresolved.

Tectonic Labs’ Design for Agility From a Chain’s First Block

Manuel Santos, Danno Ferrin, Ron Kahat and Michael Lodder of Tectonic Labs have proposed the most complete design I have found. They presented it at MAgiCS 2026, a workshop on migration and agility in cryptographic systems held in Rome in May, and Springer published their paper on July 9. The authors assess Bitcoin and Ethereum as lacking cryptographic agility, and Hedera and Cosmos as having partial support. They sort algorithm choice into three types: singular, where one algorithm is used system-wide; negotiated, where two parties pick from what both support, as in TLS; and selected, where one party picks from an allowed set. Negotiation does not work on a blockchain, they note, because an unbounded set of nodes must validate each transaction without a handshake.

Their EVM-compatible chain lets each user select an algorithm from an allowed set. A new transaction type, 0xCA, encodes the body and the signature as separate typed components, with algorithm identifiers for ECDSA, Falcon-512 and ML-DSA-44. Validators use one consensus signature algorithm at a time and change it by registering new keys on-chain. The switch happens at a scheduled block height if validators with more than two-thirds of the voting power have registered, and the chain continues under the old scheme if they have not. For the case where the current scheme is already broken, the authors also propose that each validator hold a recovery key based on a different assumption, such as SLH-DSA. That is Heilman’s backup idea applied to validators.

The authors tested the design on a local three-node network running on one Apple M3 Max machine. Over 30,000 blocks and 11 million transactions, their 0xCA transaction type added no measurable overhead. Falcon-512 sustained 3,200 transactions per second, about 80% of their baseline, against 1,900 for ML-DSA-44. Two of the authors, Danno Ferrin and Ron Kahat, have drafted EIP-8197, “Cryptographically Agile Transactions,” to bring the same separation of body and signature to Ethereum. Its transaction-type number has not been assigned yet, and it relies on a registry such as EIP-7932 for algorithm assignments.

Users of their chain migrate the same way they would elsewhere: generate a new key, derive a new address and move the funds. The authors want a user who returns after years away to find the funds still accessible, so their design sets no sunset for legacy keys. On a shared ledger, keys that never expire mean that a break of the old scheme threatens the value of every coin, including coins whose owners migrated.

Partial Agility on Algorand, Aptos, QRL and Zcash

Algorand has signed its state proofs with Falcon since 2022. Its v5.0.0 consensus upgrade, released on August 12 and in effect on mainnet later that month, added native Falcon-1024 accounts alongside Ed25519 ones. The Algorand Foundation notes that consensus still depends on a classical verifiable random function. Aptos Improvement Proposal AIP-137 would make SLH-DSA-SHA2-128s the first post-quantum scheme for Aptos accounts, as an opt-in alongside Ed25519. The Quantum Resistant Ledger (QRL) has run hash-based XMSS signatures since its 2018 launch, with an address format that can accommodate other signature schemes. I covered other chains’ plans in May.

Zcash has run four shielded pools since its 2016 launch: Sprout, Sapling from 2018, Orchard from 2022 and now Ironwood, with turnstile accounting between them. It has replaced the proof system behind its shielded pool twice on mainnet, and Ironwood, the new pool, uses the corrected Orchard circuit.

Retiring an Algorithm and the Coins That Never Move

Pieter Wuille has been a Bitcoin Core developer since 2011 and co-wrote the BIPs that specify Bitcoin’s Schnorr signatures and Taproot. On February 13 he answered Heilman with a post on the limits of cryptographic agility in Bitcoin. Holders depend on one another’s choices, he argued, because in a fungible currency the value of every coin depends on how safe the other coins are believed to be. Adding a new scheme, which he called FancySig, does not remove secp256k1 from what the network depends on. Once FancySig is adopted at scale, the shared assumption becomes “secp256k1 AND FancySig are secure.” Only disabling the old curve’s operations, or near-universal migration, removes that dependence. He expects disabling to become necessary on any chain that stays economically relevant once a break, or the fear of one, is serious enough. His reason is that millions of BTC are unlikely ever to move.

Four days later he clarified that he was not proposing a freeze, and that he does not find a Bitcoin that confiscates coins interesting. His concern was how the market would react to a suspected break. If the coins in many exposed addresses suddenly moved, and someone published a message signed with those keys claiming to own a quantum computer, the market reaction would do more harm than the theft. I argued in 2025 that Q-Day would arrive as a confidence crisis, and Wuille’s scenario is a concrete version of that argument.

Replies on the mailing list set out the main positions:

• John Light argued that disabling old schemes threatens Bitcoin’s ownership model more than theft does, because a locking script that was valid when coins were locked must remain valid.
• Antoine Poinsot answered that Bitcoin’s soft forks have made previously valid scripts invalid at least five times since Satoshi, so a case against freezing has to be made on its merits.
• The developer known as waxwing (AdamISZ) pointed out that nobody will know for certain when outputs become unsafe. An honest holder moving coins to safety, he noted, looks identical on-chain to a thief, which in his view makes any rule that might violate property rights unworkable. He also suggested that “flexibility” might describe what Bitcoin needs better than “agility.”
• conduition answered that Script lets a holder require signatures from two schemes in the same spending condition. A holder who doubts either scheme then loses coins only if both are broken.
• Matt Corallo argued that consumer wallets adopt new output types too slowly for voluntary migration to finish in time, so the community will probably have to disable insecure spend paths and allow spending only with a zero-knowledge proof of the seed phrase.
• Heilman noted that holders gain from a soft fork that freezes coins, because it reduces supply, and lose from a later soft fork that unfreezes them with such a proof, because it increases supply. He said he was not comfortable making post-quantum plans that depend on a confiscatory soft fork.

In enterprise terms, Wuille was describing deprecation. A bank deprecates an algorithm on systems it owns and renegotiates with counterparties under contract. When a chain deprecates an algorithm, its developers and node operators decide what happens to the coins of strangers who may never read the announcement.

Heilman keeps his backup algorithm permanently and relies on its fees to make it a last resort. He leaves open what happens to an everyday algorithm that breaks while coins still depend on it. In his reply to Wuille, he asked the list whether Bitcoin should make such a scheme more expensive to use or disable it.

BIP-361, written by Jameson Lopp and five co-authors and assigned its number on February 11, sets out one answer to that question for Bitcoin’s current signatures. One of its six authors, Steve Vaile, is Consulting Director for EMEA at Applied Quantum. I describe the proposal and the arguments around it here, and I take no side on freezing coins. BIP-361 is an Informational BIP in Draft status, and it requires a post-quantum signature BIP that its header still lists as to be determined. One of Bitcoin’s BIP editors converted it to Informational and questioned its deployment parameters because that prerequisite does not exist yet.

BIP-361’s authors count more than 34% of all bitcoin as having revealed a public key on-chain as of March 1, 2026. In the current text, Phase A would start 160,000 blocks, about three years, after activation. From then on, coins in legacy scripts could be sent only to post-quantum scripts. Phase B, two years later, would tighten the verification of ECDSA and Schnorr spends so that coins in quantum-vulnerable outputs can move only through a quantum-safe rescue protocol. One such protocol is a proof that the spender knows the BIP-32 parent key behind a hardened derivation path, which a quantum attacker holding only the public key would not know. The authors write that it remains to be seen how much of the supply can be rescued this way. They know of no rescue method for pay-to-public-key outputs. For those, they support Hourglass, a cap on how many such coins can be spent per block.

BIP-361 applies only to Bitcoin’s current signature schemes and does not address how Bitcoin would retire the scheme that replaces them. I covered the governance debate around it in May.

Ethereum has gone further on paper. In its Hegotá tier list, the Protocol cluster grades EIP-8298 and EIP-8151 A-tier, its expected-to-ship grade. Together they would let an account that has delegated to smart-contract code drop secp256k1 as its master key, after which signatures from the retired key no longer authenticate it.

For validators, the same list calls EIP-8365 “the one PQ item that belongs in Hegotá.” It would stop new validators from using the genesis-era BLS withdrawal credentials known as 0x00. Its authors present it as the first stage of a written deprecation plan. A companion EIP, aimed at the following fork, would exit the remaining 0x00 validators at a capped rate, and another would gradually reduce their retired balances to zero ahead of the post-quantum transition. About 9,200 validators still used 0x00 credentials in August, and several hundred had not attested for over six months, which the authors read as a sign of lost keys.

Ethereum’s developers have not formally scheduled any of these EIPs for inclusion yet, and the deprecation plan covers only validators. For ordinary accounts, EIP-8164 and the other account-level proposals protect only owners who use them.

Ethereum also has an emergency plan on paper. In March 2024, Vitalik Buterin outlined a hard fork for the day quantum attacks begin: revert the blocks since the theft started, disable ordinary externally owned account transactions and let holders recover through a STARK proof that they know the seed their key was derived from, the same idea Corallo raised for Bitcoin. It is a research post, not a rule, and it still needs the owner to act. In that plan, an account whose owner never acts stays frozen, and no Ethereum proposal I found says what happens to it after that.

Zcash retired Orchard after a soundness flaw, one that could have let an attacker mint counterfeit ZEC. The turnstile caps what can leave Orchard at what verifiably went in, so counterfeit coins cannot add to the ZEC supply outside the pool. NU6.3 imposed no freeze: coins can leave within that public accounting limit. The cap applies to the pool’s total, not to individual withdrawals, so counterfeit and real coins leave on equal terms. If counterfeit ZEC had existed, whoever left last would have found the turnstile closed. Shielded Labs expected a counterfeiter to race honest holders to the exit, and any coins beyond the cap would effectively have been destroyed.

A break in spend authorization is harder still, because an attacker who can sign for another holder’s coins leaves through the turnstile like any holder. For that case, Zcash has written its retirement rule down. ZIP 2005, the Zcash Improvement Proposal whose rules shipped with NU6.3, says Zcash must switch off its current shielded protocols before quantum attacks become feasible, and that funds still in the Sprout, Sapling or Orchard pools would then be inaccessible. Zcash calls its shielded coins notes. Since Ironwood’s first block, its notes have been created in a format that a future Recovery Protocol could use to let their owners move them, which ZIP 2005 outlines but leaves undecided in its details.

The ZIP sets no date for the switch-off, and it states that it does not by itself make Zcash secure against quantum attacks. Of the chains I reviewed, Zcash is the only one that has deployed the note format its rescue path depends on and written down what happens to holders who do not move. The switch-off itself still needs its own upgrade and date.

Bitcoin already keeps one weakened primitive. OP_SHA1 still works in Bitcoin Script and in Tapscript, more than nine years after the first practical SHA-1 collision, as a participant noted in the mailing-list discussion of Heilman’s proposal. Keeping the opcode costs little, because a collision attack by itself does not break a script that commits to a fixed SHA-1 hash. Breaking one would take a preimage attack. Disabling the opcode could freeze coins locked by scripts that call it.

Five Gaps in the Current Proposals

Each proposal above addresses a particular algorithm, failure or layer of a chain. Between them, as of early October 2026, they leave five questions open:

• Hash functions. Bitcoin’s proof-of-work and Merkle trees use SHA-256, and its older address types hash public keys with RIPEMD-160 and SHA-256. Grover’s algorithm gives only a quadratic speedup against hashes, so quantum computing is not the pressing reason to change them. A classical break would require a migration that none of these proposals designs. Chains are already choosing differently on newer hashes. Ethereum’s researchers dropped Poseidon from the layer-1 roadmap in August before deploying it, because standard hashes had become cheap enough to prove with binary-field proof systems. In the same month, Algorand’s virtual machine, AVM v13, added a poseidon2 opcode, and Solana and Starknet already offer native Poseidon support.
• Implementations. Fixing a broken implementation is a different job from replacing a broken algorithm: find every chain and verifier that runs the code, patch it and replace any exposed key. Orchard’s flaw was in a shared gadget library, OtterSec found six teams making the same mistake independently, and Bitcoin Core verifies signatures with one library. Zcash’s June fix was an incident-specific repair. None of the proposals I reviewed describes a rehearsed, general process for replacing a broken implementation on a chain that is already running.
• A review cadence. No chain I reviewed publishes a standing review of the algorithms it accepts, with criteria and dates for deprecating them. The Protocol cluster’s January 2027 reassessment is the closest.
• Wallet behavior. Heilman’s design assumes holders never reuse keys. Corallo recounted on the mailing list on February 13 that Trust Wallet, regularly in the top three app-store results for “bitcoin wallet,” generated fresh addresses by default, then made the feature optional, then removed it because nobody turned it on. I found no measurement of whether wallets preserve the assumptions these designs make, such as never reusing or exposing a key and keeping a backup leaf available.
• Time-to-change data. Incident disclosures publish timelines, as Zcash’s did in 2019 and 2026, but no chain I reviewed publishes a consistent record of decision, activation and holder migration across its cryptographic changes, which is why I built the table above from public dates.

What Exchanges, Custodians and Funds Can Do Now

For crypto-asset service providers in the EU, a crypto-agility obligation already applies. Article 6(4) of Delegated Regulation (EU) 2024/1774, the technical standard on ICT risk management under the Digital Operational Resilience Act (DORA), requires a financial entity’s encryption policy to provide for updating or changing its cryptographic technology on the basis of developments in cryptanalysis. An entity that cannot do so must adopt mitigation and monitoring measures that ensure its resilience against cyber threats, and Article 6(5) requires it to record them with a reasoned explanation.

DORA applies to crypto-asset service providers authorized under the Markets in Crypto-Assets Regulation (MiCA). The European Securities and Markets Authority (ESMA) had read that provision as excluding providers still operating under MiCA’s transitional regime, which ended across the EU on July 1, 2026. ESMA’s position is that a firm serving EU clients now needs a MiCA authorization or, for banks, investment firms and the other regulated entities that MiCA names, a notification, and that a firm with neither, outside a narrow reverse-solicitation exception, is in breach of EU law. The notified entities are subject to DORA in their own right.

As I read Article 6(4), a provider’s policy has two parts. For the cryptography it controls, such as its APIs, its internal key management and its release signing, the policy has to show how the provider changes algorithms. For on-chain keys, consensus rules set the signature algorithms the custody stack may use, and a provider cannot change those rules on its own, although it may be able to choose among the mechanisms a chain already supports. Where it cannot, the clause for entities that cannot change applies: mitigation, monitoring and a recorded reason. Article 6(4) states a general duty, and this two-part reading is my application of it to blockchains.

The Digital Assets Extension of my PQC Migration Framework defines agility for the sector the same way. A provider is crypto-agile when it can change the algorithm on its own custody stack, APIs and signing services on a planned date. It must also be able to name, for each chain, the protocol change its on-chain keys depend on, how firm that change’s date is, and the address-rotation policy it applies until then.

An exchange, custodian or fund can take five steps now:

• Rehearse an algorithm change on systems you control. Pick one internal signing path in a staging environment and replace its signature algorithm, for example ML-DSA with SLH-DSA where the tooling supports both, then update the signers, verifiers, key handling and policy that depend on it. Time the assessment, decision, change and verification separately, and rehearse the return to an approved configuration that is still secure, as I described in the October article. A parameter-set change is a smaller exercise and should be labeled as one.
• Reduce the exposure you control. Inventory where your public keys are exposed, including through off-chain signatures and shared extended public keys. Where custody policy allows, and after checking that the move keeps multisignature and recovery controls intact, move bitcoin from reused and Taproot addresses to never-spent hash-protected outputs, and keep ETH in accounts that have not signed any transaction or off-chain message. Both steps reduce key exposure while the coins are unspent. Neither makes the coins quantum-safe, because spending them exposes the key again.
• Write the playbook for an algorithm event on each chain you list. Zcash’s sequence shows what to plan for: a pool disabled for a day, a hard fork the next day, a public disclosure, a price drop of about half and a migration to a new pool eight weeks later. Decide in advance who can pause deposits and withdrawals for a single chain, what triggers that decision and how client assets move through a migration.
• Prepare for new output types before they activate. Corallo argued that large custodians could move all their coins within days or weeks in an emergency, and that the most popular consumer wallets have taken five to ten years to adopt basic Bitcoin features. A custodian’s own coins are the smaller problem. Once post-quantum output types are specified, an exchange can build and test support before activation. After activation, it can use the new outputs for its own deposit and storage addresses, and accept client withdrawals to them once its security checks are done. My article on preparing for crypto’s quantum future lists the other steps by role.
• Disclose the dependence. In its quarterly report for the period ended June 30, 2026, the iShares Bitcoin Trust tells shareholders that a transition to post-quantum cryptography could require broad consensus and “a fork (or multiple forks),” with no assurance that consensus would be reached or the changes made successfully. A fund holding assets on several chains can describe its dependence on each one the same way, naming the protocol change it is waiting for on that chain.

What Protocol Developers Can Build Into the First Upgrade

Jonas Nick calls SHRINCS the first concrete post-quantum signature scheme designed for Bitcoin, and he says it is not meant to be the final one. Ethereum’s frame transactions have no activation date. Before either ships, protocol developers can build in five things:

1. A standing second path. A backup leaf, as Heilman proposes, or reserved scheme identifiers, as in EIP-8141. A backup that consensus already verifies can be used without a new rule, a new native verifier still needs one, and an account whose own code verifies signatures can change without either. Each path needs its wallet support and its retirement decision planned alongside it.
2. The retirement rule and its rescue path, in the same round. Zcash had turnstile accounting in place before Orchard broke. ZIP 2005 states in advance which funds become inaccessible when the old protocols are switched off, and Ironwood notes are created in a format a future Recovery Protocol could use. A retirement plan should also say how nodes keep verifying old blocks after an algorithm stops being accepted for new spends.
3. A published review cadence, with criteria and dates for deprecating each accepted algorithm. The Protocol cluster’s January 2027 reassessment is a start.
4. Agility plans for hash functions, proof systems and the implementations that verify them, alongside the plans for signatures.
5. A measured time-to-change, rehearsed on testnets and signets and published, so that holders, exchanges and supervisors can plan around a number.

Zcash sealed a pool then worth about $1.7 billion in 60 days without a blanket freeze, because its turnstile accounting was in place before the flaw was found. Its next retirement rule is already written into ZIP 2005. Bitcoin and Ethereum have drafts, and they still have time to turn them into rules before their first post-quantum upgrades activate.

Steve Vaile, one of BIP-361’s authors, is Consulting Director for EMEA at Applied Quantum. Applied Quantum sells post-quantum migration advisory services, and the recommendations above favor that business. I also advise Project Eleven, which works on post-quantum security for digital assets; no Project Eleven material is cited here. The PQC Migration Framework, including its Digital Assets Extension, is free under CC BY 4.0, and anyone can use it without engaging us.

From the author