A live Ethereum layer-2 network has dropped transaction signatures entirely, and its founder has published where the design still breaks, including a front-running flaw found and fixed before publication.
Key Takeaways
- Live on Ethereum mainnet since September 30.
- Protocol default: 1,000 payments per hash chain.
- Front-running flaw found and fixed on October 21.
The founder, who posts as Hadamard, described the design in an October 24 Ethereum Research post and asked for critical feedback.
Ordinary Ethereum accounts authorize transactions with ECDSA signatures, which a large enough quantum computer running Shor’s algorithm could break. No machine today can do that, but warnings about exposed wallet keys have pushed developers to look for alternatives. BB84, an OP Stack rollup on Ethereum mainnet with chain ID 42069000, removes signatures from its network altogether.
Each account is built from a secret that is hashed over and over with keccak-256, creating a chain of values. Only the last value is public. To pay, the wallet reveals the value before it, 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 steps, while BB84’s developer CLI creates 10-step chains for each one-time address. A step is used up 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 post spells out the security trade-off. Inside the network, everything rests on keccak-256 being hard to reverse, and Grover’s quantum search algorithm only cuts that 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.
The 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 it, 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 does not cover
Griefing: anyone can post a junk commit and block an address for up to five blocks, though they cannot move its funds.
A rogue sequencer: 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. BB84’s 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.
Getting money out means trusting the 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.” 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 wrong state can be challenged, and here nothing can be challenged during that wait. The sequencer is also run by BB84.
| Stage | What the user trusts |
|---|---|
| Deposit from Ethereum | An ordinary ECDSA wallet and the bridge contract |
| Payment on BB84 | The hash-chain secret, the commit rule and BB84’s sequencer |
| Standard withdrawal, 7 days or more | The permissioned proposer |
| Merchant fast withdrawal, 2 hours | The proposer plus a registry operator |
What would change the picture
The post ends 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.
Fault proofs: Hadamard says the extra checks are simple enough to prove with Optimism’s existing Cannon tooling.
A safer commit rule: the append-only design would close both the griefing and sequencer gaps.
A full paper: a longer write-up with the complete rules is being prepared for arXiv.
Ethereum’s wider migration: 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.
Be the first to comment