Post-Quantum Blockchain Accounts, Explained

How it works, in 60 seconds

A quantum computer breaks the elliptic-curve signatures blockchains use to approve transactions. Swapping in a post-quantum signature works but is 14 to 72 times more expensive to verify on-chain, on every transaction, forever.

So this work drops signatures instead. You commit to hash(secret) ahead of time, then later reveal the secret to authorize; the contract just checks the hash. Security now rests on hash preimage resistance, which quantum computers barely dent, not on elliptic curves, which they break.

The hard part is not the crypto, it is the systems fallout: the reveal is a public race an attacker can join, and once signatures are gone the account must re-authenticate every transaction field itself (binding completeness). The paper builds the account, breaks it, fixes it, and measures it, deploying a signature-free version on a live network at about 1.4x the cost of an ordinary account.

The question

If a powerful quantum computer arrived tomorrow, how could the blockchain accounts that already exist keep operating safely, without waiting years for the underlying protocol to upgrade?

Almost every blockchain today, Ethereum and Bitcoin included, authorizes transactions with elliptic-curve signatures (ECDSA and its relatives). That math is what proves "yes, the owner of this account approved this transaction." A large enough quantum computer running Shor's algorithm can recover the private key from the public key, which means it can forge that approval and move other people's money.

The obvious response is: swap the elliptic-curve signature for a post-quantum one. The math for that already exists and is standardized (ML-DSA, SLH-DSA, and others).

The problem is cost. Verifying a post-quantum signature on-chain is heavy, and that cost is paid on every single transaction, forever, replicated across every node in the network. Measured against a plain account today, on-chain post-quantum verification runs anywhere from 14 to 72 times more gas depending on the algorithm.

The different idea

This research takes another route. Instead of replacing one signature with a more expensive signature, it asks whether authorization can drop signatures altogether.

It can, using a decades-old trick called commit-reveal. You do not sign anything. Instead:

Today: sign every transaction

1. Hold a private key

2. Produce an ECDSA signature

3. Contract verifies the signature

Broken by a quantum computer

Commit-reveal: no signature

1. Pick a random secret

2. Store hash(secret) on-chain (commit)

3. Later, reveal the secret

4. Contract checks the hash matches

The security assumption changes completely. It no longer rests on elliptic curves, which quantum computers break outright. It rests only on the fact that you cannot run a hash backwards to find its input. Quantum computers barely dent that: Grover's algorithm gives a square-root speedup, so a 256-bit hash still leaves roughly 128 bits of security even against a quantum attacker. That is comfortable.

So why has nobody shipped this?

The idea itself is old. Versions of hash-based authorization have been floated since at least 2014. The reason it does not exist as a real, deployed account type is not the cryptography. It is a set of practical engineering problems that turn out to be much harder than "just verify a signature." This project is really about finding, analyzing, and fixing those problems. Three of them stand out.

Problem 1: the reveal is a public race

The moment you broadcast your secret to reveal it, everyone watching the network can see it. An attacker copies it instantly and submits their own competing transaction. Now two transactions are racing to land in the next block:

your reveal        →  ?
attacker's reveal  →  ?
whoever lands first wins

This stops being a cryptography question and becomes a distributed-systems one. The research models this race formally and derives the probability of theft as a function of things like how much of the network an attacker controls, how blocks get built, network timing, and censorship. The payoff is that quantum key theft turns from an inevitability into a measurable, boundable risk. One sharp finding: when block production is concentrated in a few hands rather than spread out, the risk gets meaningfully worse, by a factor of roughly a hundred in the modeled cases.

Problem 2: account abstraction makes it harder, not easier

Ethereum is moving toward "account abstraction," where accounts are smart contracts with programmable rules. A common assumption is that this makes post-quantum migration easier. It does the opposite, and understanding why is one of the paper's main contributions.

An ordinary signature quietly does more than prove identity. It also authenticates every field of the transaction at once: the destination, the amount, the gas, the fees, the data. Change any one of them and the signature no longer matches.

destination · amount · gas · fees · data · nonce
        ↓
one signature covers all of them

Take the signature away and that guarantee vanishes. Suddenly the various parties who help get your transaction on-chain (bundlers, sequencers, relayers) may be able to alter fields you never approved. So the account itself now has to explicitly re-authenticate every field that has financial consequences. The paper names and formalizes this requirement:

Binding completeness

Once protocol-level signatures are gone, the account must cryptographically commit to every field that can move value or cause harm. Miss even one, and an attacker may be able to steal tokens, inflate fees, drain the account's gas deposit, or force denial of service. During this work several such gaps were discovered as real, exploitable bugs, each demonstrated, fixed, and turned into a permanent regression test. That catalogue of failure modes became a core result.

The honest catch: relocated, not eliminated

Signatures do not fully disappear on today's Ethereum

On Ethereum's main layer as it exists now, even a commit-reveal account still sits inside an outer transaction that a bundler wraps in an ordinary elliptic-curve signature. So the quantum-vulnerable envelope is moved onto a third party, not removed. The paper proves there is no signature-free path to inclusion on mainnet today.

Where signatures genuinely leave the authorization is on chains with native account abstraction. This work deploys and measures exactly that on zkSync Era, a live public test network, and shows the account authorizing with no elliptic-curve signature at all. The twist: the front-running race from Problem 1 then lands squarely on the single sequencer that orders that chain's transactions. The envelope keeps moving; it does not vanish. That "you can relocate it but not eliminate it" arc is the spine of the paper.

It was actually built

This is not a thought experiment. The project ships a working implementation: EVM smart contracts, an ERC-4337 account-abstraction version, a native-AA version deployed to zkSync Era, Monte-Carlo simulations of the front-running game, adversarial red-team testing, replay against two years of real historical gas prices, and a full regression suite. The working rule throughout was strict:

Every attack we think of gets demonstrated against the real implementation first, then fixed, then locked in as a permanent regression test.

On the live zkSync test network, authorizing through this account cost about 1.4 times a plain elliptic-curve account per action, same order of magnitude, while needing no signature verification. Anyone can reproduce the offline results with a single command against a public container image (linked at the bottom).

What the research contributes

Not one algorithm, but a set of results:

A practical post-quantum account that authorizes with no post-quantum signature verification in the hot path.
A formal analysis of the reveal race, turning "will the key get stolen" into a derived probability, and showing how validator concentration changes it.
Binding completeness, a framework for reasoning about which transaction fields must be re-authenticated once protocol signatures are gone. It likely applies well beyond this one construction.
A security taxonomy of previously undocumented attack classes, each found, exploited, fixed, and regression-tested during the build.
Honest cost accounting: roughly 14 to 72 times cheaper on Ethereum layer 1 than on-chain post-quantum verification, while staying compatible with today's infrastructure.

What this is not

It does not propose a new blockchain.
It does not invent a new post-quantum algorithm.
It does not compete with NIST standards like ML-DSA. If anything, it is a bridge for the years before those standards are cheap to run on-chain.

It is a systems-engineering result, sitting where blockchain, cryptography, distributed systems, smart-contract security, and account abstraction meet.

Why it matters

Chains will eventually support post-quantum cryptography natively, through protocol upgrades or dedicated built-in operations. But protocol changes take years, and the threat does not wait for them. This work is about that in-between period: it shows there is a migration path that runs on the infrastructure we already have, cuts the on-chain cost dramatically, gives a measurable rather than hand-waved level of protection against a quantum attacker, and, in the process, surfaces a whole new class of security questions that account abstraction raises once you take signatures away.

How do you safely redesign blockchain account authorization for the post-quantum era, using the infrastructure that exists today?

Answering that meant combining cryptography, distributed systems, protocol design, smart-contract engineering, adversarial analysis, and real measurement into one end-to-end system.

Ongoing: from revealing secrets to one-time signatures

The account above authorizes by revealing a secret. A newer line of work, including post-quantum accounts from the Ethereum Foundation and others, replaces the reveal with a one-time hash-based signature: instead of showing a secret, the account signs the exact transaction with a key it will never use again. That removes the public reveal race, because the signature already names the single action it authorizes and nothing else.

The catch is this project's theme, one layer deeper. A one-time key is catastrophic to sign twice: a second signature on the same key lets an attacker forge an arbitrary transaction with ordinary, non-quantum computing. And "sign this key only once" is a rule the blockchain cannot enforce, because the dangerous event, producing that second signature, happens off-chain inside the wallet before any transaction exists to check. An attacker who can reorganize recent blocks, censor a transaction past its deadline, or desynchronize two of your devices can try to force that second signature. The race was never eliminated; it relocated a second time, from the order of transactions in the mempool to the state of the key in your wallet.

This part is analysis, not a deployment. It models that "forcing" attacker, shows that the sign-once rule cannot be enforced on-chain (only priced and bounded), and works out which wallet discipline and which signature parameters stop an attacker from ever forcing a forgery. A Monte-Carlo simulator now measures it: with those disciplines in place a forced forgery never occurs across the whole range of attacker strength, and what remains is a bounded delay and a leaf-consumption cost that mostly reduces to waiting for the chain to finalize. The one thing that does not reduce to waiting is the ordering game from Problem 1 resurfacing here: an attacker who controls transaction ordering can still land a stale, already-superseded action in place of the owner's corrected one. Three working pieces specify and measure it: the message-bound signature spec, the state-management analysis, and the forcing-adversary simulator. It is exploratory and shared as work in progress, alongside the reviewed paper above.