op-batcher and op-proposer Operations Guide

The op-batcher is the sole pathway for user transactions to reach L1. If the batcher stalls due to insufficient ETH balance, L1 congestion, or blob market misconfiguration, the L2 sequencer block production may continue, but no state roots will be posted to L1. This creates a soft halt where user transactions are accepted locally but never finalized. Exchanges and bridges relying on L1 finality for deposit credits will stop processing, leading to a complete freeze of cross-chain asset flows. Operators must monitor the batcher's tx_published counter and safe head lag as primary liveness signals.

The op-batcher's posting strategy directly determines a chain's operational runway. Misconfiguring blob vs. calldata fallback logic during an L1 fee spike can drain the batcher's ETH balance in minutes, halting all data posting. Operators must model worst-case L1 blob gas costs and ensure the batcher's fee management strategy dynamically adjusts to the blob_base_fee without exceeding a pre-set cap. A failure to post data due to underpriced transactions is functionally equivalent to a sequencer outage. Chainscore can review your batcher's fee escalation logic and DA cost projection models.

The op-proposer submits output roots that anchor the L2's canonical state to L1. If the proposer submits an invalid state root—whether due to a software bug, a derivation pipeline error, or a compromised key—it can trigger a fault proof challenge. During the challenge period, honest validators must intervene to prevent finalization of a fraudulent state, which could be exploited to drain bridge assets. Operators must run independent verifier nodes alongside the proposer to detect anomalies before submitting a batch. A single-operator proposer without independent verification is a systemic risk to all canonical bridges.

Both the batcher and proposer require hot private keys with ETH balances to function. A key compromise allows an attacker to drain operational funds or, more critically, submit fraudulent output roots. Standard cold-wallet governance is incompatible with the sub-minute posting cadence required for liveness. Operators must implement a tiered key architecture: a hot key with a minimal, auto-refilled balance for transaction submission, protected by a hardware security module (HSM) or a secure enclave. Chainscore can audit your key management topology to ensure it balances liveness requirements with the catastrophic risk of proposer key compromise.

The batcher and proposer are tightly coupled to the op-node's derivation pipeline. A network upgrade that changes the derivation rules—such as a new batch format or a shift in the channel timeout—requires a coordinated restart of all three services. Running a mismatched batcher version against an upgraded op-node can cause the batcher to construct invalid batches that the p2p network rejects, wasting ETH on reverted L1 transactions. Operators must consult the OP Stack Component Compatibility Matrix before any upgrade and execute a pre-defined restart sequence to avoid a liveness gap during the activation window.

Standard node health metrics like block height and peer count are insufficient for detecting batcher or proposer failures. Operators must implement dedicated alerting on: the batcher's pending transaction count, the time since the last successful L1 batch inclusion, the proposer's output root submission interval, and the ETH balances of both service accounts. A silent failure where the op-node is healthy but the batcher has stopped posting can persist for hours without triggering generic infrastructure alerts. Chainscore can define a comprehensive Prometheus alerting ruleset tailored to your chain's specific posting cadence and finality window.

For an operational review, maintain a source-backed package containing current binary versions, release notes, chain config, signer addresses, L1 contract targets, fee settings, transaction manager parameters, alert thresholds, and recent batcher/proposer transaction samples. This lets protocol, security, and finance teams verify whether failures are caused by software compatibility, L1 fee conditions, signer funding, RPC dependency issues, or governance-controlled contract changes. Chainscore Labs can review this evidence before upgrades, migrations to blobs, or proposer/fault-proof configuration changes.