How to Check if Rollup Fault Proofs Are Enabled

To check whether a Rollup has fault proofs enabled, the most direct method is to review its official documentation or developer announcements, where it should explicitly state that "Fault Proofs" are live and activated. For example, Optimism activated its permissionless fault proof system on the mainnet on June 10, 2024. This system allows anyone to submit and challenge proposals regarding the L2 state without permission, serving as a critical line of defense for fund security.

Why Check for Fault Proofs?

In an Optimistic Rollup, the system assumes all state transitions are valid by default, but provides a Challenge Period. During this window, anyone can submit a "fault proof" to demonstrate that a state transition is incorrect.

• What activation means: If fault proofs are enabled, anyone can challenge invalid withdrawals or state proposals. This is a key step toward a "trustless" security model.

• Risks when disabled: If the fault proof system is not activated (e.g., during a transitional development phase), the network's security may rely more heavily on centralized components or trust assumptions maintained by the project team, providing weaker security guarantees for user withdrawals.

How to Check?

You can investigate through the following ways:

Case A: Check official technical documentation and announcements (most authoritative)

The official documentation is the primary source of information for determining whether fault proofs are live.

1. Search for "Fault Proofs" keywords: Visit the official documentation or developer docs of projects like Optimism or Arbitrum and search for "Fault Proof" or "Dispute Game".

2. Confirm the activation announcement: Official channels typically publish an announcement specifying the activation date. For example, Optimism explicitly announced that fault proofs were activated on OP Mainnet on June 10, 2024. If the documentation still says "in development" or "testnet," the feature is likely not yet enabled on mainnet.

Completion criteria: On the official project website or technical documentation, find a statement explicitly saying "Fault Proofs are enabled" or "Permissionless challenges are live".

Case B: Observe the challenger program configuration

For developers or chain operators, you can check whether a challenger component is deployed. Taking OP Stack chains as an example, running an op-challenger service is a critical step for network security. The official tutorial clearly states that after deploying the Sequencer and Proposer, the final step is to configure the challenger to monitor and respond to disputes.

• How it works: The op-challenger monitors dispute games generated by the DisputeGameFactory contract. When it detects an invalid state proposal, it initiates a challenge, resolving the dispute through an interactive dispute game.

Completion criteria: If you see an active op-challenger service in the chain's operational components and it is participating in dispute games through the DisputeGameFactory contract, this indicates the chain's fault proof mechanism is activated and effective.

Core Mechanisms and Risks

Once fault proofs are enabled, anyone can become a proposer or a challenger, achieving what is known as a permissionless state. On OP Mainnet, the dispute window is approximately 7 days.

• Key roles: op-proposer automatically submits state root (Output Root) proposals; op-challenger monitors and challenges these proposals.

• Economic game: Challengers must stake a bond when submitting a challenge, and if the challenge succeeds, they receive a reward. This ensures that challengers have an economic incentive to uphold network security.

Security Note: If at the time of your check the official documentation or announcements do not explicitly mention that fault proofs are activated, or if they state they are "in development" or "disabled," this means your fund operations on that chain (especially withdrawals) rely on trust assumptions placed on the project team rather than on purely code-driven game theory.

Final Confirmation

After completing these checks, you can confirm the current security model of the network. For example, for OP Mainnet, confirming that "the permissionless fault proof system was activated on June 10, 2024" means the chain possesses this layer of security protection. If you are using other OP Stack-compatible chains, consult their respective official documentation to verify whether this feature is enabled.