
How to view the security issues of Optimism's fraud proofs?
TechFlow Selected TechFlow Selected

How to view the security issues of Optimism's fraud proofs?
The OP Foundation proposed a hard fork to fix the issue and transition it to a permissioned proof.
By Haotian
Recently, Optimism has come under scrutiny from the international community due to security audit concerns surrounding its Fault Proof System. The originally permissionless fraud proof mechanism was found to have critical security flaws—yet instead of resolving them transparently, the OP Foundation proposed a hard fork to fix the issues and transition it into a permissioned system. What exactly happened?
1) In short: The Fault Proof System is a mechanism designed to verify the correctness of Layer 2 network states. Anyone can submit L2 state claims permissionlessly to the dispute virtual machine (VM) on L1, where others may challenge them. If a challenge succeeds, penalty and reward mechanisms are triggered.
This fraud proof mechanism is essential for ensuring the security of the OP-Rollup architecture. The launch of the Fault Proof System in June addressed long-standing market criticism about the OP Stack lacking an effective challenge mechanism.
2) However, a recent community-led audit uncovered multiple vulnerabilities in this fraud proof system—and the response from the Optimism Foundation was shocking:
1. Dismissing opcode-level vulnerabilities in the fraud proof VM as minor security issues;
2. Excluding the fraud proof system from external audit scope;
3. Temporarily switching the permissionless fraud proofs to a permissioned model, while proposing a hard fork called "Granite" to address the security flaws.
Such actions inevitably raise doubts about the purpose and effectiveness of the Fault Proof System altogether.
3) How should we view this incident? In my opinion:
1. Optimism introduced the Fault Proof System primarily as a necessary security challenge mechanism to expand the appeal of the OP Stack ecosystem. The market had already become "priced in" regarding whether Optimism truly possessed such a functional challenge mechanism.
2. The Fault Proof System is indeed sophisticated and complex. Most state validation occurs locally on L2, with only critical components submitted to the fault-dispute VM on L1 for final resolution. Yes, they developed a custom opcode-based virtual machine—this approach ensures low verification costs on L1 while maintaining strong security guarantees.
3. The shift from permissionless to permissioned fraud proofs—and the emergency disabling of the system—reveals excessive control held by the OP Foundation and its multi-sig security council. Even when fraud proofs are technically permissionless, they remain ultimately under the oversight of the security committee.
4. Compared to fellow ecosystem member Arbitrum, Optimism now lags behind in achieving Stage 1 goals for security and decentralization. This setback will likely amplify recognition of ZK-Rollups’ technological lead.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














