Optimism Cannon

Submit a Bug
08 March 2022
Live since
KYC required
Maximum bounty

Program Overview

The cannon (cannon cannon cannon) is an on-chain interactive dispute engine implementing EVM-equivalent fault proofs. Half geth, half MIPS, ALL awesome.

It's Go code

  • that runs an EVM
  • emulating a MIPS machine
  • running compiled Go code
  • that runs an EVM

This is not a system deployed to prod. It is a repo targeting 1:1 recalculation of L1 EVM blocks within a fraud-provable system.

For more information about Cannon, please visit:

Special Case

Only a maximum of five bounties will be paid (for a total prize pool of 250,000 USD). The bounty program will initially be scheduled for a up to a period of one month starting from this announcement (up until May 9th, 2022).

The Optimism team will evaluate any claim received during that period, on a first-come, first-serve basis. If the claim is found valid, the bounty will be paid out, and payouts will be suspended while the team works on fixing the disclosed bug.

Any subsequent report of the same bug after the initial claim will not give rise to a bounty payment, neither will slightly different bugs of the same class (See Below).

Below: The same class is defined as similar or related bugs that we would naturally have been fixed as a result of having received the initial claim. Therefore, if the bug is still exploitable after the bounty program restarts (using the "fixed" code), it will still be eligible for bounty payment.

The Optimism team may (but are not obligated to) evaluate some of the received claims even while payouts are suspended. If they determine that the claim is valid and the bug is different from the one that caused the suspension of payouts, another bounty will be paid out if possible.

After the fixes, the bounty program will be restarted with a refreshed duration of one month (using a new reference commit). Claims previously submitted but not already evaluated will retain their priority, but will be evaluated against the new commit. Things then proceed as above.

This process continues until either all five bounties have been paid out, or one month elapses during which no valid claims have been turned in.


Refer to the https://github.com/ethereum-optimism/cannon repository for instructions.

In particular, bug bounty hunters should look at demo scripts such as this one to understand the Cannon setup.

Before your get your head down in the details, read through

Make sure to stay up to date with new developments on the repository as the Optimism team might add tools there that will make your life easier (such as an automated challenger/defender agent).

This bug bounty program is focused on their blockchain infrastructure and smart contracts and is focused on preventing the following critical vulnerabilities:

  • Any bugs which will cause a challenge to be successfully performed against a valid L1 block, ie. a block for which Cannon has a different execution result than the L1 blockhash.
  • Any bugs that will allow for the creation of an invalid L1 block which cannot be successfully challenged

The following additional non-critical cases may be rewarded:

  • Any bugs that allow for the successful crafting of a valid L1 block such that it takes more than 30 minutes on a recent Macbook to generate all the required data to successfully complete the fault proof.
  • Any bugs which are not directly exploitable given the minigeth MIPS executable, but could be if another program were run.

A more precise statement of these criteria can be found below.

Rewards by Threat Level

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported. However, please refer to the Impacts in Scope section for proper classification of vulnerability severities. Bug reports that normally fall under the severity classification system but do not appear in the Impacts in Scope section are not eligible for a reward.

All reports for critical bugs must come with a PoC with an end-effect impacting an asset-in-scope in order to be considered for a reward. Explanations and statements are not accepted as PoC and code is required.

Low-impact bugs are bugs that might not be directly exploitable using the assets-in-scope. Reports for low-impact bugs must also come with a PoC supporting the claim being made, even though this PoC might not be an exploit.

See below (“Impacts in Scope”) for more details on the criteria by which the bounties for both critical and low-impact bugs can be claimed.

This bug bounty program will also have a hard cap for critical rewards of USD 250 000, meaning that the critical reward can be paid out a total of 5 times. Rewards for duplicate bug reports are only paid out once, to the first valid report that was submitted. In the event that multiple critical bug reports are submitted that exceed this amount, the rewards will be provided on a first come first served basis. All critical reports submitted after the first 5 valid reports will not be eligible for any payout.

Optimism requires KYC to be done for all bug bounty hunters submitting a report and wanting a reward. The information needed is an invoice with the hacker’s name and address.

Payouts are handled by the Optimism team directly and are denominated in USD. However, payouts are done in USDC.

Smart Contract

USD $50,000
PoC Required
USD $5,000
PoC Required

Assets in scope

All smart contracts of Optimism: Cannon can be found at https://github.com/ethereum-optimism/cannon/ with the Reference Commit 04f331f512f19dedbaaea210f435f74b6e3b8b3e. However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.

Prioritized Vulnerabilities

Impacts in Scope

Only the following Critical impacts vulnerabilities are accepted within this bug bounty program. All other impacts will not be considered, even if they affect something in the assets-in-scope table. Further information about each impact can be found below.


  • You can successfully challenge a valid L1 block
  • You can craft an L1 block with an invalid state root that cannot be successfully challenged (see exception below).


  • You can successfully craft a valid L1 block such that it takes more than 30 minutes on a recent Macbook to generate all the required data to successfully complete a fault proof.
  • Bugs which would not be exploitable on the repo as-is, but are identifiably “bugs,” and could be exploited if those components are used differently

Additional information:

  1. (Critical) You can successfully challenge a valid L1 block.

To claim this condition, you need to demonstrate (probably using a script of some sort) that you can create an L1 block that is valid (i.e. a miner could produce a similar block on mainnet and it would pass of the validation rules and become part of the chain) and that you can successfully challenge the block via the Challenge.sol contract, leading up to successful call to a non-reverting call to the ConfirmStateTransition function which does emit the ChallengerWins event.

  1. (Critical) You can craft an L1 block with an invalid state root that cannot be successfully challenged.

To claim this condition, you need to demonstrate that you can create a block which would otherwise be valid, but is invalid due to an incorrect state root, and show that this L1 block cannot be successfully challenged using Cannon, assuming that the defender behaves honestly (e.g. it is well known that, amongst other things, the challenge cannot be completed if the defender stops answering).

Note that you can't include an invalid block in an Hardhat or geth node by default. So to demonstrate this bug, you will need to set up your own geth node (we insist on geth vs other clients to help us evaluate the claim), and modify the validation logic such that it will accept your invalid block.

Alternatively, you could also demonstrate the bug by modifying the Cannon contracts so that they do not validate the state root. However, you would have to find a way to retrieve the preimages necessary to play the challenge game (as by default, they are retrieved from a local node).

The challenge process should end with a non-reverting call to the DenyStateTransition function which does emit the ChallengerLoses event.

Exception: Finding a case where a preimage cannot be fetched in the x64 version of minigeth (“prefetch mode”), resulting in a message of the type “can't find preimage 0x…” will be considered a low-impact bug, if it is fixable solely in the pre-fetching logic (without any corrections to the on-chain contracts). If the bug is due to a request for a pre-image which is fundamentally unknowable (such as 0x000000…), this would still count as a high-impact bug.

  1. (Low) You can successfully craft a valid L1 block such that it takes more than 30 minutes on a recent Macbook to generate all the required data to successfully complete a fault proof.

This should be assessed by how long it takes to run a script like the simple demo script to complete a fault proof over the block you supply. Performing such a fault proof is almost only "generation" (this includes running the block validation to various execution steps). Blockchain execution and communication overheads are negligible, but should not be counted towards the total.

The generation time will be accessed on a laptop owned by Optimism PBC.

The generated data includes:

  • the initial MIPS memory checkpoint generated by mipsevm/mipsevm
  • the preimages for the block validation, generated by minigeth/go-ethereum $BLOCK
  • the final MIPS memory checkpoint, generated by mipsevm/mipsevm $BLOCK
  • all the intermediate MIPS memory checkpoints necessary to play the challenge game (log2(n) where n is the length of the execution trace)
  1. (Low) Bugs which would not be exploitable on the repo as-is, but are identifiably “bugs,” and could be exploited if those components are used differently.

An example of such a low-severity exploit would be: “It is possible to trigger a divergence between the off-chain and on-chain MIPS execution given a custom MIPS executable, but which can NOT be triggered with the standard minigeth MIPS executable generated during the cannon build process”.

Out of Scope & Rules

The following vulnerabilities are excluded from the rewards for this bug bounty program:

  • Attacks that the reporter has already exploited themselves, leading to damage
  • Attacks requiring access to leaked keys/credentials
  • Attacks requiring access to privileged addresses (governance, strategist)
  • Attacks involving the already know ‘large preimage’ problem. We are aware of it, and research into mitigations is ongoing.

Smart Contracts and Blockchain

  • Basic economic governance attacks (e.g. 51% attack)
  • Best practice critiques
  • Sybil attacks
  • Centralization risks

The following activities are prohibited by this bug bounty program:

  • Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
  • Any testing with pricing oracles or third party smart contracts
  • Attempting phishing or other social engineering attacks against our employees and/or customers
  • Any testing with third party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
  • Any denial of service attacks on mainnet or public testnets
  • Automated testing of services that generates significant amounts of traffic
  • Public disclosure of an unpatched vulnerability in an embargoed bounty