Quantum Attack Vectors in Ethereum

Ethereum’s security relies on two kinds of cryptography:

Signatures: ECDSA for user accounts and BLS for validators and commitments.

Hashes: Keccak-256 for addresses and Merkle structures.

A quantum computer doesn’t threaten both equally. Shor’s algorithm breaks discrete log in polynomial time, which means asymmetric cryptography such as signatures based on elliptic curves stop being secure once public keys are visible (e.g. ECDSA on secp256k1 and BLS12-381). Grover’s algorithm only weakens brute force by a square root, which leaves hashes and symmetric crypto safe at current sizes.

This difference matters and is often misunderstood. When a cryptographically relevant quantum computer (CRQC) arrives, Ethereum’s hash-based structures continue to be secure, but its signature systems do not. The result is predictable, any place in the stack where control depends on an ECDSA or BLS, security guarantees no longer hold.

This post maps that attack surface as it exists today. The focus is on where keys are exposed, how they can be recovered, and what the impact looks like when that happens. The first practical attacks would not be against the mempool, they would be long, grinding recoveries of keys that have been visible on-chain for years. From there the consequences spread through accounts, contracts, consensus, rollups, bridges, and oracles.

An Ethereum EOA address is the last 20 bytes of keccak256(uncompressed_pubkey). If you have never signed anything that became public, your public key is not on-chain and your address is just a hash truncation. The moment you sign and broadcast a transaction, the signature reveals enough information to recover your public key via the (v,r,s) values. Public off-chain signatures do the same thing: EIP-712 typed data for orders and listings, permit calls for ERC-20 allowances, login challenges, and any random “sign this message to prove ownership”. If that signature is visible to anyone else, your public key is revealed (believed to be true for the vast majority of accounts).

Ethereum is account-based. You keep using the same address for years: ETH, ERC-20s, NFTs, approvals, governance, contract admin, etc. This is unlike Bitcoin’s UTXO model, where good address hygiene hides public keys until spend and retires them after; read more here. In Ethereum, identity is long-lived. Once a public key is visible, it tends to remain relevant as funds and permissions continue to flow through that same account. In a world where a CRQC exists, “public key visible” means “private key computable”. That holds forever, though the consequences only matter if the account still controls assets or permissions.

EOAs aren’t the only place public keys show up. Validators publish their BLS12-381 keys when they deposit, and those keys remain permanently visible in consensus state and are referenced to verify attestations and proposals. EIP-4844 introduces KZG commitments, where the structured reference string behind them is made of elliptic-curve points whose binding relies on discrete log hardness. zk-SNARK systems (Groth16/PLONK) post verification keys on-chain, which are themselves curve points. Bridges and oracles usually advertise the public keys of their signer sets. In all these cases the situation is the same, once the public material is visible, Shor’s algorithm makes the corresponding secret recoverable.

For completeness on Grover’s algorithm, if a public key has never been revealed, the address is just the last 20 bytes of keccak256(pubkey). Attacking it means finding some valid secp256k1 keypair whose hash ends with that 160-bit pattern. That is a truncated hash preimage problem. Classically the cost is about $2^{160}2^\{160\}$, Grover’s algorithm reduces it to ~$2^{80}2^\{80\}$. The attacker doesn’t need to find your original key, only a colliding one but even then, $2^{80}2^\{80\}$ quantum work is far beyond reach. In practice, never-spent addresses remain safe, for a more detailed analysis, see this paper. The risk begins the moment you sign, because that exposes the actual public key and makes recovery possible using Shor’s algorithm.

Long-grinding (at rest)

Any account whose public key is known can be recovered over a longer period of time, e.g. spent EOAs, admin EOAs, validator BLS keys, verification keys for curve-based SNARKs, KZG commitment material embedded in 4844’s structured reference string. There is no race against block time as those public keys are known today. This is most likely the first attack vector we will see, though it only matters if the recovered key still controls something of value.

Just-in-time (mempool)

When a signed EOA transaction hits the public mempool, the signature and therefore the public key is visible before inclusion. If key recovery can be done in a few seconds, the attacker submits a replacement with the same nonce and a higher fee and spends first. However, Ethereum’s ~12-second slot time compresses this window and thus this attack vector is not viable until quantum derivations are very fast.

How EOAs work

Ethereum has two types of accounts: Externally Owned Accounts (EOAs), which are controlled by a private key, and contract accounts, which are controlled by code. EOAs are what most people think of as “wallets”. They’re what MetaMask or a hardware wallet gives you. When you send a transaction, your wallet signs it with your private key, and the network checks the signature against the public key.

Quantum risk

We have covered how and when an EOA public key is revealed above. In simple terms, once an EOA’s public key has been revealed (on-chain via any transaction, or off-chain via a visible signature), a CRQC can recover the private key. From that point, an attacker can act as the account. Whether this matters depends on what the account still controls (funds, approvals, ownership of contracts). An empty account carries little practical risk.

Practical notes

• Nonces: Ethereum requires transactions from an account to be in order, using a sequential nonce. That only decides ordering. If an attacker already has your private key, they don’t need to race you; they are you.
• Hardware wallets: A Ledger or Trezor protects against malware stealing your private key. But they can’t protect against Shor’s algorithm inverting your public key once it’s revealed.
• Multisigs of EOAs: A multisig is just a set of EOAs with a threshold. It’s harder for a human attacker to compromise, but with a CRQC each EOA is just another discrete log to solve. There’s no new hardness assumption.

Impact

It’s hard to predict exactly how this plays out, we have written more about this here. But at a high level we can most likely expect in practice quiet, selective EOA wallets being drained. This could be any account from an exchange hot wallet, cold storage that moved coins once, or treasury EOAs. These will look no different from a regular transaction or a classical hack.

How they work

Smart contracts are anchored by code and storage committed in the state root. They don’t trust or even require signatures unless you put that logic into the code. However, that’s exactly what most control planes do.

Where signatures appear

• onlyOwner where the owner is an EOA.
• Upgradeable proxy contracts, where an admin EOA multisig decides what logic to point to.
• ecrecover-based checks for off-chain approvals: permits, meta-transactions, custom admin calls.
• Governance systems where proposals are voted on and authorized by committee members signing with ECDSA keys.

Quantum risk

With a CRQC, those signers are recoverable if their public keys have ever been visible. The attacker can now perform any action authorized by that key: upgrade proxies to malicious implementations, call admin functions, burn or mint at will, disable safeties, or drain treasuries. None of this relies on an EVM bug,  it works because the attacker can generate valid signatures with the recovered private key.

Impact

Similarly to EOA wallets, it’s impossible to tell exactly how this plays out but a likely scenario might look something like a major smart contract which uses a proxy with a 4‑of‑6 EOA multisig as the admin. For this example, imagine that the public keys of those six EOAs have been visible since 2021. On Q‑day, the attacker derives four keys, calls upgradeTo to a malicious implementation that siphons reserves, and then uses forged signatures to drain user allowances. The chain shows clean, valid calls. Nothing looks weird at the EVM level because the signatures verify according to the logic of the protocol.

You can read more about a quantum attack specifically on the Ethereum USDC smart contract here.

How it works

Ethereum’s consensus is run by validators. Each validator stakes 32 ETH and generates a BLS12-381 public key when they join. That key is used to sign their activity, attestations about blocks, and sometimes proposals for new blocks. These public keys are published up front when validators deposit, and they remain visible in consensus state for as long as the validator is active. With a CRQC, validators’ private keys can be recovered.

Quantum risk

• Forged participation. If enough validator keys are extracted, an attacker can produce signatures (attestations and proposals) that look like they came from honest operators, even though they didn’t. That undermines the voting process used to agree on the canonical chain.
• Equivocation and slashing. Validators are penalized (slashed) if they sign conflicting votes, for example, two different blocks at the same height. With stolen keys, an attacker can deliberately create these conflicts at scale. Honest validators then appear to misbehave, are slashed, and ejected. This reduces the pool of available validators and weakens consensus. Even without majority control, widespread slashing is enough to destabilize the chain and force exchanges and bridges to pause activity.
• Finality. Finality means that after a certain point, blocks can no longer be reverted. If participation drops or votes are forged, finality becomes unreliable. Even temporary instability here can break the assumptions that applications, exchanges, and bridges depend on. With a supermajority of keys under their control, an attacker could go further and steer finalized history deciding which chain fork becomes “the truth”.  Note, this requires an attack where a majority of validator private keys have been derived.
• Withdrawals. Validators eventually withdraw their staked ETH. The destination of those withdrawals is controlled by withdrawal credentials. Some validators still use BLS withdrawal credentials, meaning the same compromised key controls their exit. These are directly exposed to a CRQC. Others use execution-layer withdrawal credentials that send funds to an Ethereum address. If that address is an EOA, it’s extractable like any other. If it’s a contract wallet that doesn’t rely on ECC, it’s safer, but those are rarer today.
• Light clients and sync committees. Light clients don’t run full nodes, they rely on sync committees which are a rotating set of validators whose BLS signatures vouch for recent headers. If those committee keys are recoverable, an attacker can forge headers that convince light clients to follow a chain the full network would reject. This creates a split between what light clients believe and what full nodes enforce, and downstream systems that depend on light clients (mobile wallets, some bridges) inherit that confusion.

Impact

You don’t need a full “51% attack” to cause damage. Mass slashing is enough to paralyze finality and erode trust. Even a few hours of equivocating proposals and broken participation metrics could send clients into safety mode and exchanges into withdrawal freezes.

Ethereum’s scaling strategy relies heavily on rollups, systems that execute transactions off-chain and then post proofs back to Ethereum to show their state transitions are valid.

zk-rollups

Most production zk-rollups today use SNARKs such as Groth16 or PLONK over curves like BN254 or BLS12-381. The unforgeability of these proofs depends on the discrete log problem in elliptic-curve groups. Attackers with a CRQC can forge proofs that make invalid state transitions look valid to Ethereum. That could allow them to mint unbacked assets on the rollup, then withdraw them onto L1.

STARK rollups

STARKs on the other hand, are built entirely on hashes and error-correcting codes. As discussed, Grover’s only halves the brute-force cost of breaking them, which still leaves infeasible security margins at 256-bit sizes. STARK proofs remain sound against quantum adversaries. The catch is that many STARK-based systems still use ECDSA/EdDSA keys for their sequencers (who order transactions), for bridges, and for governance. Those weak links can fall even if the proof layer is secure.

Optimistic rollups

Another type of rollup, known as an optimistic rollup, assumes that transactions are valid by default, and only runs fraud proofs if someone challenges them within a time window. The challenge game is hash-based and theoretically quantum-safe. But the challengers themselves are EOAs signing with ECC. If their keys are forgeable, an attacker can impersonate or silence challengers, or push governance changes that disable fraud proofs altogether.

Bridges are one of the most exposed parts of Ethereum’s ecosystem because they concentrate large pools of value behind small signer sets. Their design varies, but the quantum risk is the same as they ultimately rely on signatures that can be forged once public keys are known.

Multisig-based bridges

Most generic token bridges work by locking assets in an escrow contract on Ethereum and issuing a wrapped version on another chain. To redeem, users submit a withdrawal request that must be approved by a set of off-chain signers. The bridge contract checks their ECDSA signatures against a known public key set. With a CRQC, those public keys are solvable. A 5-of-7 multisig is no longer five humans agreeing, it is five discrete logs to derive. Once the threshold is met, the attacker can instruct the bridge to release funds to themselves.

The result is direct loss of the escrowed assets and immediate depegging of the wrapped tokens on the other chain. Protocols that accept those wrapped assets as collateral become under-collateralized.

Canonical rollup bridges

Every rollup has an official bridge contract on Ethereum that enforces deposits and withdrawals. These bridges are supposed to be fully trustless: deposits are locked on L1, and withdrawals are only honored if a valid proof of the rollup’s state transition is submitted. But these contracts still have admin keys to upgrade logic, set parameters, or pause in emergencies. Those admin roles are usually EOAs or EOA-based multisigs. With a CRQC, those keys are extractable. That means the bridge logic itself can be upgraded or disabled by an attacker posing as the rightful admin. Even if the proof system remains sound (as in STARK-based rollups), the control plane around the canonical bridge can be taken over.

Impact

Bridges are systemic chokepoints: a single compromise can drain hundreds of millions of dollars in one move. They also link Ethereum’s credibility to that of other chains. When a bridge breaks, not only are users on both sides affected, but confidence in cross-chain assets across the ecosystem is shaken. Under quantum threat, bridges are simply signer sets waiting to be solved.

Oracles feed off-chain data into Ethereum: asset prices, event outcomes, cross-chain states, etc. Contracts depend on this data to liquidate loans, settle derivatives, and mint or redeem assets.

How they work

Oracle nodes sign reports with ECDSA keys. The consumer contract verifies those signatures against a known key set. Some designs require a threshold (e.g. 15-of-20 signatures) before accepting a feed.

Quantum risk

These public keys are exposed by design. Once recoverable, an attacker can forge reports. With enough keys to reach the threshold, they can publish values of their choice. That might mean pushing the ETH/USD feed down to trigger liquidations, inflating collateral values to mint stablecoins, or faking the outcome of an event to drain insurance pools.

Impact

Oracles are woven through DeFi. A compromised feed propagates into many protocols at once. By manipulating prices or outcomes, an attacker can force liquidations, mint unbacked assets, or trigger payouts, extracting direct profit while leaving protocols insolvent. The code executes as normal but on false inputs.

How it works

EIP-4844 (“proto-danksharding”) introduced blobs: large chunks of transaction data posted to Ethereum more cheaply than calldata. To make these blobs verifiable without storing all the data, Ethereum uses KZG commitments. A polynomial is committed to by evaluating it at a secret value τ and binding that to curve points. To prove a blob matches its commitment, you provide a short pairing-based proof. Light clients and rollups can then check the proof against the commitment without downloading the entire blob.

Quantum risk

The binding and soundness of KZG rely on the discrete log hardness of BLS12-381. Once again, with a CRQC, that assumption collapses. Attackers could forge evaluation proofs, i.e. blobs and commitments that don’t actually match but still verify as valid. Put simply, bad data can be made to look good.

Impact

This doesn’t let you break EVM execution rules inside blocks; transactions must still follow the protocol. The failure is in the data-availability layer, which rollups depend on to reconstruct their state. If blob proofs can be forged, light clients and rollups can no longer distinguish valid data from fabricated data. The guarantee that “Ethereum rejects invalid data” disappears, undermining the safety of rollups and any system built on them.

How it works

Ethereum’s transaction pipeline uses Proposer-builder separation (PBS). Validators propose blocks, but delegate ordering to builders who assemble transactions and send them via relays. Users can also submit directly to builders through private order-flow systems like Flashbots Protect, bypassing the public mempool to avoid frontrunning.

How it’s secured

These connections rely on elliptic-curve cryptography: devp2p (see below) uses secp256k1 ECDH handshakes, relays and RPC endpoints use TLS with ECC certificates, and builders sign attestations to prove authenticity. The assumptions are straightforward, you know who you’re talking to, and your transaction stays confidential until it lands in a block.

Quantum risk

With elliptic-curve crypto broken, these assurances vanish. Builders or relays can be impersonated. Private transactions can be intercepted, altered, or leaked back into the public mempool. Man-in-the-middle (MITM) and eclipse attacks, where a node is isolated and only hears attacker-controlled messages, become easier.

Impact

On their own, these are confidentiality and availability issues. Combined with forged validator keys or drained EOAs, they amplify censorship, misrouting, and erosion of trust in private submission. The promise of front-running protection collapses if authentication is unreliable. Longer term, as quantum machines accelerate, the public mempool itself becomes a theft vector through just-in-time key recovery. But that is a later-phase risk, the early quantum threat is broken trust in the private transaction supply chain.

How it works

Ethereum nodes discover and talk to each other using the devp2p protocol. To secure these connections, they perform an elliptic-curve Diffie–Hellman (ECDH) handshake over secp256k1. RPC endpoints (used by wallets, dapps, and infrastructure providers) are usually protected by TLS, which again relies on ECC certificates and key exchange.

Quantum risk

With a CRQC, these guarantees fail. Attackers can impersonate peers or servers, intercept and decrypt traffic, and eclipse nodes by feeding them only attacker-controlled data. A user may believe they are connected to Ethereum when they are only talking to an attacker.

Impact

This layer doesn’t directly move funds, but it underpins the network’s resilience. If connections can’t be trusted, monitoring and observability tools break, incident response falters, and censorship-resistance weakens. In a quantum incident, when forged keys and proofs are already causing confusion, the loss of reliable communication makes coordination and recovery much harder.

Smart contracts

There are practical ways today to remove elliptic curves from your smart contract authorization boundary. Smart accounts can verify signatures in code. ERC-1271 standardizes isValidSignature for contracts. ERC-4337 lets accounts define custom signature checks. That means wallets can already require post-quantum signatures, e.g. hash-based (SPHINCS+/SLH-DSA, XMSS, etc.) or lattice-based (Dilithium/ML-DSA, Falcon/FN-DSA). These are heavier than ECDSA, but may be acceptable for governance and high-value transactions. We cover post-quantum signature algorithms more on our blog.

EOAs

Externally owned accounts are the weakest link under quantum threat, because once a public key has been revealed it is recoverable. Two practical options exist today:

• Move funds to a fresh address that has never signed. This keeps the public key hidden and safe until you spend again. It’s a temporary measure as the first time you sign, the key is exposed.
• Migrate to a smart contract wallet. See above re post-quantum smart contracts.

We can split Ethereum’s cryptography into two distinct groups. Hashes and symmetric primitives remain secure against Grover’s algorithm. Elliptic-curve signatures (ECDSA and BLS12-381) do not survive Shor’s. That distinction defines the attack surface.

Once a cryptographically relevant quantum computer (CRQC) exists, any public key already exposed on Ethereum becomes extractable. That includes EOAs that have ever signed a transaction or message, validator keys published at deposit, multisigs, bridge committees, oracle signers, SNARK verifiers, and the elliptic-curve commitments behind EIP-4844. The first attacks will be long-grinding recoveries of keys already exposed. Mempool attacks are likely to arrive later, when hardware is fast enough to solve keys inside block times.

On Q-Day this could mean drained wallets, captured admin roles, forged rollup proofs, slashed validators, drained bridges, falsified oracle data, and unreliable data-availability checks. In short, any part of the system where authorization depends on an ECDSA or BLS signature loses its security guarantees. Hash-based surfaces, addresses that have never signed, Merkle structures, and STARK proofs remain safe at current parameters.

Some defenses can be applied today. Users can move funds to never-spent addresses or migrate to contract wallets with post-quantum verification. Protocols can replace EOA admins with contract accounts that check post-quantum signatures. These steps don’t require a protocol fork and move high-value assets out of the elliptic-curve blast radius. But full resilience will require protocol-level changes: post-quantum signature support for accounts, validators, and commitments.

Quantum progress is accelerating faster than most people think. See here, here and here. The hardest operational problem isn’t choosing a post-quantum suite; it’s rotating the vast set of already-exposed keys without breaking continuity. The ecosystem needs a standardized way to migrate authority at scale: users, contracts, bridges, sequencers, validators. The migration path matters as much as the destination.