Succinct supports validity and ZK fault proofs for OP Stack rollups with configurable withdrawal timing.

Shared Execution Logic and Different Proof Policies

Kona supplies OP Stack derivation and execution logic; SP1 proves that logic, and the proposer connects the proof to an L1 output claim. OP Succinct and Lite reuse the proving program while applying different acceptance policies. DisputeGameFactory creates the game contracts that the withdrawal portal references. Validity mode requires routine evidence for submitted outputs. Lite initially places a claim into a challenge process, reserving mandatory proving for disputed claims. These policies belong to the rollup's infrastructure. Switching between them requires changes to the proposer service and contract configuration.

Validity Proofs From Block Ranges to Output Roots

Validity proving links consecutive L2 block ranges to a verified output root that the withdrawal contracts can consume.

Range Proofs and Aggregation

The range program proves the derivation and execution needed to advance between output roots. Aggregation combines completed contiguous range proofs into a proof that the L1 verifier can check. Each range can contain multiple blocks. Routine proving therefore does not imply one proof transaction for every user transaction. The standard proposer schedules range and aggregation separately; its publication interval measures L2 blocks. Externally coordinated builds let another service trigger aggregation and require external L1 submission.

Open full-size image

Output Roots and Portal Compatibility

OPSuccinctL2OutputOracle verifies the submitted proof before recording an output in validity mode. With OptimismPortal2, OPSuccinctDisputeGame wraps that oracle operation in the dispute-game interface. Successful initialization establishes a defender-winning result. The portal can therefore consume proven outputs without an interactive challenge process. Its withdrawal requirements remain separate from output verification, including the delays that follow withdrawal proving and game resolution.

What Happens When an OP Succinct Lite Proposal Is Challenged?

An accepted challenge gives the proposal a proof deadline, and a timely valid proof defends the claimed state transition. OP Succinct Lite resolves state-transition disputes through a single-round ZK proof mechanism. An unchallenged claim can instead resolve after its challenge window expires.

Challenge and Proof Deadlines

MAX_CHALLENGE_DURATION bounds the initial challenge window from game creation. An accepted challenge starts a new deadline using MAX_PROVE_DURATION from the challenge timestamp. The challenger posts the required bond without first generating a proof of invalidity. A defending proof must establish the transition against the game's starting root, claimed root, L1 anchor, and rollup configuration.

If a challenged proposal receives no valid proof within its deadline, resolution awards the game to the challenger. That game cannot support withdrawal finalization.

Parent Outcomes and Voluntary Proofs

Child games depend on their parent outcome. A child cannot resolve while its parent remains in progress. If the parent resolves for the challenger, its descendants also resolve for the challenger. A valid proof for the child cannot rescue that branch. Parent dependencies can extend the wait beyond the child's own proof generation time, even when its proposed transition has a valid proof.

Open full-size image

An optional proof can establish an unchallenged proposal before the challenge window ends. Lite's fast-finality proposer mode automates this proactive proving. A successful proof makes the game eligible for resolution when its parent permits it. The remaining portal delays still apply, so game resolution and withdrawal finalization can occur at different times.

When Can an OptimismPortal2 Withdrawal Be Finalized?

An OptimismPortal2 withdrawal becomes finalizable after its proof matures and its supporting game has a finalized, eligible defender-winning result.

Withdrawal Inclusion and Proof Maturity

The withdrawal inclusion proof establishes that a particular withdrawal exists within the output root's committed L2 state. This proof serves a different purpose from the SP1 state-transition proof. OptimismPortal2 starts the withdrawal's proof maturity clock when it records the withdrawal inclusion proof. The portal can record an inclusion proof against an eligible game while that game remains in progress. Its maturity period can consequently overlap with the remaining game-resolution wait.

Game Finality and Remaining Eligibility

Game finality adds a review delay after the supporting game records its resolution. The timing threshold is the later of withdrawal proving time plus the proof maturity delay, or game resolution time plus the game finality delay. These waits can overlap; adding them consecutively can overstate the delay. The deployed portal and AnchorStateRegistry expose the relevant timing configuration. Finalization also requires an eligible game and an unpaused system. Blacklisting or retirement can block finalization. An eligible withdrawal still needs a successful L1 finalization transaction.

Proof Policies and L1 Anchor Settings

The validity proposer selects the L1 anchor that its proof uses, while proof policy governs when the rollup requests evidence. Lite proofs use the L1 anchor recorded in their game; block-tag settings guide their proposer's selection of provable L2 blocks. These settings operate at different layers and can combine within compatible proposer configurations. Using safe or latest L1 data can reduce the wait before proving or proposing, with greater reorganization exposure.

Proof Policies and L1 Anchor Settings

The validity proposer selects the L1 anchor that its proof uses, while proof policy governs when the rollup requests evidence. Lite proofs use the L1 anchor recorded in their game; block-tag settings guide their proposer's selection of provable L2 blocks. These settings operate at different layers and can combine within compatible proposer configurations. Using safe or latest L1 data can reduce the wait before proving or proposing, with greater reorganization exposure.

• Setting: Validity proving Timing Effect: Prove block ranges routinely Control and Required Conditions: Rollup selects the mode; output submission requires a valid proof
• Setting: Lite on-demand fault proving Timing Effect: Generate proofs to defend challenged claims Control and Required Conditions: Challengers must detect and challenge invalid proposals within the window
• Setting: Lite fast-finality proving Timing Effect: Prove proposals before a challenge Control and Required Conditions: Proposer enables the feature; parent and portal requirements remain
• Setting: Oracle optimistic fallback Timing Effect: Accept outputs without proof verification Control and Required Conditions: Oracle owner activates it; proposer authorization governs submission; incompatible with OPSuccinctDisputeGame
• Setting: Finalized L1 anchoring Timing Effect: Wait for a finalized L1 anchor Control and Required Conditions: Operator selects the block tag; withdrawal delays still apply
• Setting: Safe L1 anchoring Timing Effect: Use a safe L1 checkpoint Control and Required Conditions: Ethereum and EigenDA proposer backends require SafeDB for this choice
• Setting: Latest L1 anchoring Timing Effect: Use the L1 tip with configured confirmation depth Control and Required Conditions: Operator chooses confirmation depth; Ethereum and EigenDA proposer backends require SafeDB

Open full-size image

Deployment Controls That Change the Timing Assumptions

Rollup control settings determine who may post or challenge outputs and whether the oracle requires cryptographic verification. AccessManager can restrict Lite proposers and challengers independently. A separate optimistic fallback in OPSuccinctL2OutputOracle accepts outputs without ZK verification through the legacy oracle interface. This mode is incompatible with OPSuccinctDisputeGame. The oracle owner controls its activation and finalization period. If permissionless proposing remains enabled there, any account can submit an unverified root. Its security assumptions differ from validity mode. Estimates also change when an upgrade replaces the portal interface or its delay configuration.