Managing the proposer address

This guide explains how to update the proposer address, within the dispute game smart contracts, for chains using permissioned fault proofs. The proposer (opens in a new tab) is responsible for submitting L2 outputs to L1, which is a critical component of the OP Stack. You will need the L1ProxyAdmin account, before you begin.

The proposer role is defined in the PermissionedDisputeGame.sol (opens in a new tab) 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 (opens in a new tab) 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 new 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 (opens in a new tab).

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 (opens in a new tab) 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:

   b. Creating a new dispute game to confirm the proposer address:

   1. Call create() on the DisputeGameFactory with the permissioned cannon game type.
   2. Query the PROPOSER() function on the newly created game.
   3. Verify it matches the new address.

• 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 and pay for gas 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 for details.

• Read the protocol configurability specifications (opens in a new tab) for more in-depth details.