LibraryScaling2023Design paperCorpus record
The Fault Proof System
Optimism Cannon. Optimism.
A dispute walks a single instruction of a state transition on a parent chain, so anyone who can post a bond can force the on-chain step that decides a bad proposal.
A reading of the public document. Not a copy of it, and not a claim about a later network that reused the name.
Ask who may challenge, how long the window is, and where the transaction data sits. Those three decide whether the spec is in force.
The five-minute read
The defect
An optimistic rollup that can only be challenged by a permissioned set is a multisig with extra steps.
The rule
A dispute walks a single instruction of a state transition on a parent chain, so anyone who can post a bond can force the on-chain step that decides a bad proposal.
How it is put together
The proposal is innocent until a dispute says otherwise. The game narrows to one instruction. The parent chain is the referee, not the executor of every transaction.
Where the claim stops
The spec is the mechanism. A live chain may still gate who may propose.
One action, walked through
- A proposer posts a state root.
- A challenger posts a disagreement.
- Bisection continues until one instruction is checked on the parent.
- Who may open a dispute?
The argument, unpacked
Why it is still on the desk
Ask who may challenge, how long the window is, and where the transaction data sits. Those three decide whether the spec is in force.
After the text
OP mainnet moved toward permissionless fault proofs after running with a security council. The spec and the deployment date are different citations.
What has to be true
- The spec is the mechanism. A live chain may still gate who may propose.
- A fault proof does not make data available. If the data was withheld, the bisection may have nothing to read.
- This is not Arbitrum's protocol and not a ZK proof.
What happened after the paper
OP mainnet moved toward permissionless fault proofs after running with a security council. The spec and the deployment date are different citations.
What to check before you use the idea
- Who may open a dispute?
- Where is the data the instruction reads?
- What happens when the window expires with no challenge?
Terms
- Bisection
- Cutting a disputed computation in half until one step remains.
- State root
- A commitment to the rollup state a proposer claims.
The problem the paper names
An optimistic rollup that can only be challenged by a permissioned set is a multisig with extra steps.
What the design proposes
- The proposal is innocent until a dispute says otherwise.
- The game narrows to one instruction.
- The parent chain is the referee, not the executor of every transaction.
How the mechanism is specified
- A proposer posts a state root.
- A challenger posts a disagreement.
- Bisection continues until one instruction is checked on the parent.
What this page does not treat as proven
- The spec is the mechanism. A live chain may still gate who may propose.
- A fault proof does not make data available. If the data was withheld, the bisection may have nothing to read.
- This is not Arbitrum's protocol and not a ZK proof.
Why a venture studio still reads it
Ask who may challenge, how long the window is, and where the transaction data sits. Those three decide whether the spec is in force.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.