Ethereum L2 BB84 Drops Transaction Signatures to Counter Quantum Threat
Key Takeaways
- •BB84 has operated on Ethereum mainnet since September 30, replacing ECDSA signatures with keccak-256 hash-chain accounts to reduce exposure to future quantum attacks.
- •Payments on the network settle only in bridged USDC and EURC, with commit and reveal transactions free for users and a fresh one-time address generated for each recipient.
- •A front-running vulnerability in unsigned commits was discovered while drafting the research post and addressed on October 21 through a first-commit-wins rule, though griefing and rogue-sequencer risks remain.
- •The rollup has no fault proofs, so under L2BEAT's staging framework it would not even qualify as Stage 0, making withdrawals dependent on a permissioned proposer.
- •Hadamard suggests hash-chain validation could be adopted as an EIP-7702-style or native account-abstraction mode on general-purpose layer-2 networks, with a fuller write-up being prepared for arXiv.

BB84, an OP Stack rollup live on Ethereum mainnet under chain ID 42069000, has removed transaction signatures from its network entirely, replacing them with Lamport-style hash chains in a design intended to blunt the long-term quantum threat to conventional cryptography. The network has been running on mainnet since September 30. Its founder, who publishes under the pseudonym Hadamard, described the system in an October 24 Ethereum Research post and asked for critical feedback.
Ordinary Ethereum accounts authorize transactions with ECDSA signatures, which a sufficiently large quantum computer running Shor's algorithm could break. No machine capable of that exists today, but warnings about exposed wallet keys have pushed developers to search for alternatives — a key becomes publicly visible once an account has sent a transaction. Hash-based constructions are also among the oldest post-quantum candidates: Leslie Lamport proposed a hash-based signature scheme in 1979, and NIST's 2024 post-quantum standards include a hash-based scheme, SLH-DSA.
Hash-chain accounts, one step at a time
Each BB84 account is built from a secret that is hashed over and over with keccak-256 — the same hash function Ethereum itself uses — creating a chain of values in which only the last value is public. To pay, the wallet reveals the value before the current position, which anyone can check by hashing it once. The network then records that value and moves the account one step down the chain.
The protocol default is 1,000 payments per hash chain, while BB84's developer CLI creates 10-step chains for each one-time address. A step is consumed even if the payment itself fails, and the chain rejects any conventionally signed transaction.
Payments run only in bridged USDC and EURC. Both the commit and reveal transactions are free for users, and payers create a fresh one-time address for each recipient.
The security trade-off
The post spells out the design's limits. Inside the network, everything rests on keccak-256 being hard to reverse, and Grover's quantum search algorithm would cut that only to about 2^128 operations. Addresses, however, are shortened to 160 bits, which leaves about 2^80 of quantum resistance on the address itself. BB84's documentation advertises 128-bit post-quantum security without that caveat. Ethereum mainnet is also still ECDSA: deposits start from ordinary Ethereum wallets, and withdrawals pay out to them.
A front-running flaw found while writing the post
Revealing a secret makes it public, so anyone watching could copy it into a transaction paying themselves. To prevent that, the wallet first sends a commit transaction that locks the secret to one exact payment without showing it. The reveal must follow within five blocks by default.
The weak point was that commits carry no signature, because there is nothing to sign with. In the first version, a new commit simply replaced the pending one. An attacker who spotted a secret in a pending reveal could swap in a commit tying that secret to their own payment. Hadamard says the team found the flaw while writing the post and fixed it with a new rule that took effect on October 21. Under the revised rule, the first commit wins, the slot clears only after the matching reveal or expiry, the wallet waits for its commit to land in a block before revealing, and the public RPC does not expose pending transactions.
What the fix leaves open
Griefing remains possible: anyone can post a junk commit and block an address for up to five blocks, though they cannot move its funds. A rogue sequencer is another residual risk: if an honest commit expires or is reorganized out while its reveal is pending, the secret is no longer locked. Today only BB84's own sequencer sees pending transactions.
Hadamard suggests a stricter “Guy Fawkes” rule, in which commits are appended instead of replaced, but says it has not been built. The documentation goes further than the post, stating that commit and reveal mean a sequencer cannot steal a withdrawal.
A wallet that must not lose count
Because each chain has a fixed number of steps, the wallet has to renew it on the very last one by including a new commitment in that final payment. If it misses that step, the address is dead. Keeping count is just as important: Hadamard says the app and the chain fell out of sync in production, so wallets must be able to resynchronize from chain data.
The secrets still need protecting like keys. The CLI warns that its wallet file stores spend keys unencrypted and lists encryption as a roadmap item. Removing signatures changes how spending is authorized, not the need to keep secrets safe.
Withdrawals rest on a trusted operator
BB84 has no fault proofs. A permissioned proposer posts the network's state to Ethereum through a custom dispute game that resolves immediately, and with no proof system, Hadamard writes that by L2BEAT's framework the chain “would not even be Stage 0.” The framework grades rollups from Stage 0 to Stage 2 according to how far users must trust an operator rather than a proof system. Withdrawals therefore trust the proposer. The documentation still describes withdrawals as following the OP Stack fault-proof flow with a seven-day maturity delay, but as Optimism's explainer sets out, fault proofs exist so that wrong state can be challenged — and here nothing can be challenged during that wait. The sequencer is also run by BB84.
What would change the picture
The post closes with questions that reach beyond one chain. The biggest is whether hash-chain accounts could become an EIP-7702-style or native account-abstraction validation mode on general-purpose layer-2 networks, which would make the idea available without moving to a dedicated chain. EIP-7702, live since Ethereum's Pectra upgrade in May 2025, lets ordinary accounts take on smart-contract code. Hadamard adds that the extra checks are simple enough to prove with Optimism's existing Cannon tooling, that an append-only commit rule would close both the griefing and sequencer gaps, and that a longer write-up with the complete rules is being prepared for arXiv. Ethereum's wider migration effort, set out in its quantum roadmap, also covers validator signatures, data commitments and proof systems.
This article is provided for informational purposes only and does not constitute financial or investment advice. Experimental networks carry technical and custody risks.
Source: Coindoo