Making Solana Quantum-Resistant: Hidden Keys, Merkle Roots, and a Two-Second Window

We've spent most of our time talking about Ethereum. But if you look at the actual exposure numbers, Solana has the more urgent problem, and almost nobody is saying it out loud.

According to Project Eleven's 2026 report, about 65% of Ethereum sits in quantum-vulnerable addresses. On Solana, that number is 100%. Every single account. By design.

Let me explain why Solana is structurally worse, and then walk through the specific construction we use to fix it, which comes down to one idea: never leave a usable public key sitting on-chain.

Why every Solana account is exposed, not just some

On Ethereum, your public key only becomes visible when you spend. An address that has only ever received funds keeps its public key hidden behind a hash. That's why "only" 65% of ETH is exposed, the accounts that never spent are still dark.

Solana doesn't work that way.

On Solana, your account address is your Ed25519 public key. The key is the address. It sits on-chain from the moment the account exists, whether or not you've ever signed anything. There's no hash layer, no address type that keeps it dark. The report's phrasing is blunt: Solana exposes the public key for every address, which renders all of Solana quantum-vulnerable.

So "harvest now, decrypt later," the attack where an adversary records exposed keys today and cracks them once quantum hardware exists, is trivially easy on Solana. There's nothing to wait for and nothing to intercept. Every public key for every account is already published. An attacker just downloads the chain.

Solana's speed makes it worse

Here's the cruel irony. Solana's headline feature, throughput, is also a quantum liability. The chain processes tens of thousands of transactions per second, each one touching public keys, and the assets behind those keys run into the billions across DeFi, staking, NFTs, and SPL tokens. Every dollar of it is secured by Ed25519, and Ed25519 falls to Shor's algorithm exactly the way Ethereum's ECDSA does.

100% exposure, the fastest exposure rate in crypto, billions at stake. Solana needs an account-level fix more than Ethereum does, not less.

The core idea: a key nobody can see is a key nobody can break

Most quantum defenses focus on replacing the signature algorithm with a post-quantum one. That's necessary eventually, but on Solana the lattice schemes are heavy (a Dilithium signature is roughly 38x larger than Ed25519), which fights the chain's whole performance model.

So we start somewhere different. Instead of immediately swapping the algorithm, we attack the thing that actually makes Solana vulnerable: the public key sitting permanently on-chain.

What if the key were never there until the exact moment you needed it, and gone again seconds later?

That's the mechanism behind QP2's first Solana verifier.

How the Merkle-root account works

Here's the construction, step by step.

1. Generate a batch of fresh keys. When you set up the account, you generate N fresh keypairs (today these are Ed25519). Not one key, a whole batch.

2. Commit only the Merkle root. You build a Merkle tree over the N public keys and publish only the root hash on-chain as your account's commitment. None of the actual public keys are revealed. All an observer sees is a single root hash, which leaks nothing a quantum computer can attack, because there's no curve point in a hash.

3. Spend by revealing one leaf, with a proof. To make a transaction, you take one unused key from the batch, sign with it, and reveal that key plus a short Merkle proof showing it's a genuine leaf under your published root. The network verifies the proof against the root and checks the signature. The key is now used.

4. The exposure window is seconds. That revealed public key is only visible for the brief moment the transaction takes to confirm, which on Solana is roughly one to two seconds. After that, the key is spent and never used again. It's a one-time key.

5. Refresh the root with fresh keys. As the batch runs low, the account commits a brand-new Merkle root over a brand-new batch of fresh keys. The old keys are retired. The address never changes, only the committed root does.

Why this kills the realistic attack

Look at what this does to each attack:

Harvest now, decrypt later is eliminated. This is the big one. The whole attack depends on exposed public keys being available to record today and crack later. In this design there are no exposed public keys to record. Until the instant you spend, every key is hidden behind the Merkle root. There's nothing in the historical ledger to harvest, because keys are revealed one at a time, used once, and retired. An attacker scraping the chain finds root hashes, not attackable keys.

The live attack shrinks to a two-second window. The only moment a public key is ever visible is during confirmation. For a quantum attacker to exploit that, they'd have to observe the revealed key and derive the private key and land a competing transaction, all inside the one-to-two-second window before the key is spent and dead. Solana's fast finality, usually a liability for exposure, actually works in your favor here: the window is tiny.

So with keys that are still Ed25519 today, this design already removes the attack that actually matters, the patient one, the harvest-and-wait. What remains is a problem that's seconds wide instead of years wide.

Being honest about what this is, and isn't

We're not going to tell you Ed25519 keys are quantum-proof. They aren't. If a quantum computer existed that could break a key inside a two-second window, the live attack would still be theoretically possible, even though the harvest attack is gone.

That's exactly why this is a verifier, not a final answer.

QP2's whole architecture is built on one principle: the signing scheme is a swappable component behind a permanent identity. This Merkle-root construction is the first verifier we ship for Solana, because it's light, it works within Solana's compute budget, and it eliminates the realistic attack today. But the leaves don't have to stay Ed25519.

As post-quantum schemes mature, we add verifiers whose leaves are FALCON or ML-DSA keys, the same Merkle structure, now with mathematically quantum-proof keys at every leaf. Users switch to them with a single transaction. Same account, same address, the exposure-minimization benefit plus true post-quantum keys underneath.

So the path is:

• Today: hidden keys behind a Merkle root, seconds-long exposure, harvest-now-decrypt-later eliminated, on Ed25519.
• Tomorrow: switch to a verifier with post-quantum leaves, fully quantum-proof, one transaction, address unchanged.

You don't have to predict when Q-Day lands. You close the realistic attack now and keep a one-transaction upgrade in your pocket for when the lattice schemes are ready.

Why this fits Solana specifically

Two reasons this construction is well-suited to a high-throughput chain.

First, it's cheap. Verifying a signature plus a Merkle proof is mostly hashing and one signature check, exactly the kind of work Solana's runtime is fast at, rather than the heavy verification of a large lattice signature. You get the protection without immediately fighting Solana's compute and byte limits.

Second, it builds on something Solana already has: keyless addresses. A Program Derived Address has no Ed25519 key behind it at all, it's off-curve by construction. A QP2 account on Solana lives at a PDA, holds the Merkle root in its state, and is driven entirely by the QP2 program gated by the active verifier. There's no root key sitting exposed, because the identity was never a key in the first place.

The takeaway

Solana's quantum problem is bigger than Ethereum's, not smaller. 100% of accounts exposed versus 65%, the fastest key-exposure rate in crypto, billions behind already-public Ed25519 keys.

The fix doesn't have to wait for heavy lattice cryptography to ship chain-wide. By hiding keys behind a Merkle root and exposing each one for only the seconds it takes to confirm, QP2 eliminates the harvest-now-decrypt-later attack today, and because the verifier is swappable, the same account upgrades to fully post-quantum keys later with a single transaction and no change of address.

Your address stays. Your security evolves. On Solana too.

QP2 — Quantum Proof Protocol. We're building quantum-resistant accounts for EVM and Solana. -> qp2.org

Sources: Project Eleven 2026 quantum exposure report (65% ETH / 100% SOL vulnerable); Google Quantum AI ECDSA resource-estimate paper (March 2026); Solana account structure and Program Derived Address documentation. Informational, not investment advice.