Managing the proposer address

pages/operators/chain-operators/tutorials.mdx

@@ -36,6 +36,8 @@ This section provides information on adding attributes to the derivation functio
 
   <Card title="Running a Local Development Environment" href="/operators/chain-operators/tutorials/chain-dev-net" />
 
+  <Card title="Managing the proposer address" href="/operators/chain-operators/tutorials/proposer-address" />
+
   <Card title="Integrating a new da layer with alt Da" href="/operators/chain-operators/tutorials/integrating-da-layer" />
 
   <Card title="Modifying predeployed contracts" href="/operators/chain-operators/tutorials/modifying-predeploys" />

pages/operators/chain-operators/tutorials/_meta.json

@@ -4,5 +4,6 @@
     "adding-precompiles": "Adding a precompile",
     "modifying-predeploys": "Modifying predeployed contracts",
     "integrating-da-layer": "Integrating a new DA layer",
+    "proposer-address": "Managing the proposer address",
     "chain-dev-net": "Running a local network environment"
 }

pages/operators/chain-operators/tutorials/proposer-address.mdx

@@ -0,0 +1,82 @@
+---
+title: Managing the proposer address
+lang: en-US
+description: Learn how to update the proposer address for chains using permissioned fault proofs.
+content_type: tutorial
+topic: proposer-management
+personas:
+  - chain-operator
+  - protocol-developer
+categories:
+  - chain-operation
+  - chain-management
+  - proxy
+  - fault-proofs
+is_imported_content: 'false'
+---
+
+# Managing the proposer address
+
+This guide explains how to update the proposer address for chains using permissioned fault proofs.
+The proposer is responsible for submitting L2 outputs to L1, which is a critical component of the OP Stack.
+You will need access to the [L1ProxyAdmin](/superchain/privileged-roles#l1-proxy-admin) account, before you begin.
+
+The proposer role is defined in the [`PermissionedDisputeGame.sol`](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/PermissionedDisputeGame.sol) contract for chains running permissioned fault proofs.
+When you need to change the proposer address, you must update the implementation for `gametype 1` in the `DisputeGameFactory.sol` contract.
+
+## Steps to update the proposer address
+
+1.  **Identify the current configuration**
+
+    First, confirm that your chain is using permissioned fault proofs by checking the `DisputeGameFactory` contract on your L1. You can verify the current implementation by querying the `gameImpls` mapping with the permissioned cannon game type. This will return the current implementation contract for permissioned fault proof games.
+
+    See the [DisputeGameFactory contract](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) for the `gameImpls` function details.
+
+2.  **Prepare the new implementation**
+
+    You'll need to deploy a new implementation of the `PermissionedDisputeGame.sol` contract with the updated proposer address. When deploying:
+
+    *   The constructor requires multiple parameters including the proposer address
+    *   Use the same parameters as your existing implementation, except for the new proposer address
+    *   Ensure all inherited contracts are properly initialized
+    *   Test deployment on a testnet first
+
+    For constructor parameters, refer to the [PermissionedDisputeGame contract](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/PermissionedDisputeGame.sol).
+
+3.  **Update the implementation in the DisputeGameFactory**
+
+    Using the L1ProxyAdmin account, call the `setImplementation()` function to update the permissioned game type:
+
+    *   `_gameType`: Use `GameType.PERMISSIONED_CANNON` (value: 1) for permissioned fault proof games
+    *   `_impl`: The address of your new implementation with the updated proposer
+
+    Only the owner of the DisputeGameFactory contract (typically the ProxyAdmin) can call this function. See the [DisputeGameFactory contract source](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/dispute/DisputeGameFactory.sol) for the function signature.
+
+4.  **Verify the update**
+
+    After updating the implementation, verify the change was successful by:
+
+    a. Checking the implementation address is updated in the `gameImpls` mapping
+
+    b. Creating a new dispute game to confirm the proposer address:
+
+    *   Call `create()` on the DisputeGameFactory with the permissioned cannon game type
+    *   Query the `PROPOSER()` function on the newly created game
+    *   Verify it matches your new address
+
+    For verification methods, see the [DisputeGameFactory documentation](https://specs.optimism.io/fault-proof/stage-one/dispute-game-factory.html) and [game interface specs](https://specs.optimism.io/fault-proof/game-interface.html).
+
+## Important considerations
+
+*   This operation should be planned carefully as the proposer is a critical component of your rollup.
+*   Ensure the new proposer address is valid and properly controlled before making the change.
+*   Consider testing the procedure on a testnet before applying to production environments.
+*   The `L1ProxyAdmin` is a highly privileged role - ensure proper access controls are in place.
+*   All existing dispute games will continue to use the old proposer address, but newly created games will use the updated proposer.
+*   The proposer must have sufficient ETH balance to post bonds when creating new dispute games.
+
+## Next steps
+
+*   After updating the proposer address, you may need to configure the new proposer node. See the [proposer configuration](/operators/chain-operators/configuration/proposer) for details.
+
+*   Read the [protocol configurability specifications](https://specs.optimism.io/protocol/configurability.html#proposer-address) for more in-depth details.