Optimism Fault Proofs — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Optimism Fault Proofs, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed Optimism Fault Proofs reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Bridge exploit, Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Bridge exploit findings disclosed against Optimism Fault Proofs
- Logic error findings disclosed against Optimism Fault Proofs
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Optimism Fault Proofs: Incorrect game type can be proven and finalized due to unsafe cast
In Optimism's Fault Proof system, the `raw()` helper used by OptimismPortal2 to compare a dispute game's type against the portal's respected game type unsafely downcasts the 32-bit `GameType` to `uint8`, so any two game types sharing the same low byte are treated as identical. Because the off-chain challenger only watches games of the current respected type, an attacker could create an old, unmonitored and known-exploitable game (e.g. type 0 while the portal respects 256) and use it to prove and finalize an invalid withdrawal, draining portal funds. The upstream team fixed it by returning `uint32`, and the issue was judged medium severity after extensive debate about exploitability constraints.
Optimism Fault Proofs: Theft of initial bonds from proposers who are using smart wallets
Optimism's DisputeGameFactory creates fault dispute games and records the root claim's claimant using tx.origin, while the attached msg.value becomes the initial bond that is later refunded to that claimant. Because smart wallets such as Gnosis Safe authenticate transactions off-chain and accept execution from any submitter, an attacker can monitor the mempool for a proposer's signed proposal, replay the identical call from their own EOA so it lands first, and thereby become registered as the claimant of an honest claim and collect the bond at game resolution. The protocol team characterized this as an intended EOA-only footgun but still fixed it by having the factory pass the real msg.sender to the game (PR #10149). The finding was upheld as Medium after escalation on the grounds that the root cause sits in the factory and the DelayedWETH safety mechanism is not bypassed, with the theft constrained to the smallest root-level bond.
Optimism Fault Proofs: Loss of bond amounts on re-org attacks
Optimism's fault-proof dispute game lets a participant challenge a claim by passing only a parent claim index plus a move commitment, without cryptographically binding the move to the exact claim it targets. Because Ethereum mainnet blocks can be reorged between transaction submission and execution, the claim occupying that index can change, silently redirecting the challenger's move to a different (possibly valid) claim. An attacker can plant an invalid bait claim, let defenders race to refute it without waiting for finality, trigger a reorg that swaps in a valid claim at the same index, and collect all the defenders' now-wrongful bonds. At high game depths the bonds are large, so honest participants could lose substantial funds before the fix required every move to carry the target claim hash and its Position in the game tree.
Optimism Fault Proofs: Fault game factory can be manipulated to DOS game type using malicious `l2BlockNumber`
Optimism's dispute game factory lets anyone create a fault dispute game while passing an arbitrary L2 block number in the immutable extraData. That number is only checked against the latest anchor root in the AnchorStateRegistry during initialization, so an attacker can pass type(uint256).max. Because the fault dispute game computes the disputed L2 number from the trace index rather than the supplied extraData, the passed number is never bound to the proven output, and once a resolved game updates the registry, the anchor becomes type(uint256).max, causing every subsequent create() for that game type to revert with UnexpectedRootClaim. This permanently DoS the game type, blocking new L2-to-L1 withdrawals and message finalization through it until an admin acts. The finding was adjudicated as a valid Medium, justified by the trusted proxy-admin owner who can detect the anomalous block number and switch game type within a 72-hour SLA.