Skip to main content
This guide shows how to enable Flashblocks on an OP Stack chain: running rollup-boost as the block-building coordination layer, streaming flashblocks from op-rbuilder, and serving the stream to RPC providers through flashblocks-websocket-proxy — in both single-sequencer and high-availability (HA) multi-sequencer setups. For what Flashblocks are, the component architecture, and the lifecycle of a flashblock, see the Flashblocks explainer. For full details on design choices, data structures, and invariants, see the Flashblocks specification.

​
What you’ll run

A Flashblocks-enabled sequencer runs these services side by side:
  • rollup-boost: Coordination layer with Flashblocks enabled
  • op-rbuilder: Execution client and builder with Flashblocks support
  • op-reth: Fallback builder, a standard EL node
  • flashblocks-websocket-proxy: Relays the flashblocks stream from the active sequencer to RPC providers
  • op-conductor (optional but recommended): Manages multiple sequencers, ensuring only one healthy leader streams blocks
Flashblocks are streamed from the op-rbuilder to rollup-boost over WebSockets, minimizing latency between the sequencer and the pre-confirmed state. The role each component plays is described in the architecture section of the Flashblocks explainer.

​
How to set up and run rollup-boost

Flashblocks relies on rollup-boost as the coordination layer for block building. To run Flashblocks, you’ll configure rollup-boost alongside your sequencer and execution clients.

​
Single‑sequencer setup

As suggested in the above links, in a single-sequencer setup, Flashblocks are streamed from rollup-boost (or op-rbuilder) to flashblocks-websocket-proxy by setting the following environment variable in flashblocks-websocket-proxy:

​
HA‑compliant multi‑sequencer setup

While Flashblocks can be enabled in a single-sequencer setup, we highly recommend running a high-availability (HA) multi-sequencer setup managed by op-conductor. In an HA setup, multiple op-conductor instances form a Raft group. At any time, only one healthy sequencer acts as the active leader responsible for block building, while others remain in follower mode. Leadership changes automatically if the active sequencer becomes unhealthy. For Flashblocks, each sequencer (leader and followers) runs its own dedicated components, including rollup-boost and op-rbuilder. Only the leader’s op-rbuilder produces flashblocks; follower instances remain idle. In this setup, the connection between rollup-boost and the flashblocks-websocket-proxy is mediated by op-conductor.
  • op-conductor listens to Flashblocks from rollup-boost (or op-rbuilder).
  • If it is the active leader, it forwards the Flashblocks to flashblocks-websocket-proxy.
  • If it is not the leader, it does not forward anything.
The rest of the data flow remains unchanged.

​
HA configuration

1. Configure op-conductor to listen for Flashblocks and forward them if leader:
  • Variable descriptions:
    • OP_CONDUCTOR_WEBSOCKET_SERVER_PORT: Port where op-conductor exposes Flashblocks if it is the leader. For example: ws://<op-conductor-url>:8546/ws.
    • OP_CONDUCTOR_ROLLUPBOOST_WS_URL: Direct URL of rollup-boost (or op-rbuilder) where Flashblocks are available. In a single-sequencer setup, this is the same URL you’d pass directly to flashblocks-websocket-proxy.
    • OP_CONDUCTOR_ROLLUP_BOOST_ENABLED: Enables health checks for rollup-boost (and indirectly op-rbuilder) so leadership can fail over if either becomes unhealthy.
    • OP_CONDUCTOR_EXECUTION_RPC: Execution RPC URL of rollup-boost. Same as OP_NODE_L2_ENGINE_RPC configured on op-node.
2. Configure flashblocks-websocket-proxy to consume Flashblocks from all sequencer conductors:
This way, the proxy always connects to the active leader via its op-conductor. Optional rate limits for flashblocks-websocket-proxy:
  • PER_IP_CONNECTIONS_LIMIT: Max connections allowed per client IP.
  • INSTANCE_CONNECTION_LIMIT: Max total connections allowed per proxy instance.

​
Next steps