Spin up proposer

Learn how to set up and configure an OP Stack proposer to post L2 state roots.

After you have spun up your sequencer and batcher, 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.

Step 4 of 5: This tutorial is designed to be followed step-by-step. Each step builds on the previous one.

Automated Setup Available

For a complete working setup with all components, check out the automated approach in the code directory.

This guide assumes you already have a functioning sequencer, batcher, and the necessary L1 contracts deployed using op-deployer. If you haven’t set up your sequencer and batcher yet, please refer to the sequencer guide and batcher guide first.

To see configuration info for the proposer, check out the configuration page.

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.

Prerequisites

Before setting up your proposer, ensure you have:

Running infrastructure:

• An operational sequencer node
• Access to a L1 RPC endpoint

Network information:

• Your L2 chain ID and network configuration
• L1 network details (chain ID, RPC endpoints)

For setting up the proposer, we recommend using Docker as it provides a consistent and isolated environment. Building from source is also available as an option.

Use docker

If you prefer containerized deployment, you can use the official Docker images and do the following:

1. Set up directory structure and copy configuration files

   # Create a proposer directory inside rollup
   cd ../    # Go back to rollup directory if you're in batcher
   mkdir proposer
   cd proposer
   # inside the proposer directory, copy the state.json file from the op-deployer setup
   # Copy configuration files from deployer
   cp ../deployer/.deployer/state.json .
   
   # Extract the DisputeGameFactory address
   GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].DisputeGameFactoryProxy')
   echo "DisputeGameFactory Address: $GAME_FACTORY_ADDRESS"
   
2. Create environment variables file

   OP Stack Standard Variables

   The proposer uses OP Stack standard environment variables following the OP Stack conventions. These are prefixed with OP_PROPOSER_ for proposer-specific settings.

   # Create .env file with your actual values
   cat > .env << 'EOF'
   #  L1 Configuration - Replace with your actual RPC URLs
   OP_PROPOSER_L1_RPC_URL=https://sepolia.infura.io/v3/YOUR_ACTUAL_INFURA_KEY
   
   # L2 Configuration - Should match your sequencer setup
   OP_PROPOSER_ROLLUP_RPC=http://op-node:8547
   
   # Contract addresses - Extract from your op-deployer output
   OP_PROPOSER_GAME_FACTORY_ADDRESS=YOUR_ACTUAL_GAME_FACTORY_ADDRESS
   
   # Private key - Replace with your actual private key
   OP_PROPOSER_PRIVATE_KEY=YOUR_ACTUAL_PRIVATE_KEY
   
   # OP Stack proposer configuration (optional - defaults provided)
   OP_PROPOSER_PROPOSAL_INTERVAL=3600s
   OP_PROPOSER_GAME_TYPE=0
   OP_PROPOSER_POLL_INTERVAL=20s
   OP_PROPOSER_ALLOW_NON_FINALIZED=true
   OP_PROPOSER_WAIT_NODE_SYNC=true
   EOF
   

   Important: Replace ALL placeholder values (YOUR_ACTUAL_*) with your real configuration values.

3. Create docker-compose.yml

   If you get “failed to dial address” errors, ensure your proposer is in the same Docker network as your sequencer.

   Common fixes:

   • Add networks: - sequencer-node_default to your proposer’s docker-compose.yml
   • Use service names like op-reth:8545 and op-node:8547 in your .env file
   • Verify your sequencer network name with docker network ls

   
   services:
     op-proposer:
       image: us-docker.pkg.dev/oplabs-tools-artifacts/images/op-proposer:v1.16.3
       volumes:
         - .:/workspace
       working_dir: /workspace
       ports:
         - "8560:8560"
       env_file:
         - .env
       command: >
         op-proposer
         --rpc.port=8560
         --log.level=info
         --log.format=json
       restart: unless-stopped
       networks:
         - sequencer-node_default
   
   networks:
     sequencer-node_default:
       external: false
   
   
4. Start the proposer service

   # Make sure your sequencer network exists
   docker network create op-stack 2>/dev/null || true
   
   # Start the proposer
   docker-compose up -d
   
   # View logs
   docker-compose logs -f op-proposer
   
5. Verify proposer is running

   # Check container status
   docker-compose ps
   
6. Final directory structure

   rollup/
   ├── deployer/            # From previous step
   │   └── .deployer/      # Contains state.json
   ├── sequencer/          # From previous step
   ├── batcher/           # From previous step
   └── proposer/         # You are here
       ├── state.json    # Copied from deployer
       ├── .env          # Environment variables
       └── docker-compose.yml # Docker configuration
   

Understanding proposer startup logs

When you first start your proposer, you’ll see several types of log messages:

1. Initialization messages (normal):

   lvl=info msg="Initializing L2Output Submitter"
   lvl=info msg="Connected to DisputeGameFactory"
   lvl=info msg="Starting JSON-RPC server"
   

2. Sync status messages (expected during startup):

   msg="rollup current L1 block still behind target, retrying"
   current_l1=...:9094035 target_l1=9132815
   

   This is normal! It means:

   • Your rollup is still syncing with L1 (e.g., Sepolia)
   • The proposer is waiting until sync is closer to L1 tip
   • You’ll see the current_l1 number increasing as it catches up
   • Once caught up, the proposer will start submitting proposals

Don’t worry about the “retrying” messages - they show healthy progress as your rollup catches up to the latest L1 blocks.

Common log patterns:

• Startup: You’ll see initialization messages as services start
• Sync: “block still behind target” messages while catching up
• Normal operation: Regular proposal submissions once synced
• Network: Connection messages to L1/L2 endpoints

If you see errors about “failed to dial” or connection issues:

• For source build: Verify your localhost ports and services

Your proposer is now operational and will continuously submit state roots to L1!

Build from source

Finding the current stable releases

To ensure you’re using the latest compatible versions of OP Stack components, always check the official releases page.

Look for the latest op-proposer/v* release that’s compatible with your sequencer setup.

This guide uses op-proposer/v1.16.3, the latest release at the time of writing, alongside op-node/v1.19.3 and op-reth/v2.4.0 from the sequencer setup. Always check the release notes for compatibility information.

Building from source gives you full control over the binaries.

1. Clone and build op-proposer

   # 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.16.3
   
   # Build op-proposer
   cd op-proposer
   just
   
   # Binary will be available at ./bin/op-proposer
   
2. Verify installation

   Run this command to verify the installation:

   ./bin/op-proposer --version
   

Configuration setup

The rest of this guide assumes you’re using the build-from-source approach. If you chose Docker, all the necessary configuration was covered in the Docker tab above.

1. Organize your workspace

   Create your proposer working directory at the same level as your sequencer:

   # Create proposer directory inside rollup
   cd ../    # Go back to rollup directory
   mkdir proposer
   cd proposer
   
   # Create scripts directory
   mkdir scripts
   
2. Extract DisputeGameFactory address

   Extract the DisputeGameFactory contract address from your op-deployer output:

   # Make sure you're in the rollup/proposer directory
   cd rollup/proposer
   
   # Copy the state.json from deployer
   cp ../deployer/.deployer/state.json .
   
   # Extract the DisputeGameFactory address
   GAME_FACTORY_ADDRESS=$(cat state.json | jq -r '.opChainDeployments[0].disputeGameFactoryProxyAddress')
   echo "DisputeGameFactory Address: $GAME_FACTORY_ADDRESS"
   

   The proposer only needs the DisputeGameFactory address to submit proposals. The GAME_TYPE=0 represents the standard fault proof game type.

3. Set up environment variables

   Create your .env file with the actual values:

   # 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 private key
   PRIVATE_KEY=YOUR_ACTUAL_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 private key

   Get a private key from your wallet that will be used for submitting proposals to L1. This account needs sufficient ETH to pay for L1 gas costs.

   The proposer account needs to be funded with ETH on L1 to pay for proposal submission transactions. Monitor this account’s balance regularly as it will consume ETH for each proposal submission.

Proposer configuration

Create scripts/start-proposer.sh:

#!/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=$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

Your final directory structure should look like:

rollup/
├── deployer/              # From previous step
│   └── .deployer/        # Contains state.json
├── optimism/             # Contains op-proposer binary
├── sequencer/           # From previous step
├── batcher/            # From previous step
└── proposer/          # You are here
    ├── state.json     # Copied from deployer
    ├── .env          # Environment variables
    └── scripts/      # Startup scripts
        └── start-proposer.sh

Starting the proposer

1. Start the proposer

   # Make the script executable
   chmod +x scripts/start-proposer.sh
   
   # Start the proposer
   ./scripts/start-proposer.sh
   

Understanding proposer startup logs

When you first start your proposer, you’ll see several types of log messages:

1. Initialization messages (normal):

   lvl=info msg="Initializing L2Output Submitter"
   lvl=info msg="Connected to DisputeGameFactory"
   lvl=info msg="Starting JSON-RPC server"
   

2. Sync status messages (expected during startup):

   msg="rollup current L1 block still behind target, retrying"
   current_l1=...:9094035 target_l1=9132815
   

   This is normal! It means:

   • Your rollup is still syncing with L1 (e.g., Sepolia)
   • The proposer is waiting until sync is closer to L1 tip
   • You’ll see the current_l1 number increasing as it catches up
   • Once caught up, the proposer will start submitting proposals

Don’t worry about the “retrying” messages - they show healthy progress as your rollup catches up to the latest L1 blocks.

Common log patterns:

• Startup: You’ll see initialization messages as services start
• Sync: “block still behind target” messages while catching up
• Normal operation: Regular proposal submissions once synced
• Network: Connection messages to L1/L2 endpoints

If you see errors about “failed to dial” or connection issues:

• For Docker: Check your network configuration and service names

Your proposer is now operational!

What’s Next?

Perfect! Your proposer is submitting state roots to L1. The final step is to set up the challenger to monitor and respond to disputes.

Spin up challenger →

Next: Configure and start op-challenger to monitor disputes and maintain your rollup’s security.

---

Need Help?

• Proposer Configuration: op-proposer Configuration Reference
• Dispute Games: Deploying Dispute Games with OPCM