Skip to main content
op-proposer is the OP Stack’s output proposer: the service that submits output roots, claims about the L2 chain’s state, to L1 so that withdrawals can be proven against them.

​
Overview

op-proposer queries its rollup node for an output root (a commitment to the L2 state at a given block) and submits it to L1 on a configured interval. On a chain running fault proofs, each proposal is a transaction to the DisputeGameFactory that creates a new dispute game: a claim that stands unless successfully challenged. By default op-proposer proposes only finalized L2 state, because a proposal of state that does not hold true later is an invalid claim that carries dispute game penalties. (A pre-fault-proof proposal path still exists in the code but is effectively unused.) It exists because proposals are how L1 learns about L2 state: withdrawals are authenticated against resolved proposals, so a user proves a withdrawal against a proposed output root and finalizes it once that proposal’s dispute game resolves in its favor. Without op-proposer, no new output roots reach L1 and withdrawals cannot be proven. Who runs it: the chain operator, as one of the chain’s core services. On chains with permissioned fault proofs, only the designated proposer role can submit proposals; with permissionless fault proofs anyone can propose, but the operator still runs op-proposer so proposals land regularly.

​
Get started

  • Spin up proposer: set up and configure op-proposer as part of standing up an OP Stack chain.

​
How-tos

​
Configuration & flags reference

  • Proposer configuration: every configuration option and environment variable, plus the proposer policy constraints that govern what gets proposed and when.

​
Releases