OP Stack Specification

The FaultDisputeGame contract family uses a bisection-based mechanism to resolve L2 output root disputes. It iteratively narrows down disagreements until they reach single instruction steps verifiable via a fault proof virtual machine.

There are two main categories of variants:

1. Permissionless: Any address can participate (e.g., FaultDisputeGame, FaultDisputeGameV2, SuperFaultDisputeGame).
2. Permissioned: Participation is restricted to authorized roles (e.g., PermissionedDisputeGame, PermissionedDisputeGameV2, SuperPermissionedDisputeGame).

Key architectural differences include support for Super Roots (aggregated state across multiple chains) and the use of the Immutable Args Pattern in V2 variants to reduce deployment costs.

The OptimismPortal contract is the primary interface for managing deposits and withdrawals between L1 and L2 chains in an OP Stack system.

Key Capabilities:

• Deposits: Users can create

The Canyon upgrade incorporates the Shapella upgrade from L1 and includes several minor protocol fixes. A key architectural change is the introduction of an L2 block-timestamp activation rule.

To implement this, the upgrade is specified in two locations:

1. The rollup-node via canyon_time.
2. The execution engine via config.canyonTime.

Important: The Shanghai time in the execution engine must be synchronized to match the Canyon time.

The OptimismMintableERC721Factory is a factory contract used to deploy L2 ERC721 tokens that represent L1 NFTs within the OP Stack bridge system.

Key Concepts

• Local Token: An ERC721 token deployed on L2 by this factory that represents a remote token from another chain.
• Deterministic Deployment: The factory ensures that for any unique combination of (Remote Token, name, symbol), at most one Local Token contract is created. This prevents fragmented integrations and user confusion.

The Holocene Network Upgrade is a protocol update for the OP Stack that encompasses changes across the Execution Layer, Consensus Layer, and Smart Contracts.

Key areas of impact include:

• Execution Layer: Introduces Dynamic EIP-1559 Parameters.
• Consensus Layer: Implements Holocene Derivation.
• Smart Contracts: Updates System Config.

The Jovian Network Upgrade is an experimental specification covering changes across the Execution Layer, Consensus Layer, and Smart Contracts.

Note: This specification is currently not finalized and should be treated as experimental.

Upgrade Scope

Execution Layer

Includes specifications for:

• Minimum Base Fee
• DA Footprint Limit
• Operator Fee

Consensus Layer

Includes specifications for:

• Network upgrade transactions applied during derivation.
• Auto-upgrading and extension of the L1 Attributes Predeployed Contract (also known as the L1Block predeploy).

Smart Contracts

Includes specifications for:

• System Config

The L2ERC721Bridge is a contract on an OP Stack L2 chain that enables the transfer of ERC721 tokens between Ethereum L1 and L2. It operates using a paired lock/mint and burn/unlock mechanism:

• L1 to L2 (Deposit): When a deposit is finalized on L1, the bridge mints a corresponding token on L2.
• L2 to L1 (Withdrawal): When a withdrawal is initiated on L2, the bridge burns the token on L2 to allow the user to claim the original token on L1.

The Multithreaded Cannon (MTCannon) Fault Proof Virtual Machine (FPVM) is the second iteration of the Cannon FPVM. It emulates a minimal uniprocessor Linux-based system running on a big-endian 64-bit MIPS64 architecture.

Operationally, the FPVM functions as a state transition function where each Step executes a single instruction. Given an input state $S_{pre}$, the VM produces a new state $S_{post}$ through the function $f(S_{pre}) ightarrow S_{post}$. The execution trace of a program is represented as an ordered set of these VM states.

The FeeSplitter and FeeVault predeploys manage the distribution and withdrawal of L2 fees.

• FeeSplitter: Located at 0x420000000000000000000000000000000000002B. It is a proxied contract that manages the distribution of all L2 fees by collecting funds from various vaults and distributing them to recipients based on calculated shares.
• FeeVaults: These include SequencerFeeVault, L1FeeVault, BaseFeeVault, and OperatorFeeVault. They act as storage for fees and allow configuration of the withdrawal network and recipient via setter functions.

To use the FeeSplitter, vaults must be configured with WithdrawalNetwork.L2 and have the FeeSplitter address set as their recipient.

FeeSplitter Address: 0x420000000000000000000000000000000000002B