From 4c78801bb01684b67cd3c63a7b3a2644dfd1c3cc Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 31 Jul 2025 14:06:14 +0100 Subject: [PATCH 1/2] Update fault-proof explainer with warning about `create-game` subcommand and provide guidance for `op-challenger` usage --- pages/stack/fault-proofs/explainer.mdx | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/pages/stack/fault-proofs/explainer.mdx b/pages/stack/fault-proofs/explainer.mdx index 5960e3c11..ec82e5eed 100644 --- a/pages/stack/fault-proofs/explainer.mdx +++ b/pages/stack/fault-proofs/explainer.mdx @@ -86,11 +86,17 @@ Due to the permissionless structure where many different actors can participate Users can complete the full withdrawal cycle without depending on any privileged action. The Guardian role can override the system by pausing withdrawals, blacklisting games, or reverting to a permissioned system. As a result, the trust assumption is reduced to requiring only that the Guardian role does not act to intervene, inline with the stage 1 requirements. + ### Since the roles of proposer and challenger will be open to everyone, are guides available outlining the best practices for running them? It's not expected that normal users run `op-proposer` to regularly propose output roots. -Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan or using the [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger`. -Documentation for `op-challenger` is forthcoming. +Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan. + + +The [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger` is **for testing purposes only** and should not be used in production environments. It is not intended as a replacement for proper `op-proposer` infrastructure. + + +For detailed guidance on running `op-challenger`, see the [OP-Challenger explainer](/stack/fault-proofs/challenger) and [how to configure challenger for your chain](/operators/chain-operators/tools/op-challenger). ### How much ETH should a chain operator put aside to operate the Fault Proof System? From c673aa89a534f11c9b715334dcfd665733ecab4a Mon Sep 17 00:00:00 2001 From: Blessing Krofegha Date: Thu, 31 Jul 2025 14:09:55 +0100 Subject: [PATCH 2/2] update text --- pages/stack/fault-proofs/explainer.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/stack/fault-proofs/explainer.mdx b/pages/stack/fault-proofs/explainer.mdx index ec82e5eed..52eefd5c0 100644 --- a/pages/stack/fault-proofs/explainer.mdx +++ b/pages/stack/fault-proofs/explainer.mdx @@ -92,7 +92,7 @@ As a result, the trust assumption is reduced to requiring only that the Guardian It's not expected that normal users run `op-proposer` to regularly propose output roots. Users would generally just propose a single output root if they need to withdraw and the chain operator isn't proposing outputs for them via direct calls to the `DisputeGameFactory` via Etherscan. - + The [`create-game`](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger#create-game) subcommand of `op-challenger` is **for testing purposes only** and should not be used in production environments. It is not intended as a replacement for proper `op-proposer` infrastructure.