OP Stack architecture

An OP Stack chain is an optimistic rollup: it executes transactions on its own network, publishes their data to a parent chain, and lets anyone challenge its claims about the resulting state rather than proving each one up front. That makes it a derived chain: its canonical history is defined by data published to a parent chain, and every other part of the system exists to produce that data, to turn it back into blocks, or to convince the parent chain of the result. That single property explains most of the architecture. This page is the system view. It names the parts, says who runs each one, walks one transaction through all of them, and marks where trust actually sits. Each section links the page that owns the detail rather than repeating it, and terms introduced here are defined in the glossary. Examples throughout describe a chain in the standard configuration: Ethereum for data availability, and permissionless fault proofs. Both are configurable, and the sections below mark where a different choice changes the answer.

​

The big picture

Two chains are involved. The parent chain, usually Ethereum, stores the L2’s transaction data and holds the contracts that settle its state. The rollup produces blocks quickly and cheaply, and publishes everything it does back to the parent. Two edges carry most of the security argument. Derivation runs on the sequencer and on every verifier alike, so a verifier reading only Ethereum arrives at the same chain the sequencer built. Forced inclusion binds the sequencer to the same deposit rules as everyone else, which is why a deposit lands even if the sequencer would rather ignore it. See the derivation pipeline.

​

The actors, and who runs each

The OP Stack is a set of separate services rather than one program. The consensus and execution clients run as a pair, one to one, connected over the Engine API. Two implementations of the consensus role exist, op-node in Go and kona-node in Rust, which is what client diversity looks like at this layer. Upgrades of the deployed contracts do not go through op-deployer; see Upgrading the contracts. The security argument rests on verifiers being unprivileged. Anyone can run a rollup node plus an execution client, derive the chain from Ethereum, and detect a sequencer that published something the data does not support. Whether proposing and challenging are equally open depends on the chain’s configured game type, covered in Permissionless and privileged.

​

Life of a transaction

The sequence below follows one transaction through every component on a chain using Ethereum DA. It is the component view; for what the finality labels mean and how long each stage takes, see Transaction finality. The sequencer’s mempool is private, unlike L1 Ethereum’s public one, which limits the MEV opportunities a public pending-transaction pool creates. Ordering is decided by the execution client, not the rollup node. The rollup node’s job at block-building time is to fix what the protocol requires, the L1 origin and the deposits for that epoch, and to leave the rest to the execution client’s mempool. Steps 1 through 5 are run by the chain operator, so they depend on the sequencer behaving. Step 6 is where that dependency ends: once the data is on the DA layer, the block’s ordering is fixed by that layer rather than by the sequencer’s goodwill. On chains streaming Subblocks, applications can act on a preconfirmation within roughly 200 milliseconds of submission, well before step 4. The interval is a target rather than a guarantee. Steps 8 and 9 are a separate track on its own schedule. The proposer posts on a configured interval covering many blocks, not once per transaction, and by default proposes only finalized L2 state. These steps serve withdrawals; they do not advance the chain. A proposal is not self-executing. Its dispute game must resolve in its favor before a withdrawal proved against it can be finalized, and the Guardian can still act during the window that follows. Proving and finalizing a withdrawal are separate steps, described in Withdrawal flow. Transactions can also enter from L1. A user who submits a deposit to the OptimismPortal gets it included in L2 by the derivation rules themselves, which is what makes deposits censorship-resistant. See Deposit flow and Forced transactions.

​

Where data lives, and what you trust

Three different things go to the parent chain, and conflating them is the most common source of confusion about rollup security. An output root is a commitment to the whole L2 chain state at a given block, not the block’s state root alone. It is what a withdrawal proof is checked against. The contracts involved are described in OP Stack smart contracts. Transaction data is what makes the chain derivable. Output roots are what make it settleable. A chain that published data but no output roots would still be a chain anyone could verify, but no one could withdraw from it. A chain that published output roots but no data would be unverifiable, and its proposals uncheckable. The trust boundary moves as a transaction ages. Before its data is published, a user is trusting the sequencer not to reorder or drop it. After, they are trusting the DA layer. The fault proof system governs only the third row: it decides whether a claim about L2 state is accepted on L1, and it does not reorder the L2 chain. A defeated proposal removes a claim about the chain; it does not roll the chain back. See the fault proofs explainer.

​

Topology options

The layered design means several choices are a chain’s to make. Some can be changed later; some are fixed at genesis.

• Standard chain. Ethereum for data availability, ETH for gas, governed upgrades. This is what the blockspace charter defines and what interoperability and shared tooling assume.
• Custom data availability. An Alt-DA layer instead of Ethereum blobs. Cheaper, and the chain’s security becomes a function of that layer’s availability guarantees rather than Ethereum’s. The feature is experimental, and with it the claim that anyone can reconstruct the chain from Ethereum no longer holds: only a commitment reaches L1.
• Custom gas token. A custom gas token as the native fee asset instead of ETH. Configured at genesis, with no migration path: an existing chain would have to coordinate a hard fork.
• Interoperable cluster. Chains in a shared dependency set exchange messages with low latency. In active development; see the interoperability explainer.

The data availability choice is a security decision before it is a configuration change, because that layer determines whether the chain can be derived at all. For the layer-by-layer view of what is swappable, see OP Stack components.

​

Permissionless and privileged

On any OP Stack chain, anyone may run a verifying node and check the chain against the DA layer, submit a deposit through the OptimismPortal, and prove and finalize a withdrawal once the proposal backing it has resolved. Whether anyone may propose or challenge depends on the chain’s respected game type. Under the permissionless FaultDisputeGame, proposing an output root and moving in a dispute game are open to anyone with a synced node and the bonded capital each move requires. Under the PermissionedDisputeGame, which is the fallback and the starting configuration for many new chains, both are restricted to the named Proposer and Challenger addresses. The Guardian chooses which game type the chain respects and can switch back to the permissioned one if the permissionless system fails. Migrating between them is a deliberate operation; see Migrating to permissionless fault proofs. Even where challenging is open, it is not free: playing a game requires a synced honest node, a bond to create or move in a game, gas for every move, and patience for delayed payouts. Named roles include the L1 and L2 Proxy Admins (upgrade the system contracts), the System Config Owner (chain parameters such as the gas limit, and the unsafe block signer key), the Batcher, the Proposer and Challenger under a permissioned game, and the Guardian (pauses withdrawals, blacklists games, and sets the respected game type). Each of these roles, its risks, its mitigations, and its live addresses are on Privileged roles.

​

Next steps

• Follow one transaction in mechanical detail in Transaction flow.
• See the swappable layers and their modules in OP Stack components.
• Find the hub page for any component in Stack Components.
• Read the normative definitions in the OP Stack specifications.