An Ethereum L2 that accepts zero signatures sounds like a security bug, but BB84 is doing it on purpose to dodge quantum attacks. Last weekend, its founder, who posts as Hadamard, published the design on Ethereum Research and asked for critical feedback. BB84 is an OP Stack rollup on mainnet, live since September 30, where L2 transactions carry no ECDSA at all. Each account is the tip of a keccak-256 hash chain built from a secret, with 1,000 steps by default. To spend, your wallet reveals the previous value in the chain, which anyone can verify by hashing once. Inside the L2, the only assumption left is preimage resistance of keccak-256, which Grover's algorithm cuts to about 2^128 work. Revealing a secret makes it public, so the protocol adds a commit and reveal step to bind each preimage to one transaction first. Two new transaction types in op-geth handle this, and the sender check replaces ecrecover. Authorisation is consumed even when the call reverts, and if a wallet misses the renewal step on the last link, that address is dead. The post includes a front-running flaw the team found while writing it. Commits carry no signature, so a new commit used to replace a pending one, and an attacker could rebind a revealed secret to their own payment. A rule that took effect on October 21 makes the first commit win. The limits are spelled out plainly. L1 deposits and withdrawals still use ECDSA. There are no fault proofs yet, and by the post's own account the chain would not even reach L2BEAT Stage 0. The sequencer is run by the team, and 160-bit addresses leave about 2^80 quantum second-preimage resistance. The post also asks whether hash-chain accounts could become an EIP-7702 or native account abstraction validation mode on general L2s.