How Ethereum, Solana, Hedera, and Canton Are Preparing for the Quantum Threat to Blockchain Cryptography

Executive Summary

Every major blockchain in production today is secured by elliptic-curve cryptography, and elliptic-curve cryptography is exactly the kind of mathematics a sufficiently large quantum computer is built to undo. A year ago, saying so out loud in a strategy meeting would have earned you a polite change of subject. Today it earns you a follow-up question because the gap between the theory and a working machine has narrowed to the point where prudent institutions are obliged to plan for it.

This note surveys what the blockchain ecosystem has actually accomplished in response, not what it has promised, but what is drafted, benchmarked, and in some cases already running on testnets. The honest summary is that the destination is largely agreed and the road is mostly unpaved. Replacement algorithms exist. New transaction types are drafted. The hard, unglamorous problem of moving hundreds of millions of existing accounts onto new cryptography without losing anyone's funds remains genuinely unsolved.

What to take away

An On-Spend Attack Against Exposed Keys Takes Minutes, Not Years

• •The threat is concrete, not hypothetical. Fresh Google research estimates an on-spend attack against exposed elliptic-curve keys at roughly 9–12 minutes once a cryptographically relevant quantum computer exists. The most exposed accounts are dormant ones (e.g., lost keys, deceased owners) that no one is watching.
• •The replacements are known. Lattice schemes (ML-DSA / Dilithium, FN-DSA / Falcon) replace account signatures; hash-based schemes (XMSS, LMS, SLH-DSA) replace consensus signatures. None are free: signatures and keys grow by an order of magnitude or more.
• •Each chain is choosing a different path. Ethereum leans on precompiles, account abstraction and a minimal zkVM; Solana is optimising for speed under Falcon; Hedera's scheme-agnostic identities make rotation cheap; Canton's per-party flexibility lets legacy and post-quantum keys coexist.
• •The migration cannot be fully automated. Chains know public keys, not private ones. They cannot rotate a user's account on the user's behalf. This forces an uncomfortable, near-binary choice: freeze unmigrated accounts at a deadline, or accept that the first quantum attacker drains them.
• •The window to act is now, not on Q-Day. Fund-recovery schemes are still research, and the cleanest of them only work for standard seed-phrase wallets. Holders, developers and architects who move early inherit a manageable migration; those who wait inherit an emergency.

Introduction: Mapping Uncharted Terrain

At Lime Institutional, our job is to map terrain. Usually that terrain is a client's balance sheet, a settlement workflow, or a tangle of legacy systems that need to speak to a ledger they were never designed to trust. Occasionally the terrain is stranger than that. This is one of those occasions, because the ground we are surveying here is the uncharted territory of quantum physics - a place where the usual cartographic instincts fail, and where a map drawn from rumour rather than measurement is worse than no map at all.

I want to be honest about why this document exists. There is a great deal of noise around quantum computing and blockchains, and most of it falls into one of two camps: breathless panic, or dismissal. Neither is useful to an institution that has to make real decisions about real capital. What is useful is a practical inventory of what has actually been accomplished like:

• •which algorithms are standardised;
• •which proposals are drafted;
• •which testnets are running;
• •and which problems remain open.

Getting a real sense of that, rather than a vibe, is the entire point of this exercise.

I should also mention why this deserves more of our energy and attention than it currently gets. Blockchain technology made a promise: that ownership could be enforced by mathematics rather than by intermediaries. That promise is only as good as the mathematics underneath it. If the signature scheme securing every account can one day be broken by a machine, then the promise has an expiration date and the institutions building serious financial infrastructure on these rails deserve to know how long the warranty runs and what the renewal looks like.

Before we get to blockchains, a word on the physics, because the subject is genuinely counter-intuitive and the temptation to hand-wave is strong. I have leaned on Scott Aaronson's Quantum Computing since Democritus, which has the rare virtue of being both rigorous and honest about what is hard. Aaronson places quantum mechanics not as some exotic corner of physics but as something more foundational:

That framing is the one I hold onto. We are not bolting an upgrade onto our existing computational world; we are looking at the layer the whole world runs on, and asking what happens to our cryptography when someone learns to program it directly. The rest of this note is a guided survey of that question.

Why This Deserves Attention: The Money on the Table

The abstract threat becomes concrete the moment you look at the chain. Recent research from Google — Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations — puts a number on it that is hard to wave away:

Elliptic-curve cryptography is the mechanism that secures user accounts. It derives a public key (a unique account identifier) from a private key, which is the owner's proof of ownership. Break the link between the two and you can spend from any account whose public key you can see. To feel the scale of what this means, we can look at some of the richest accounts on Ethereum today.

Note: Balances verified live on etherscan.io/accounts, 28 May 2026.

The Beacon Deposit Contract alone holds over 86 million ETH (roughly $171 billion at ~$1,988/ETH) and the staked ETH it custodies is secured by validator BLS12-381 signatures, which Shor's algorithm breaks just as cleanly as ECDSA. The next four entries are exchange-custodial or contract addresses. Every one of them has signed at least one transaction, which means the underlying public keys already sit in the chain's transaction history, recoverable today by anyone running a node.

The Dormant Wallets Nobody Is Watching

The most exposed accounts are not the ones being actively managed. They are the dormant ones like owners who died, lost their keys, or forgot the account existed. These are the first accounts a quantum attacker would empty, precisely because no one is watching and no one will notice the theft until long after it is too late.

• •Rain Lõhmus — 250,000 ETH (~$497M), Ethereum. The Estonian LHV Bank founder bought 250,000 ETH in the 2014 pre-sale and lost the JSON wallet file and its password. Conor Grogan of Coinbase publicly linked the address to him in late 2023. Fully visible on-chain, completely unreachable to its owner.
• •James Howells — 7,500 BTC (~$832M), Bitcoin. The Welsh engineer who in 2013 accidentally threw away the hard drive holding the private key for 7,500 BTC he mined in 2009. The drive sits, as far as anyone knows, in the Docksway landfill in Newport. He spent a decade petitioning the city council, sued for £495M in 2024 and lost, and in 2025 pivoted to "tokenising his legal ownership" of the coins he cannot touch.
• •Stefan Thomas — 7,002 BTC (~$777M), Bitcoin. Paid the coins in 2011 for a "What is Bitcoin?" video and stored them on an IronKey, then lost the slip of paper with the password. The IronKey wipes itself after 10 wrong attempts; he has used 8. With two guesses left and hundreds of millions on the line, the wallet has been frozen in place for over a decade.

These are merely the famous ones. The same pattern repeats thousands of times on every chain that has ever existed: a key written down and lost, a device discarded, an owner who died without sharing the seed phrase. Add the long tail of untouched early-adopter wallets (e.g., Vitalik Buterin's main wallet alone holds roughly 224,000 ETH) and you have a standing reward of billions of dollars for whoever switches on the first capable machine. A working quantum computer would derive the private keys for all of them in minutes.

And yet, nothing here is lost. The community saw this coming and started moving. At Lime Institutional we have been tracking these efforts across Ethereum, Solana, Hedera and Canton, and building small proof-of-concepts to stress-test the proposals (more on that near the end). But to judge the defences honestly, we first have to understand the weapon. So, briefly and without melodrama, here is how a quantum computer actually works.

Quantum Computers, Briefly and Honestly

The computers we use every day, from laptops to billion-dollar datacentres, represent data as bits of long strings of 0s and 1s. This is a legacy of the 1940s, when the only practical way to store and mutate state was a conductor that either conducts electricity or does not: "on" or "off," true or false, 1 or 0. From those two states you can build any number, character, or structure.

Transistors have shrunk relentlessly since. A typical transistor is around 14nm which is about 500 times smaller than a red blood cell and only 50 times larger than an atom. Meanwhile state-of-the-art transistors today are 4nm. As components approach atomic scale, electrons stop behaving like obedient classical objects and start obeying the laws of quantum physics. Quantum computers lean into this rather than fighting it. They too represent data as plain 0s and 1s before a computation begins and after it ends. In between, their quantum bits (qubits) have two properties that make all the difference.

Superposition

During a computation, a qubit is not in a definite state. It is neither 0 nor 1 but, in a precise probabilistic sense, both at once — say, 0 with 40% weight and 1 with 60%. The familiar analogy is a spinning coin: while it is in the air you cannot call it heads or tails, because it is meaningfully both, with some weight on each. Only when it lands does it commit.

The coin analogy is a good on-ramp, but it quietly understates the strangeness, and I would rather not sell you a tidier picture than the truth supports. Aaronson's framing is more precise and worth sitting with: quantum mechanics is "a beautiful generalization of the laws of probability," one based on amplitudes rather than ordinary probabilities. The crucial difference is that amplitudes can be negative — and that single fact is the engine of everything:

Entanglement

Entangle two qubits and the outcomes of their computations become tied together. Return to the coins: imagine starting two spinning together, then sealing one in a box and shipping it to Tokyo while the other stays in New York. The moment the New York coin lands, its Tokyo twin "magically" lands in a correlated way. The word "magically" is doing a lot of work, and the reality is subtler than instantaneous influence, but for our purposes the operational point is enough: entangled qubits are not independent, and a quantum algorithm can orchestrate many of them in concert.

Why this is useful

Together, superposition and entanglement let a quantum computer explore many possible outcomes at once, without the brute-force parallelism of running many classical threads. It behaves a little like simulating several realities side by side, which is why quantum machines excel at simulation, pattern-finding, and searching large spaces like drug and materials discovery, supply-chain routing, smart energy grids, swarm coordination, portfolio optimisation, AI training, and, the one that concerns us, breaking encryption.

Here I want to bust a popular myth before it does any damage, because it's one of the most common misunderstandings in the field. The press, Aaronson notes, would have you believe a quantum computer can "solve NP-complete problems in a heartbeat by trying every possible solution in parallel, and then instantly picking the correct one." That is, in his words, "arguably the central misconception about quantum computing among laypeople." A quantum computer is not a machine that tries every key at once and reads off the answer. Its power comes from arranging computations so that the wrong answers' amplitudes cancel out and the right answer's amplitude is reinforced. This matters for us in a very practical way: the threat to cryptography is real but specific. It applies to the particular mathematical structures Shor's and Grover's algorithms exploit - not to everything, and not by magic.

From theory to hardware: a timeline

Five years ago a useful quantum computer was a theoretical object. Today it is a plausible one, if practice keeps closing on theory at its current pace. The trajectory is worth seeing laid out:

How a Quantum Computer Breaks Cryptography

Because quantum machines are good at searching spaces and detecting patterns, they have a comparatively easy time finding the periodicity of mathematical functions, including the functions underlying elliptic curves. The cleanest way I know to picture it: imagine each blockchain account as a vault. The shape of the lock is the public key; the key that opens it is the private key you use to sign transactions.

A classical computer is an inexperienced thief, doomed to try all 2²⁵⁶ combinations one by one. A quantum computer is a skilled locksmith: it taps the lock a few times, reads its resonant frequency, and files a perfect key. The vault was never picked by brute force. It was understood. That distinction is exactly why a chosen few mathematical structures are vulnerable while others are not.

Post-Quantum Alternatives to Elliptic Curves

Elliptic-curve algorithms owe their efficiency to the same structure that makes them breakable: their strength is their weakness. Fortunately, other families of algorithms rest on different foundations.

Lattice-based schemes work over multi-dimensional grids of points. A private key is an efficient combination of vectors describing a path to a chosen point; the public key is a deliberately inefficient description of the same thing.

• •Dilithium (ML-DSA) is the finalised NIST standard (FIPS 204, August 2024) and the most conservative contender.
• •Falcon (FN-DSA) offers smaller keys and signatures but computes them with floating-point arithmetic, which complicates constant-time, side-channel-hardened implementations. NIST issued FIPS 206 as an Initial Public Draft in August 2025; final approval is expected in late 2026 or early 2027.

Hash-based schemes exploit the friendly properties of hash functions (easy to compute, deterministic, and non-reversible). Grover's algorithm halves their security, but even the weakest modern hash retains ample post-quantum strength. The price is large signatures and keys.

• •Stateful schemes combine hundreds of one-time signatures (e.g. WOTS) into a Merkle tree and track used leaves with an internal counter XMSS and LMS.
• •Stateless schemes build vast Merkle trees and select a leaf at random like the SPHINCS+ family, standardised as SLH-DSA in FIPS 205.

If it feels like the menu is short, you are reading it correctly. Several promising dishes have already been sent back to the kitchen, and they are a useful reminder that elegance on paper is not the same as security in the field:

• •Classic McEliece - well-studied and secure since 1978, but its public keys run to several megabytes, which is unusable on-chain.
• •Rainbow - a researcher favorite for its lean signatures and keys. Broken in 53 hours on a decade-old laptop in 2022.
• •Isogeny schemes - tiny keys, much admired. Broken in 2022 in four minutes on an ordinary computer.

The lesson is one we take seriously in our own work: a promising new algorithm should not be trusted simply because it is promising. It earns trust by surviving.

Execution-Layer Signatures: The Cost of Replacement

Lattice schemes are the only realistic replacement for the quantum-vulnerable ECDSA and Ed25519, because they offer the smallest signatures and keys among post-quantum options. "Smallest," though, is relative and the migration is not free. The tables below show each scheme's cost against ECDSA.

Signature size (bytes)

Public key size (bytes)

Bytecode gas cost (pure-Solidity verification)

In plain terms: signatures grow 10–38×, public keys 14–20×, and on-chain verification roughly 500–1,600× relative to ecrecover. At current gas prices, a single Falcon verification on the EVM would cost around $1.50 which is fine for a one-off, but a disaster for any user-facing flow.

The fix is to move verification out of the virtual machine and into native code via precompiles. EIP-8051 (ML-DSA) and EIP-8052 (FN-DSA) propose exactly this, and the difference is night and day:

Verification gas cost with proposed precompiles

Once precompiles ship, the gas overhead all but vanishes. The signature-and-key bloat, however, stays with us - calldata is still paid per byte, and that bill does not go away.

Consensus-Layer Signatures: The BLS Problem

BLS earns its place through one remarkable property: it aggregates thousands of validator signatures into a single signature with no growth in size. That is what makes consensus economical at the scale of hundreds of thousands of validators. Unfortunately, BLS rests on a pairing assumption over an elliptic curve, which Shor breaks as cleanly as ECDSA.

Simple, conservative, and reducible to the security of the underlying hash hash-based schemes are the natural successor. On the raw numbers they look surprisingly competitive:

Public key size (bytes)

Verification CPU cycles

Signature size (bytes)

BLS12-381 shown in the compressed encoding Ethereum's beacon chain actually uses (G1 pubkey, G2 signature).

Hash-based schemes lose decisively on signature size and the loss is worse than the table suggests, because they lack native aggregation. BLS compresses thousands of signatures into 96 bytes; an aggregate of N XMSS signatures is N × 2,500 bytes. For a network with hundreds of thousands of validators, anything linear in validator count is a non-starter.

The leading remedy is to aggregate with a zero-knowledge proof: validators sign with XMSS or LMS, and an aggregator proves "all N of these signatures verify" inside a single ZK-STARK whose size is constant regardless of N. The catch is that proving is expensive, and every block proof must be checked by every validator. There is no free lunch here — only a lunch whose bill we can move around.

How Each Chain Is Responding

Ethereum

The Ethereum community has opened the discussion in earnest (see pq.ethereum.org for a curated index). Two proposals (EIP-8051 and EIP-8052) add verification precompiles for ML-DSA and FN-DSA. For the consensus layer, Lean Ethereum proposes a minimal zkVM (the leanVM) with just four opcodes and two precompiles, aggregating XMSS-based validator signatures (leanXMSS) into a single ZK-STARK. The deliberately tiny instruction set keeps the VM formally verifiable, and aggregation compresses validator signature traffic by roughly 250×.

To accommodate new signing logic, both permanent and temporary measures are on the table. Among the long-term options:

• •Frame Transactions (EIP-8141) bring protocol-native account abstraction without smart-contract or bundler overhead. A new transaction type (0x06) carries an array of "frames," each with its own data, target, gas limit and value, executing in VERIFY, SENDER or DEFAULT mode. Beyond solving the signature problem, they enable bundled transactions, gasless approvals, and "signed by one person, paid by another" flows.
• •Schemed Transactions (EIP-8202) take a lighter approach: a new type (0x05) carrying an array of authorizations, each a signature under one of several officially supported schemes. Their authors argue, reasonably, that the threat is near and Frame Transactions may take too long to standardise.

Temporary measures lean on what already exists:

• •Account abstraction — EIP-4337, EIP-7702 and EIP-7851 together allow custom verification via a smart account. EIP-7702 lets an existing EOA delegate execution while keeping its address; EIP-7851 then irreversibly disables the legacy ECDSA key. Without 7851, a quantum attacker who recovers the old key could simply re-delegate the account to a malicious contract, so that final step is not optional.
• •Hash-Committed Accounts (EIP-8215) — an identity-decoupling scheme using ephemeral key rotation. At creation the user commits to a Merkle tree of spending rules and the address becomes keccak256(auth_root)[12:]. The public key never appears on-chain until the moment of spending, and each spend can rotate the tree to a fresh root.

Solana

Solana has moved fast while guarding its defining feature: speed. In December 2025 the Solana Foundation announced a partnership with Project Eleven and opened a public testnet replacing every Ed25519 signature with CRYSTALS-Dilithium (ML-DSA). The initial framing was optimistic (early benchmarks held ~3,000 TPS, on par with mainnet) but follow-up testing in April 2026 (reported by CoinDesk) showed the post-quantum variant running ~90% slower, with signatures 20–40× larger. An honest benchmark is worth more than a flattering press release, and the team treated it accordingly. Several improvements have since been proposed, scheduled, or shipped:

• •P-tokens (SIMD-0266) — a zero-copy, zero-heap rewrite of the SPL Token program, achieving ~98% compute-unit reduction on Transfer and reclaiming ~12% of block space.
• •Larger transactions (SIMD-0296) — raises the maximum transaction size from 1,232 to 4,096 bytes; without it, a post-quantum signature does not fit in a single transaction.
• •Firedancer — Jump Crypto's C-language validator client, using AVX-512 for both Ed25519 batch verification and the NTT inner loop of lattice schemes. On mainnet since ~December 2025, with ~20% of stake by early 2026.
• •Falcon syscall (SIMD-0461) — Falcon verification as a native syscall outside the SVM, at validator native speed. Anza and Firedancer both have open PRs.

Quantum-safe wallets already exist, too. The Winternitz Vault uses Winternitz One-Time Signatures as ephemeral keys, rotating funds into a fresh vault on every spend so the revealed public key is never reused.

Hedera

Hedera supports both Ed25519 and ECDSA, but, happily, this does not make it twice as vulnerable. Every Hedera account has a scheme-agnostic identity, an AccountId of the form X.Y.Z (e.g. 0.0.123), so an account can rotate its keys without changing its identity. That single design choice removes much of the migration pain other chains are wrestling with.

Hedera is also moving quickly. Co-creator Dr. Leemon Baird has committed to FN-DSA (Falcon) as the preferred scheme and plans to use it internally for consensus event signing as soon as FIPS 206 is finalised, with a post-quantum key type for end users targeted for 2027. The infrastructure is already well-prepared:

• •SHA-384 hashing for the hashgraph structure — 192 bits of post-quantum security, versus the 128 bits typical elsewhere.
• •CNSA 2.0 alignment — the same benchmark the US government uses for Top Secret data.
• •Jumbo Transactions (HIP-1086) already in place to carry large post-quantum signatures, with EthereumTransaction callData expanded from 6 KB to 128 KB.

Canton

Canton is a modern, privacy-focused ledger that avoids global replication, which does not make it immune. Public keys used for encryption are hidden from the wider network but remain visible to all participants in a synchronizer domain. A compromised node, a malicious operator, or an eavesdropper could capture encrypted transactions now and decrypt them later. The symmetric algorithm currently used for encrypted views, AES128-GCM, is only partially comforting: Grover halves its effective strength to 64 post-quantum bits, below NIST's 128-bit threshold for long-term confidentiality. AES-256-GCM would close that gap, but the more pressing issue is the signature algorithms Canton supports, all fully broken by Shor:

• •Ed25519 (using EC-Curve25519)
• •ECDSA-SHA256 (using EC-P256 or EC-Secp256k1)
• •ECDSA-SHA384 (using EC-P384)

Some third-party sequencing engines (such as Oraclizer's D-quencer) use BLS aggregation and may need a redesign.

Because Canton lets users choose their signing algorithm, the official implementation can be extended with post-quantum schemes relatively cleanly. The Quanton proposal does exactly this, adding ML-DSA, FN-DSA and SLH-DSA verification into the protocol. Canton's flexibility lets legacy and post-quantum keys coexist on the same synchronizer, so parties migrate on their own schedule — and early research (eprint 2025/1368) suggests party UIDs can be preserved across migration via a one-time on-chain attestation binding new keys to existing accounts. Because each participant executes its own state transitions before attestation, migration scales well, with no virtual-machine bottleneck.

A second, independent effort (BOLTS' QFlex, based on Structured Data Folding with Transmutations) secures data at the transaction level rather than the channel level, letting an institution package a settlement payload (a repo, say) in NIST-standardised post-quantum signatures without rewriting smart contracts. Both efforts are, in effect, early defences against the "Harvest Now, Decrypt Later" threat that NIST IR 8547 describes as adversaries who "collect encrypted data now with the goal of decrypting it once quantum technology matures."

Beyond Swapping Schemes: Blockchain-Agnostic Ideas

A few proposals go further than "change the signature scheme". They reach for zero-knowledge proofs, lattice mathematics, or entirely new account models to sidestep signatures altogether. The most striking is ZK-ACE (Identity-Centric Zero-Knowledge Authorisation), built on a genuinely clarifying premise: the public key was never the right primitive. What actually authorises a transaction is the owner's knowledge of a secret and a zero-knowledge proof can express that knowledge directly. The flow has three phases:

• •Registration (once per identity). The user generates a 32-byte Root Entropy Value (REV) offline, derives a public commitment id_com = Poseidon(REV || salt || domain), and publishes only the commitment. The address is derived from id_com. No public key ever touches the chain.
• •Session creation. To avoid using the master REV every time, the user produces a short ZK proof of "I know the REV behind this id_com" (~1.1k–1.4k R1CS constraints with a Poseidon-friendly backend), attaching a short-lived symmetric session key.
• •Per-transaction authorisation. Each transaction carries a 32-byte HMAC under the session key — no signature, no public key. A specialised prover aggregates all of a block's transactions into one block-level proof (~300 ms, comfortably inside Solana's current 400 ms block time), which validators verify once.

The catch is operational: a chain adopting ZK-ACE needs a prover running alongside the block leader, and the model is unfamiliar to existing wallets, indexers and explorers. But it is the cleanest expression of the underlying insight. Namely, that swapping one signature scheme for another treats the symptom, not the cause.

The Unsolved Problem: You Cannot Automate the Migration

The main contenders to replace ECDSA, Ed25519 and BLS are known. New transaction types are drafted. And yet one obstacle resists all of this elegance: the transition from legacy to post-quantum accounts cannot be automated. A chain knows only public keys. It cannot perform key rotation on a user's behalf and reliably hand them a new private key. Migration requires the user to act.

Which surfaces the Rain Lõhmus problem at scale. Once a cryptographically relevant quantum computer exists, every unmigrated account becomes a sitting target, and the chain faces an uncomfortable, near-binary choice:

• •Do nothing — and accept that whoever switches on the first machine drains billions in dormant funds before any rightful owner reacts. The chain cannot distinguish "Rain Lõhmus finally remembering his password" from "an attacker who just derived his private key." Both present a valid signature. Once funds move, they are gone; there is no rollback.
• •Freeze unmigrated accounts at a protocol-enforced deadline and let owners reclaim them through a recovery procedure. This overrides on-chain finality and looks uncomfortably like censorship — but it is the only mechanism that protects users who are not paying attention. And among 2014 pre-sale wallets, "not paying attention" describes the overwhelming majority.

There is no third option that preserves both the funds and decentralised-protocol semantics. Either the chain freezes legacy keys, or the first quantum attacker does the freezing — by emptying the accounts. Given that some form of freeze is effectively unavoidable, the real design space is how to freeze and how to let honest users recover. The community is weighing a spectrum:

No chain has reached consensus on any of these. The most likely real-world outcome is a layered hybrid: announce a long migration window, ship STARK-based recovery for standard wallets, and leave the residual long tail to per-chain governance.

What This Means in Practice

This transition will change how blockchains operate and how developers, product stakeholders and users interact with them. SDKs will adopt the new algorithms and deprecate the old ones; new transaction types may appear; wallets and sign-in flows will change to reflect new primitives; chains will revisit transaction costs and finality as they absorb the overhead; hardware requirements for proposers and validators may shift if Falcon (floating-point) or ZK proofs (GPU-hungry) come into play; existing products may need to revisit their security assumptions; and forward-looking products can market their readiness through design. Concretely, depending on who you are:

• •If you hold crypto: migrate to a post-quantum account as soon as your chain supports it. Do not wait for Q-Day. Fund salvaging may never be implemented, and even where it is, it will likely require an expensive ZK proof and submitting your seed phrase to a recovery app. If your account does not derive its key from a seed phrase, migration is more urgent still: recovery research has no plausible way to prove ownership of a non-BIP-39 account.
• •If you build software: watch the new SDKs, transaction types and official cryptography decisions, and budget for them.
• •If you architect systems: ensure new flows such as Sign-In-With-Ethereum rely on quantum-secure cryptography from the moment it ships.
• •If you maintain systems: plan to update flows and identities to post-quantum cryptography rather than retrofitting under pressure later.

How Lime Institutional Is Preparing

I said at the outset that we prefer measurement to rumour, and we hold ourselves to the same standard. We have been tracking the post-quantum migration since well before it became fashionable, and we have explored it the only way that produces real opinions: by building rough-cut, research-grade proof-of-concepts and seeing what breaks. Three of those prototypes are worth naming:

• •FlyFlow — an ERC-4337 smart-account PoC that performs Falcon signature verification inside validateUserOp, demonstrating the end-to-end flow from off-chain Falcon signing to on-chain validation against a ZKNox-style verifier.
• •pqc-eth-poc — We built a working prototype of a quantum-computer-proof crypto wallet known as a Hash-Committed Account (EIP-8215). To see how it works in the real world, we gave it a clickable app interface that also uses Ethereum's modern 'smart wallet' features (the EIP-4337 path). Ultimately, it combines heavy-duty security with everyday convenience so we can test what a next-generation wallet actually feels like in a user's hands.
• •ShorStop — a mobile app that generates the zero-knowledge proof a STARK-based recovery scheme needs: the "I know the seed phrase behind this account" claim, made concrete.

None of these are products. They are instruments just like a cartographer carries a theodolite. They exist so that when a client asks us whether Frame Transactions, Hash-Committed Accounts or ZK recovery are ready for their infrastructure, we can answer from experience rather than enthusiasm.

Key Takeaways

• •Every major blockchain needs a replacement for its elliptic-curve signatures. The question is no longer if, but when and how.
• •The threat is now concrete: Google's resource estimates put an on-spend attack at roughly 9–12 minutes once a capable machine exists, and dormant wallets are the softest targets.
• •Lattice schemes (ML-DSA, FN-DSA) replace account signatures; hash-based schemes (XMSS, LMS, SLH-DSA) replace consensus signatures. Precompiles tame the gas cost, but signature and key bloat remain.
• •Each chain is choosing a path that suits its design: Ethereum's precompiles and zkVM, Solana's speed engineering, Hedera's scheme-agnostic identities, Canton's per-party flexibility.
• •The migration cannot be automated. A protocol-enforced freeze of unmigrated accounts is, in practice, unavoidable — the only real choice is how to freeze and how honest owners recover.
• •The likely outcome is a layered hybrid: a long migration window, STARK-based recovery for standard wallets, and per-chain governance for the long tail.
• •The institutions that move early inherit a manageable migration. Those that wait inherit an emergency. The time to start mapping is now.

About Lime Institutional

Lime Institutional is a strategic advisory and technology delivery firm built on the engineering foundation of more than nine years at the forefront of blockchain and digital assets development and over 300 projects delivered. We translate that deep engineering pedigree into clear, predictable, and fully executable solution paths for financial institutions and enterprises seeking to expand into the realm of digital assets safely and seamlessly.

From strategic advisory and enterprise architecture to tokenization infrastructure and full-scale implementation programs, we bring senior consultants, engineers, and architects into the room from day one — because strategy disconnected from technical reality is just another map that doesn't survive contact with the territory.

To discuss how Lime Institutional can design and deliver a blockchain solution for your financial infrastructure, visit limeinstitutional.com

This document is prepared by Lime Institutional for informational purposes. Client details have been anonymised at their request.