Proposer setup guide

pages/operators/chain-operators/configuration/batcher.mdx

@@ -19,9 +19,8 @@ import { Callout, Tabs } from 'nextra/components'
 
 # Batcher configuration
 
-This page lists all configuration options for the op-batcher. The op-batcher posts
-L2 sequencer data to the L1, to make it available for verifiers. The following
-options are from the `--help` in [v1.10.0](https://github.com/ethereum-optimism/optimism/releases/tag/op-batcher%2Fv1.10.0).
+This page provides the **definitive guide** for OP Stack batcher configuration, serving as the single source of truth for chain operators.
+The op-batcher posts L2 sequencer data to the L1, to make it available for verifiers.
 
 ## Batcher policy
 
@@ -32,12 +31,12 @@ The batcher policy defines high-level constraints and responsibilities regarding
 | Data Availability Type     | Specifies whether the batcher uses **blobs**, **calldata**, or **auto** to post transaction data to L1.        | Batch submitter address | Ethereum (Blobs or Calldata)                                                               | - Alternative data availability (Alt-DA) is not yet supported in the standard configuration.<br />- The sequencer can switch at will between blob transactions and calldata, with no restrictions, because both are fully secured by L1. |
 | Batch Submission Frequency | Determines how frequently the batcher submits aggregated transaction data to L1 (via the batcher transaction). | Batch submitter address | Must target **1,800 L1 blocks** (6 hours on Ethereum, assuming 12s L1 block time) or lower | - Batches must be posted before the sequencing window closes (commonly 12 hours by default).<br />- Leave a buffer for L1 network congestion and data size to ensure that each batch is fully committed in a timely manner.              |
 
-*   **Data Availability Types**:
+*   **Data availability types**:
     *   **Calldata** is generally simpler but can be more expensive on mainnet Ethereum, depending on gas prices.
     *   **Blobs** are typically lower cost when your chain has enough transaction volume to fill large chunks of data.
     *   The `op-batcher` can toggle between these approaches by setting the `--data-availability-type=<blobs|calldata|auto>` flag or with the `OP_BATCHER_DATA_AVAILABILITY_TYPE` env variable. Setting this flag to `auto` will allow the batcher to automatically switch between `calldata` and `blobs` based on the current L1 gas price.
 
-*   **Batch Submission Frequency** (`OP_BATCHER_MAX_CHANNEL_DURATION` and related flags):
+*   **Batch submission frequency** (`OP_BATCHER_MAX_CHANNEL_DURATION` and related flags):
     *   Standard OP Chains frequently target a maximum channel duration between 1–6 hours.
     *   Your chain should never exceed your L2's sequencing window (commonly 12 hours).
     *   If targeting a longer submission window (e.g., 5 or 6 hours), be aware that the [safe head](https://github.com/ethereum-optimism/specs/blob/main/specs/glossary.md#safe-l2-head) can stall up to that duration.
@@ -71,7 +70,7 @@ To minimize costs, we recommend setting your  `OP_BATCHER_MAX_CHANNEL_DURATION`
   When there's blob congestion, running with high blob counts can backfire, because you will have a harder time getting blobs included and then fees will bump, which always means a doubling of the priority fees.
 </Callout>
 
-The `op-batcher` has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the [specs](https://specs.optimism.io/protocol/derivation.html#frame-format?utm_source=op-docs&utm_medium=docs) for more technical details on channels and frames.
+The `op-batcher` has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the [specs](https://specs.optimism.io/protocol/derivation.html#frame-format?utm_source=op-docs\&utm_medium=docs) for more technical details on channels and frames.
 
 A minimal batcher configuration (with env vars) to enable 6-blob batcher transactions is:
 
@@ -166,7 +165,7 @@ however you can see some of the most important variables configured below:
   OP_BATCHER_ACTIVE_SEQUENCER_CHECK_DURATION: 5s
 ```
 
-Lower throughput chains, which aren't filling up channels before the `MAX_CHANNEL_DURATION` is hit, 
+Lower throughput chains, which aren't filling up channels before the `MAX_CHANNEL_DURATION` is hit,
 may save gas by increasing the `MAX_CHANNEL_DURATION`. See the [recommendations section](#set-your--op_batcher_max_channel_duration).
 
 ## All configuration variables
@@ -538,7 +537,6 @@ flag must also be set.
   <Tabs.Tab>`OP_BATCHER_HD_PATH=`</Tabs.Tab>
 </Tabs>
 
-
 #### signer.address
 
 Address the signer is signing transactions for.
@@ -806,7 +804,6 @@ Enable the metrics server. The default value is `false`.
   <Tabs.Tab>`--version=false`</Tabs.Tab>
 </Tabs>
 
-
 ### Miscellaneous
 
 #### active-sequencer-check-duration
@@ -888,3 +885,18 @@ Print the version. The default value is false.
   <Tabs.Tab>`--version=<value>`</Tabs.Tab>
   <Tabs.Tab>`--version=false`</Tabs.Tab>
 </Tabs>
+
+## Conclusion
+
+This configuration reference provides a complete foundation for operating an OP Stack batcher efficiently and securely.
+The recommended settings balance cost optimization with operational reliability while ensuring proper transaction finality progression.
+
+The batcher is critical infrastructure that ensures your L2 chain inherits Ethereum's security properties through reliable data availability.
+Proper configuration based on these guidelines will ensure optimal operation while meeting your chain's specific requirements.
+
+### Next steps
+
+*   Read the [transaction finality](/stack/transactions/transaction-finality) docs
+*   Check out [rollup protocol](/stack/rollup/overview) specs
+*   Read the [derivation process](https://specs.optimism.io/protocol/derivation.html) guide
+*   Read the [batch submission wire format](https://specs.optimism.io/protocol/derivation.html#batch-submission) spec

pages/operators/chain-operators/deploy.mdx

@@ -30,6 +30,8 @@ This section provides information on OP Stack genesis creation, deployment overv
 
   <Card title="Smart contract deployment" href="/operators/chain-operators/deploy/smart-contracts" />
 
+  <Card title="Spin up your proposer" href="/operators/chain-operators/deploy/proposer-setup-guide" />
+
   <Card title="Validate your contract deployment" href="/operators/chain-operators/deploy/validate-deployment" />
 
 </Cards>

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

@@ -2,6 +2,7 @@
   "overview": "Deployment overview",
   "smart-contracts": "Smart contract deployment",
   "validate-deployment": "Validate your contract deployment",
+  "proposer-setup-guide": "Spin up your proposer",
   "genesis": "Chain artifacts creation"
 }
 

pages/operators/chain-operators/deploy/proposer-setup-guide.mdx

@@ -0,0 +1,246 @@
+---
+title: Spin up your proposer
+lang: en-US
+description: Learn how to set up and configure an OP Stack proposer to post L2 state roots.
+content_type: tutorial
+topic: proposer-setup
+personas:
+  - chain-operator
+categories:
+  - testnet
+  - mainnet
+  - op-proposer
+  - state-commitment
+  - l2-output-submission
+  - withdrawal-verification
+is_imported_content: 'false'
+---
+
+# Spin up your proposer
+
+After you have spun up your sequencer, you need to attach a proposer to post your L2 state roots data back onto L1 so we can prove withdrawal validity. The proposer is a critical component that enables trustless L2-to-L1 messaging and creates the authoritative view of L2 state from L1's perspective.
+
+This guide assumes you already have a functioning sequencer and the necessary L1 contracts deployed using [`op-deployer`](/operators/chain-operators/tools/op-deployer). If you haven't set up your sequencer yet, please refer to the \[sequencer guide]\(Todo - Add this link when it's live) first.
+
+## Understanding the proposer's role
+
+The proposer (`op-proposer`) serves as a crucial bridge between your L2 chain and L1. Its primary responsibilities include:
+
+*   **State commitment**: Proposing L2 state roots to L1 at regular intervals
+*   **Withdrawal enablement**: Providing the necessary commitments for users to prove and finalize withdrawals
+
+The proposer creates dispute games via the `DisputeGameFactory` contract, enabling permissionless challenging of proposed state roots and providing a robust fault proof system.
+
+## Prerequisites
+
+Before setting up your proposer, ensure you have:
+
+**Running infrastructure:**
+
+*   A synced and operational sequencer node
+*   Access to a L1 RPC endpoint
+*   The rollup node (`op-node`) running and accessible
+
+**From op-deployer deployment:**
+
+*   Successfully deployed L1 contracts using `op-deployer apply`
+*   Access to your deployment output files
+
+**Security setup:**
+
+*   A dedicated proposer private key with sufficient L1 ETH for gas fees
+
+**Network information:**
+
+*   Your L2 chain ID and network configuration
+*   L1 network details (chain ID, RPC endpoints)
+
+## Software installation
+
+### Build from source
+
+Clone and build op-proposer
+
+```bash
+# If you don't already have the optimism repository from the sequencer setup
+git clone https://github.com/ethereum-optimism/optimism.git
+cd optimism
+
+# Checkout the latest release tag
+git checkout op-proposer/v1.10.0
+
+# Build op-proposer
+cd op-proposer
+make op-proposer
+
+# Binary will be available at ./bin/op-proposer
+```
+
+### Verify installation
+
+```bash
+./bin/op-proposer --version
+```
+
+## Configuration setup
+
+### 1. Organize your workspace
+
+Create your proposer working directory:
+
+```bash
+# Create proposer directory at the same level as your sequencer
+mkdir ~/proposer-node
+cd ~/proposer-node
+
+# Create scripts directory
+mkdir scripts
+```
+
+### 2. Extract contract addresses
+
+Extract the necessary contract addresses from your op-deployer output:
+
+```bash
+# Extract L1 contract addresses from your op-deployer deployment
+cd ~/proposer-node
+
+# Copy the L1 contracts file from op-deployer
+cp ~/.deployer/state.json .
+
+# Extract the DisputeGameFactory address
+GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployment.disputeGameFactoryProxyAddress')
+echo "DisputeGameFactory Address: $GAME_FACTORY_ADDRESS"
+```
+
+### 3. Set up environment variables
+
+Create your `.env` file with the actual values:
+
+```bash
+# Create .env file with your actual values
+# L1 Configuration - Replace with your actual RPC URL
+L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY
+
+# L2 Configuration - Should match your sequencer setup
+L2_RPC_URL=http://localhost:8545
+ROLLUP_RPC_URL=http://localhost:8547
+
+# Contract addresses - Extract from your op-deployer output
+GAME_FACTORY_ADDRESS=YOUR_ACTUAL_GAME_FACTORY_ADDRESS
+
+# Private key - Replace with your actual proposer private key
+PROPOSER_PRIVATE_KEY=0xYOUR_ACTUAL_PROPOSER_PRIVATE_KEY
+
+# Proposer configuration
+PROPOSAL_INTERVAL=3600s
+GAME_TYPE=0
+POLL_INTERVAL=20s
+
+# RPC configuration
+PROPOSER_RPC_PORT=8560
+```
+
+**Important**: Replace ALL placeholder values (`YOUR_ACTUAL_*`) with your real configuration values!
+
+### 4. Get your proposer private key
+
+Extract the proposer private key from your op-deployer intent file:
+
+```bash
+# View your intent file to find the proposer private key
+cat ~/.deployer/intent.toml
+
+# Look for a section like:
+# [chains.my-chain.roles.proposer]
+# privateKey = "0x..."
+```
+
+## Proposer configuration
+
+Create `scripts/start-proposer.sh`:
+
+```bash
+#!/bin/bash
+
+source .env
+
+# Path to the op-proposer binary we built
+../optimism/op-proposer/bin/op-proposer \
+  --poll-interval=$POLL_INTERVAL \
+  --rpc.port=$PROPOSER_RPC_PORT \
+  --rpc.enable-admin \
+  --rollup-rpc=$ROLLUP_RPC_URL \
+  --l1-eth-rpc=$L1_RPC_URL \
+  --private-key=$PROPOSER_PRIVATE_KEY \
+  --game-factory-address=$GAME_FACTORY_ADDRESS \
+  --game-type=$GAME_TYPE \
+  --proposal-interval=$PROPOSAL_INTERVAL \
+  --num-confirmations=1 \
+  --resubmission-timeout=30s \
+  --wait-node-sync=true \
+  --log.level=info
+```
+
+## Starting the proposer
+
+### 1. Verify prerequisites
+
+Ensure your sequencer and op-node are running:
+
+```bash
+# Test L1 connectivity
+curl -X POST -H "Content-Type: application/json" \
+  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
+  $L1_RPC_URL
+
+# Test L2 connectivity  
+curl -X POST -H "Content-Type: application/json" \
+  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' \
+  $L2_RPC_URL
+
+# Test rollup node connectivity
+curl -X POST -H "Content-Type: application/json" \
+  --data '{"jsonrpc":"2.0","method":"optimism_syncStatus","params":[],"id":1}' \
+  $ROLLUP_RPC_URL
+```
+
+### 2. Start the proposer
+
+```bash
+# Make the script executable
+chmod +x scripts/start-proposer.sh
+
+# Start the proposer
+./scripts/start-proposer.sh
+```
+
+## Verification
+
+Verify your proposer is working correctly:
+
+### Check proposer status
+
+```bash
+# Verify proposer is responsive
+curl -X POST -H "Content-Type: application/json" \
+  --data '{"jsonrpc":"2.0","method":"optimism_version","params":[],"id":1}' \
+  http://localhost:8560
+```
+
+### Monitor dispute games on L1
+
+```bash
+# Check latest dispute game count (requires cast from foundry)
+cast call $GAME_FACTORY_ADDRESS "gameCount()" --rpc-url $L1_RPC_URL
+```
+
+Monitor your proposer's ETH balance and gas usage to ensure continuous operation.
+Your proposer is now operational!
+
+## Next steps
+
+*   For detailed parameter documentation, see the [proposer configuration reference](/operators/chain-operators/configuration/proposer).
+*   For more detail on deploying new dispute games with OPCM, [see the docs](/operators/chain-operators/tutorials/dispute-games).
+*   checkout the [migrating to permissionless fault proofs](/operators/chain-operators/tutorials/migrating-permissionless) guide
+*   For cost optimization resources, check out the [Fee calculation tools](/operators/chain-operators/tools/fee-calculator).

pages/operators/chain-operators/tutorials/absolute-prestate.mdx

@@ -277,6 +277,6 @@ After generating the absolute prestate and preimage files, you'll need to:
 
 ## Next Steps
 
-*   [Deploying new dispute games with OPCM](/operators/chain-operators/tutorials/dispute-games)
-*   [Migrating to permissionless fault proofs](/operators/chain-operators/tutorials/migrating-permissionless)
+*   Check out the [migrating to permissionless fault proofs guide](/operators/chain-operators/tutorials/migrating-permissionless).
+*   Read the [Fault proofs explainer](/stack/fault-proofs/explainer).
 *   [Fault proofs explainer](/stack/fault-proofs/explainer)

pages/operators/chain-operators/tutorials/dispute-games.mdx

@@ -148,3 +148,10 @@ cast send --rpc-url $RPC_URL --private-key $PRIVATE_KEY $OPCM_ADDRESS $CALLDATA
 4.  Setting the respected game type
     After deploying the permissionless dispute game, you'll need to update the respectedGameType in the OptimismPortal to start using it.
     For detailed instructions on setting the respected game type and migrating your chain from permissioned to permissionless fault proofs, refer to the [migrating to permissionless fault proofs guide](/operators/chain-operators/tutorials/migrating-permissionless).
+
+## Next Steps
+
+*   For more detail on deploying new dispute games with OPCM, [see the docs](/operators/chain-operators/tutorials/dispute-games).
+*   Learn about [absolute prestate](/operators/chain-operators/tutorials/absolute-prestate)
+*   checkout the [migrating to permissionless fault proofs](/operators/chain-operators/tutorials/migrating-permissionless) guide
+*   [Fault proofs explainer](/stack/fault-proofs/explainer)

pages/operators/chain-operators/tutorials/migrating-permissionless.mdx

@@ -382,3 +382,6 @@ OP_PROPOSER_GAME_TYPE=0
 ## Next steps
 
 *   For more detail on deploying new dispute games with OPCM, [see the docs](/operators/chain-operators/tutorials/dispute-games).
+*   Deploy new dispute games with OPCM via [this tutorial](/operators/chain-operators/tutorials/dispute-games).
+*   Generate an absolute prestate using the [absolute prestate guide](/operators/chain-operators/tutorials/absolute-prestate).
+*   Understand fault proofs in the [Fault proofs explainer](/stack/fault-proofs/explainer).