Overview

Optimism is an EVM equivalent Layer 2 scaling solution for Ethereum that utilizes optimistic rollup technology to enhance transaction speed and reduce costs. This allows for scalability while benefiting from Ethereum’s security. It’s an efficient approach to achieve blockchain scalability without compromising on trust and security.

As an Optimistic Rollup, Optimism leverages the security of a parent blockchain, in this case, Ethereum. It relies on the consensus mechanism of the parent chain instead of creating its own. Blocks are submitted as transaction calldata on Ethereum, making them tamper-proof once enough attestations are received. This ensures the availability and integrity of OP Mainnet.

After the Bedrock upgrade, blocks are stored on the Ethereum blockchain using a non-contract address to minimize L1 gas expenses. The sequencer primarily manages block production in Optimism, providing transaction confirmations, constructing L2 blocks, and submitting user transactions to L1. Transactions can reach the sequencer through two methods: L1 deposits or direct submission to the sequencer. Currently, The Optimism Foundation runs the only block producer on OP Mainnet, with plans for decentralization in the future.

The execution engine updates itself through a peer-to-peer network with other execution engines. The rollup node derives L2 blocks from L1, providing censorship resistance. Optimism enables the transfer of assets and messages between smart contracts on L2 (e.g., OP Mainnet) and the underlying L1 (e.g., Ethereum mainnet). This communication allows the transfer of assets, including ERC20 tokens, between the two networks, facilitated by mechanisms like the Standard bridge.

Transactions from Ethereum (L1) to OP Mainnet (L2) are called deposits. They are typically included in the first L2 block of the corresponding epoch, a few minutes after the L1 block where the deposits were initiated. Withdrawals, referring to any OP Mainnet to Ethereum message, have three stages: initialization, submission of withdrawal proof, and finalization. The fault challenge period protects OP Mainnet users against potential bridge vulnerabilities. In Optimistic Rollup, state commitments are published to L1 without immediate proof of validity, pending a challenge window. If a state commitment goes unchallenged during this period, it becomes final and safe for withdrawal proofs. Challenges can invalidate state commitments through a “fault proof” process, ensuring the accuracy of published commitments without rolling back OP Mainnet’s state or transaction order.

OP Stack

The OP Stack stands as the standardized, open-source development framework that drives Optimism’s capabilities, maintained by the Optimism Collective.

The OP Stack comprises a collection of software components managed by the Optimism Collective, serving as the foundation for Optimism. Initially powering Optimism Mainnet and, in the future, the Optimism Superchain, this stack plays a crucial role in creating new Layer 2 (L2) blockchains within the proposed Superchain ecosystem. While it simplifies the creation of L2 blockchains, it can extend to various layers, including tools, block explorers, message passing mechanisms, governance systems, and more.

The OP Stack’s evolution is ongoing, adapting to Optimism’s progress. As the Superchain takes shape, the OP Stack will integrate messaging infrastructure to facilitate seamless interaction among different chains. This ensures that the OP Stack evolves in line with Optimism’s requirements.

Optimism Bedrock is the current iteration of the OP Stack, providing the tools for launching production-quality Optimistic Rollup blockchains. The Bedrock release enables the creation of L2s that are compatible with the Superchain when it launches.

Layers of the OP Stack

The OP Stack consists of various layers and modules.

Layers

• Data Availability Layer:
  • Defines where raw inputs to an OP Stack-based chain are published.
  • Different Data Availability modules can be used, impacting the security model of the system.
  • Ethereum DA is the most widely used module, allowing data retrieval from Ethereum blockchain.
• Sequencing Layer:
  • Determines how user transactions on an OP Stack chain are collected and published to Data Availability modules.
  • In the default Rollup configuration, Sequencing is handled by a single Sequencer.
  • Future plans include modular Sequencing for more flexibility.
• Derivation Layer:
  • Defines how raw data in the Data Availability Layer is processed into inputs for the Execution Layer.
  • May use the current system state to process raw input data.
  • Supports multiple sources for Engine API inputs.
• Execution Layer:
  • Defines the structure of state within an OP Stack system and the state transition function.
  • State transitions are triggered by inputs from the Derivation Layer.
  • Allows for EVM modifications or different underlying VMs.
• Settlement Layer:
  • Establishes a view of the state of an OP Stack chain on external blockchains.
  • Used for handling withdrawals of assets from a blockchain.
  • Uses mechanisms like Attestation-based Fault Proof, Fault Proof Optimistic Settlement (proposed), and Validity Proof Settlement (proposed).
• Governance Layer:
  • Manages system configuration, upgrades, and design decisions.
  • Contains mechanisms like MultiSig Contracts and Governance Tokens.
  • Governance Tokens decentralize decision-making through voting.

Modules

• Existing Modules:
  • Ethereum DA: The most widely used Data Availability module, it sources data from Ethereum blockchain, including calldata, events, and data blobs.
  • Single Sequencer: The default Sequencer module where a dedicated actor serves as the Sequencer, with governance determining who can act as the Sequencer.
• Proposed Modules (In Development):
  • Multiple Sequencer: A modification to the Single Sequencer, allowing the selection of Sequencers from a predefined set.
  • Indexer: A proposed Derivation Layer module that derives Engine API inputs from specific smart contracts on a Data Availability Layer module like Ethereum DA.
  • Fault Proof Optimistic Settlement: An alternative to Attestation-based Fault Proof, it uses a permissionless fault proving process to invalidate incorrect proposals.
  • Validity Proof Settlement: Uses mathematical proofs to attest to the correctness of a proposed view.
  • Governance Tokens: Tokens used to decentralize decision-making, allowing token holders to vote on various project decisions.

OP Stack’s Fault Proof System

L2s on Ethereum, while following the same architectural principles as the L1, introduces a new layer known as the “proving layer.” This layer plays a crucial role in securely bridging L2 outputs back into L1. It ensures that the state claims made in L2 are verifiable and secure on the L1 Ethereum network.

Just as L1 Ethereum benefits from having multiple clients for consensus and execution layers, a multi-proof approach is essential for securing the L2’s proving layer. This approach adds layers of security by diversifying the methods of validation.

In this context, there are three common types of proofs used:

• Attestations: These are proofs that verify the correctness or validity of actions taken within the L2. They serve as confirmations of specific events or transactions.
• Fault Proofs (Fraud Proofs): These proofs are critical for identifying and proving instances of fraudulent behavior or malicious actions within the L2. They are essential for maintaining the integrity of the system.
• ZK Validity Proofs: These proofs use zero-knowledge techniques to verify the correctness of state transitions in a synchronous manner. They prove the execution of state changes when given L1 data and L2 pre-state as input.

Within the OP Stack’s architecture, the proof system components are thoughtfully decoupled to enhance security and flexibility:

• Program: This defines the synchronous state transition within L2.
• VM (Virtual Machine): The VM runs and proves the program’s execution.
• Pre-Image Oracle: This component provides the necessary L1 data and L2 pre-state as inputs.

While many ZK-proofs today tightly couple these components, creating a ZK-EVM that operates on singular L1 transaction data, the OP Stack takes a different approach. It decouples these components to isolate complexity and enable client diversity

The OP Stack’s Fault Proof System (FPS) introduces an intriguing facet through its dispute games—a component that adds a layer of engagement and robustness to the ecosystem. Interactive fault proofs introduce a bisection-game to the VM trace to verify the proof on-chain. In contrast, VM-based ZK proofs arithmetize and folds the execution into a validity proof. Both approaches aim to ensure the correctness and security of L2 state transitions.

At its core, a dispute game is a foundational element within the dispute protocol. It operates as a simple state machine initialized with a 32-byte commitment to any disputable information’s validity. The resolution function, defining whether the commitment is true or false, is left to the implementer. The OP Stack’s first implementation of this, the FaultDisputeGame, is permissionless, as its resolution function hinges on a fault proof program’s execution outcome within an emulated VM.

The program defines the actual state transition as a “client,” while the input-fetching component (providing L1 data and L2 pre-state) acts as the “server.” Operating independently with server/client interactions but without a VM, the program closely resembles a regular blockchain node. This design philosophy allows for the reuse of code and promotes code efficiency.

Dispute games rest on two critical properties:

• Incentive Compatibility: The system rewards truthful claims and penalizes false ones, ensuring fair participation.
• Resolution: Each game possesses a mechanism to definitively validate or invalidate the root claim.

In the Dispute protocol, various dispute games can be crafted, managed, and upgraded through the DisputeGameFactory. This extensibility opens doors to innovative features, such as aggregate proof systems, and the potential to dispute elements beyond L2 state, like a FaultDisputeGame tailored for on-chain binary verification.

The Bisection Game, a specific dispute game within the protocol, is the inaugural game built on the OP Stack’s dispute protocol. This game involves players iteratively dividing an execution trace into individual steps. Once these steps reach commitments to the state at each instruction, the FaultDisputeGame executes a single instruction step on-chain using a generic VM. This VM’s state transition function, denoted as T(s, i) -> s’, can take any form, as long as it adheres to this format.

Key components of the Bisection Game include:

• Claims: Represent commitments to the state of the VM at a specific instruction. These claims can be true or false, with their veracity determined during the resolution phase.
• Positions: Claims are associated with positions in a binary tree, indicating which instruction the claim relates to. Positions are generalized indices.
• Chess Clocks: Players operate under time limits for their moves, with a total game time of 7 days, divided into 3.5 days per side.
• Moves: Players bisect the game until claims commit to the state of a single VM instruction. Moves can be attacks (challenging a parent claim) or defenses (agreements with a parent claim).
• Instruction Step: At the leaf nodes of the position tree, claims commit to the state at a single VM instruction, with the final move being the execution of that instruction on-chain for verification.

Resolution occurs when chess clocks for all claims run out, with a minimum duration of 3.5 days. Each claim spawns its own Sub Game—a DAG with a depth of 1. Sub games rely on the resolution of their child sub games for their own resolution. An honest player’s presence, assuming all moves are exhausted, ensures a favorable resolution for their view of the trace, regardless of the root claim’s honesty. Dishonest claims are susceptible to counters by any party.

Functional Overview of the FPVM

The Fault Proof VM (FPVM) is a critical component within the OP Stack’s fault proof architecture, providing essential functionality to ensure the correctness and security of Layer 2 (L2) Ethereum. It does not implement Ethereum-specific or L2-specific logic directly but provides essential interfaces, most notably the interface to the pre-image oracle. The core responsibility of the FPVM is to execute lower-level instructions within the L2 state transition.

The FPVM distinguishes itself from the Fault Proof Program (FPP), which runs within the FPVM. The FPP represents the client-side logic that defines the L2 state-transition. This separation allows the FPVM to remain minimal and unaffected by Ethereum protocol changes or L2-specific requirements. Instead, updates can be made to the FPP to incorporate changes.

• The FPVM’s requirements are minimal, as it primarily handles synchronous program execution and loads all inputs through the pre-image oracle.
• The FPVM ensures that the program’s execution is in line with the FPP’s definition, and it facilitates the interaction between the program and the oracle.

The FPVM adopts a granular approach to instruction proving. Instead of proving an entire execution trace, it focuses on proving one instruction at a time. This granularity allows for precise validation and verification of each instruction, enhancing security and reducing the complexity of on-chain proofing.

To prove an instruction, the FPVM follows a structured process that generally resembles the Cannon approach:

1. Reading from Memory: The FPVM reads the instruction from memory.
2. Interpretation: It interprets the instruction, executing it within a thread context.
3. Register and Memory Updates: The instruction may lead to changes in the register file and memory.
4. Pre-Image Oracle Interaction: To support the pre-image oracle and basic program runtime requirements like memory allocation, the execution supports a subset of Linux syscalls.
5. Syscalls for Pre-Image: Read/write syscalls facilitate interaction with the pre-image oracle. The program can request a pre-image by writing a hash and then retrieve the value in small increments.

FPVM to ZKVM

While fault proofs are a crucial aspect of ensuring the integrity of state transitions, there are alternative approaches, such as Zero-Knowledge (ZK) validity-proofs, that offer distinct advantages, including speed and efficiency. The transition from FPVM (Fault Proof VM) to ZKVM can represent a significant evolution in the OP Stack’s capabilities and flexibility.

• ZK validity-proofs offer the potential for rapid bridging between different layers of Ethereum.
• Unlike fault proofs, there is no on-chain challenge game for ZK validity-proofs, meaning there is no specific dispute window. This can lead to faster and more seamless validation

To accommodate a more advanced Ethereum stack and support different client implementations, it’s essential to decouple the VM and the program. This decoupling ensures that the VM can evolve independently of the program, providing flexibility and adaptability.

• The ZK RFP (Zero-Knowledge Request for Proposals) projects are embracing the approach of proving a minimal VM. For example, Risc0 is working on proving a minimal RISC-V VM, while O(1) Labs is focusing on a MIPS VM.
• These VMs are designed to be compatible with the same program used in fault proofs, ensuring consistency and interoperability.
• To enable the support of ZKVM, some modifications are required to make the pre-image oracle load data non-interactively. This adjustment streamlines the process for ZK validity-proofs.
• By taking this approach, the ZKVM can remain future-proof, allowing for smoother transitions and upgrades as the Ethereum ecosystem evolves.

Optimism Bedrock

Optimism Bedrock is the latest official release of the OP Stack, designed to facilitate the creation of production-ready Optimistic Rollup blockchains. It comes with several significant improvements over its predecessor:

• Reduced Transaction Fees:
  • Optimism Bedrock implements optimized batch compression, reducing transaction fees.
  • Ethereum is utilized as a data availability layer, further optimizing data handling.
  • The removal of L1 execution gas reduces L1 data fees to the theoretical minimum, resulting in an additional 10% reduction in fees compared to the previous version.
• Shorter Deposit Times:
  • Bedrock introduces support for L1 re-orgs in the node software, significantly reducing deposit confirmation times.
  • Deposits are expected to confirm within 3 minutes, a substantial improvement from the earlier 10-minute wait.
• Improved Proof Modularity:
  • Bedrock abstracts the proof system from the OP Stack, allowing rollups to use either fault proofs or validity proofs like zk-SNARKs.
  • This abstraction enables the use of systems like Cannon to prove faults within the system.
• Enhanced Node Performance:
  • The node software’s performance is significantly improved by allowing multiple transactions in a single rollup “block,” replacing the previous “one transaction per block” model.
  • This change reduces state growth by approximately 15GB/year at current transaction volumes.
  • Technical debt from the previous version is removed, streamlining the node software and eliminating the need for a separate “data transport layer” node for indexing L1.
• Improved Ethereum Equivalence:
  • Bedrock aims to closely resemble Ethereum in its design.
  • Deviations from Ethereum in the previous version, such as the one-transaction-per-block model, custom opcodes for L1 block information, separate L1/L2 fee fields in the JSON-RPC API, and a custom ERC20 representation of ETH balances, have been removed.
  • Bedrock adds support for Ethereum features like EIP-1559, chain re-orgs, and others present on L1.

Design Principles of Optimism Bedrock

• Modularity:
  • Bedrock is built with a focus on modularity, allowing for the easy interchange of different components within the OP Stack.
  • It employs well-defined interfaces and versioning schemes, enabling a flexible architecture that can adapt to future developments in the Ethereum ecosystem.
  • Examples of modularity include the separation of the rollup node and execution client and the modular fault proof design.
• Code Reuse:
  • Bedrock maximizes the use of existing Ethereum architecture and infrastructure to inherit security and reliability benefits from battle-tested Ethereum codebases.
  • Examples include the use of minimally modified execution clients and EVM contracts instead of precompiled client code.
• Ethereum Equivalence:
  • Bedrock is designed to closely resemble Ethereum to provide a familiar developer experience.
  • While it maintains Ethereum compatibility, some exceptions exist due to fundamental differences between L1 and a rollup, such as an altered fee model, faster block time (2s vs. 12s), and a special transaction type for including L1 deposit transactions.
• Protocol Components:
  • The core components of the protocol include Deposits, Withdrawals, Batches, Block Derivation, and Proof Systems.
  • Deposits on L1 are guaranteed to be included in the canonical L2 chain, preventing censorship or control of the L2.
  • Withdrawals are cross-domain transactions initiated on L2 and finalized on L1, enabling various interactions between L2 and L1.
  • Batches are organized groups of L2 transactions, optimized for data compression and parallelized batch submission.
  • Block Derivation ensures the correct timing of deposits, handles timestamps on L1 and L2, and guarantees that the L2 block timestamps stay synchronized with L1.
• Deposits:
  • Deposits on L1 are transactions that are to be included in the rollup, guaranteeing their inclusion in the L2.
  • Deposited transactions on L2 are derived from the values in the event(s) emitted by a deposit contract on L1.
  • Bedrock specifies a gas burn mechanism and a fee market for deposits to prevent denial of service attacks.
• Withdrawals:
  • Withdrawals are cross-domain transactions initiated on L2 and finalized on L1.
  • Bedrock introduces a two-step withdrawal process to enhance security and reduce the risk of bridge compromises.
• Batches:
  • Batches are the wire format for messaging between L1 and L2, designed to minimize costs and software complexity for writing to L1.
  • Optimized data compression is used, and messages are parallelized for efficient submission.
  • Batch transactions remove all execution gas used by the L1 system, reducing costs.
• Block Derivation:
  • The protocol ensures the timing of deposits on L1 is respected with regards to the block derivation of the canonical L2 chain.
  • Sequencing epochs and sequencing windows play a crucial role in this process.
  • Handling L1 and L2 timestamps, along with a block derivation pipeline, are key aspects of block derivation.
• Fault Proofs:
  • Fault proofs are used to ensure trustless execution of L2-to-L1 messaging, such as withdrawals.
  • Outputs are hashed in a tree-structured form to minimize the cost of proving any piece of data.
  • Proposers periodically submit output roots, which are Merkle roots of the entire canonical L2 chain.

Bedrock Implementation

Optimism Bedrock, part of the OP Stack, is implemented with a strong emphasis on technical separation of concerns and compatibility with Ethereum principles. 

Execution Client

The Execution Client is responsible for determining the state of the canonical L2 chain, processing inbound transactions, and managing the system’s state. Bedrock relies heavily on Ethereum’s execution client specifications and existing implementations, particularly go-ethereum.

Modifications to go-ethereum are minimal, primarily related to handling deposited transactions and charging transaction fees. Deposited transactions are represented using a new transaction type compliant with the EIP-2718 typed transactions standard.

Transaction fees in Bedrock consist of sequencer fees and data availability fees, both combined into a single gasPrice field in the JSON-RPC.

Rollup Node

Unlike Ethereum, Bedrock doesn’t employ proof-of-stake consensus. Instead, consensus in the canonical L2 chain is established through block derivation.

The Rollup Node is a stateless component responsible for deriving the system’s state by reading data and deposits on L1. Rollup Nodes can be used in multiple ways:

• Verifying the Canonical L2 Chain: In this mode, the node verifies the correctness of output roots shared by other nodes or posted on L1.
• Participating in the L2 Network: Most commonly, Rollup Nodes participate in a network of nodes tracking L2 progression and state. They read data and deposits from L1, interpret blocks, and accept transactions from users and peers.
• Sequencing Transactions: Some Rollup Nodes operate as sequencers, creating new blocks on top of the unsafe L2 head. Currently, there’s typically one sequencer per OP Stack network.

Sequencers are responsible for producing batches, and a separate component called the Batcher reads transaction data from a trusted Rollup Node and converts it into batcher transactions to be written to L1.

Bedrock includes a pair of standard bridge contracts for common types of deposits, simplifying the process of depositing and withdrawing ETH and ERC-20 tokens.

While fault-proof construction and verification are implemented in the Cannon project, the integration of an output root challenger into the Rollup Node is part of later specification milestones.

Bedrock Differences

EVM Changes

• Block Production:
  • Blocks are produced every two seconds, which is a departure from the legacy network, where blocks are mined for every incoming transaction.
  • The TIMESTAMP opcode returns the timestamp of the block, updating every two seconds.
  • The BLOCKNUMBER opcode returns the actual block number, updating every two seconds. This means the one-to-one mapping between blocks and transactions no longer applies.
  • The upgrade introduces “system transactions” created by the op-node for executing deposits and updating the L2’s view of L1.
• EIP-1559:
  • Optimism Bedrock supports EIP-1559, which changes the gas fee calculation with two components: the base fee and the priority fee.
  • Unlike Ethereum, $ETH is not burned on Bedrock when using EIP-1559. Burning $ETH would lock it in the bridge forever.
  • Some EIP-1559 parameters are different from Ethereum, including block gas limit, block gas target, EIP-1559 elasticity multiplier, EIP-1559 denominator, maximum base fee increase, maximum base fee decrease, and block time in seconds.
  • The L1 security fee uses the same mechanism as before but is submitted to a non-contract address, reducing the L1 security fee by about 20%.
• Removed Opcodes:
  • The Bedrock upgrade aims to be maximally EVM equivalent, and it removes the L1BLOCKNUMBER opcode to reduce differences between Bedrock’s EVM and Ethereum’s EVM.
• ETH Balances: 
  • Bedrock migrates ETH balances from an ERC20 contract called OVM_ETH into the Bedrock network’s state. The OVM_ETH contract’s methods continue to work, but the totalSupply() method will return zero.
• Chain Reorgs:
  • Bedrock nodes always derive blocks from L1, so if L1 experiences a reorg, L2 will reorganize itself to match L1’s state.
  • Blocks can be in one of three states: unsafe (not yet submitted to L1), safe (submitted to L1), and finalized (considered final and irreversible).
• Historical Data:
  • Bedrock nodes can serve pre-Bedrock block bodies, transactions, and receipts, but historical execution traces require running a Legacy Geth instance.
  • Some legacy fields have been removed from pre-Bedrock JSON-RPC transaction responses.
• JSON-RPC: 
  • Bedrock supports standard JSON-RPC methods exposed by go-ethereum. Some legacy methods have been removed or replaced to reduce differences between Bedrock and Ethereum.
• Mempool:
  • Bedrock introduces a private mempool to store pending transactions until they are included in a block, unlike Ethereum’s first-come-first-serve transaction processing.
  • Users need to configure op-geth to forward transactions to the sequencer for submission.
• Two-phase withdrawals:
  • Bedrock implements a two-phase withdrawal process to enhance security and prevent fraudulent withdrawal proofs.
  • Users must post withdrawal proofs upfront, wait for validation, and then finalize the withdrawal after a seven-day waiting period.
  • This change is not backward-compatible, and software relying on old withdrawal methods needs to be updated.

• Deposit Replayability:
  • Deposits are no longer replayable in Bedrock, unlike the legacy network where they were replayable.
  • Deposits on the legacy network that have not been replayed are no longer replayable as part of the migration.

Contracts Changes

Optimism Bedrock includes various contracts that play crucial roles in the operation of the network. 

L1 Contracts:

• L2OutputOracle:
  • This contract contains the state root of the Optimism blockchain (OP Mainnet, OP Goerli, etc.).
  • It receives the result of the fault proof process once fault proofs are activated, replacing the old State Commitment Chain.
• OptimismPortal:
  • The OptimismPortal contract provides a low-level API for communication between different layers.
  • It’s recommended to use the L1CrossDomainMessenger and L2CrossDomainMessenger for sending messages between L1 and L2 unless bypassing the sequencer is necessary.
• Existing Interface Contracts:
  • These contracts maintain the same interface as existed pre-Bedrock to ensure that dApps don’t require significant modifications:
  • L1CrossDomainMessenger: Used for sending messages between L1 and L2, which may or may not have assets attached.
  • L1StandardBridge: Utilizes L1CrossDomainMessenger to transfer ETH and ERC-20 tokens between L1 and L2.

L2 Contracts

• L1Block:
  • The L1Block contract provides information about the latest L1 block known to L2.
  • It includes parameters such as block number, timestamp, base fee, hash, and sequence number.
  • Note that L1 information is delayed by two block confirmations to mitigate the impact of reorganizations.
• SequencerFeeVault:
  • This contract handles funding the sequencer on L1 using the ETH base fee on L2.
  • Fees are calculated using EIP 1559, similar to Ethereum, but with different parameter values.
• L2ToL1MessagePasser:
  • Used internally by L2CrossDomainMessenger to initiate withdrawals.
  • There are two contracts in Bedrock, the legacy contract, and the new contract, each with its specific address.
• Existing Interface Contracts:
  • Similar to L1 contracts, these contracts maintain the same interface as pre-Bedrock:
  • L1BlockNumber: Provides the number of the latest L1 block, serving as a proxy to L1Block.
  • L2CrossDomainMessenger: Used for sending messages from L2 to the underlying L1.
  • L2StandardBridge: Used to “attach” assets (ETH and ERC-20 tokens) to messages sent by L2CrossDomainMessenger.
  • WETH9: An ERC-20 token that wraps ETH to provide extra functionality like approvals.

Historical Contracts:

• These contracts are no longer relevant but are retained as part of the state for compatibility:
  • DeployerWhitelist: Previously used to manage whitelists before OP Mainnet moved out of beta.
  • OVM_ETH: Previously used to manage user ETH balances before Bedrock.

Communication Between Layers

In Optimism Bedrock, the terminology around “deposits” and “withdrawals” is specific and essential to understand how messages flow between the underlying L1 blockchain and L2.

Deposits from L1 to L2:

• Recommendations for Creating Deposits: To create a deposit from the underlying L1 blockchain (Ethereum, Goerli, etc.) to L2 (OP Mainnet, OP Goerli, etc.), several options are available, including pre-Bedrock contracts like L1StandardBridge and low-level deposit functionality in L1CrossDomainMessenger.
• OptimismPortal’s depositTransaction: The OptimismPortal contract provides the depositTransaction function, allowing you to perform various actions on L2 from L1. This includes sending transactions, making payments, creating contracts, and more. Importantly, this provides an uncensorable alternative in case the sequencer (which orders transactions on L2) is temporarily down. Verifiers on L2 will still receive these transactions and update the state. When the sequencer is back online, it processes these transactions in the same order to maintain a valid state.
• Buffer for Gas Estimation: It’s recommended to add a 50% buffer to the gas estimate obtained from eth_estimateGas when creating deposits. For example, if the estimated gas consumption is 100,000, you should send the transaction with a gas limit of at least 150,000. This buffer helps ensure that your deposit won’t run out of gas during execution.
• Deposit Fee Adjustment: To prevent potential DOS attacks on Optimism networks via forced L1 to L2 transactions that bypass the Sequencer, a fee adjustment schedule is implemented, closely resembling EIP1559. Deposit fees for L1→L2 transactions are paid by burning a certain amount of L1 gas, which is proportional to the deposit’s L2 gas limit. This means that the actual cost of an L1→L2 deposit may increase by the time the transaction is included in a block and executed. Therefore, adding a 50% buffer to the gas limit is crucial to ensure the deposit won’t run out of gas and revert.
• Address Aliasing for Contract Deposits: Deposits from contracts still use address aliasing, which is a mechanism to handle addresses consistently between L1 and L2.
• Faster Confirmation: Deposits from L1 to L2 are faster, taking about a minute to confirm, as they require only five blocks for confirmation, and L1 blocks are typically produced every 12 seconds.

There is no longer a CTC (canonical transaction chain) contract. Instead, L2 blocks are saved to the Ethereum blockchain using a non-contract address to minimize the L1 gas expenses. 

Bedrock: Node Operator Guide

Github Specs

In a Bedrock deployment, there are two main components, and a third component may be required for specific networks:

• Rollup Node (op-node):
  • Derives blocks from L1 (Layer 1 Ethereum) and passes them to the Execution Engine.
  • Participates in a peer-to-peer network to synchronize unsubmitted blocks created by the sequencer.
  • Serves as Optimism’s consensus client.Communicates with the Execution Engine via JSON-RPC using the Engine API.
• Execution Engine (op-geth):
  • Executes the blocks received from the Rollup Node.
  • Stores the state of the blockchain.
  • Exposes standard JSON-RPC methods for querying blockchain data and submitting transactions.
  • Acts as Optimism’s execution client.
  • Communicates with the Rollup Node via JSON-RPC using the Engine API.Note: It is a minimal fork of go-ethereum.
• Legacy Geth (Optional for OP Mainnet and OP Goerli):
  • Serves execution traces for historical transactions that occurred before the Bedrock upgrade.
  • Supports historical execution data.
  • When an RPC call requires historical execution traces, the Rollup Node forwards the request to Legacy Geth.
  • Requests for historical data on Bedrock networks are served directly by the Execution Engine for networks like OP Sepolia.

The communication between the Rollup Node and Execution Engine is facilitated by JSON-RPC via the Engine API, similar to how Ethereum networks operate. These components work together to ensure the proper functioning of the Optimism network. Depending on the specific network you are deploying on, you may or may not need Legacy Geth to handle historical execution traces.

• System Requirements:
  • op-node: Minimum 2 CPUs, 4GB RAM, no storage required.
  • op-geth: Minimum 4 CPUs, 8GB RAM, at least 40GB storage for OP Goerli or OP Sepolia, 600GB for mainnet (SSD required).
  • Download op-geth and op-node as Docker images or compile them from source.
• Node Configuration:
  • Configure op-node to point to the correct L1, op-geth, and L2 network.
  • Initialize op-geth with the correct network parameters.
  • Configure op-geth to communicate with the Rollup Node.
  • Optionally, configure Legacy Geth if needed for historical execution data.
• Configuring op-geth:
  • Initialize op-geth using either a Genesis File or a Data Directory, depending on the network.
  • Ensure sufficient disk space for the network’s data.
  • Configure op-geth using CLI flags, including –rollup.historicalrpc, –rollup.sequencerhttp, and others based on your needs.
  • Generate a JWT secret for authentication.
  • Configure op-geth’s authenticated RPC endpoint.
• Configuring op-node:
  • op-node is a standalone binary with no state or initialization.
  • Configure it using command line flags or environment variables.
  • Specify network-specific genesis parameters using a rollup config file or –network flag.
  • Participate in the peer-to-peer network to distribute blocks.
• Configuring Peer-to-Peer Networking:
  • Ensure op-node has a static IP address accessible from the public internet.
  • Open port 9003 on your firewall for incoming unsubmitted blocks.
  • Set up a load balancer with an external IP for Kubernetes deployments.
• Legacy Geth (if needed):
  • Run Legacy Geth alongside op-geth for upgraded networks (e.g., OP Mainnet, OP Goerli) to serve historical execution traces.
  • Configure Legacy Geth with appropriate flags and specify –rollup.historicalrpc in op-geth.
• Troubleshooting:
  • Address and resolve common issues like authentication errors, forbidden hosts, failed P2P config, and wrong chain configurations.
  • Ensure all components are running correctly, and your Bedrock node is actively participating in the Optimism network.
  • Monitor the node’s performance and maintain it as needed to ensure optimal functionality.
• Resources:
  • Optimism’s Node Operator Guide
  • Node Upgrade Guide
  • Wallet Upgrade Guide
  • Important Metrics

Transaction Flow

The transaction process for rollups on OP Mainnet involves two essential steps to ensure data integrity and state consistency across Layer-1 (Ethereum) and Layer-2 (OP Mainnet).

Writing the Transaction to L1

The primary mechanism for ensuring that transactions are recorded on L1 is through the use of op-batcher. This component compresses multiple transactions into batches for efficiency and cost-effectiveness. These batches are then posted to L1, securing their availability and integrity. The batcher operates within specific parameters to manage the timing and size of these batches:

• Compression: Transactions are compressed into batches to optimize the data size before being written to Ethereum. This process not only enhances throughput but also aims at achieving a favorable compression ratio to reduce costs.
• Posting to L1: Once a batch is prepared and reaches its designated size or the maximum allowable time limit, it is then posted to L1. The status of these transactions can vary:
  • Unsafe: Transactions are processed but not yet confirmed on L1; they risk being dropped if a batcher fault occurs.
  • Safe: Transactions are confirmed on L1 but are subject to potential reorganization of blocks on Ethereum.
  • Finalized: Transactions are embedded in an Ethereum block that is highly unlikely to be reorganized, making them irreversible.

Once written to L1, the transaction must be executed to modify the state on L2, which is handled by op-geth. After execution, op-proposor is responsible for writing a commitment to the post-transaction state back to L1. This commitment does not need to occur after every single transaction but can be done after a block of transactions, enhancing efficiency.

• State Processing: The actual modification of the state is executed by op-geth, which applies the transaction to the existing state, resulting in a new state. This is followed by:
• Proposing the New Merkle Root: op-proposor then posts the new state’s Merkle root to the blockchain. The use of Merkle roots helps in managing the size of the data that needs to be written back to L1, significantly reducing costs.

Determining the status of a transaction involves checking whether it is unsafe, safe, or finalized. This can be done using tools like Foundry, where you can query the number of the block containing your transaction and compare it to the latest finalized or safe block number.

The process outlined ensures that all transactions are not only processed efficiently but also maintain a high level of integrity and security. Once a transaction is finalized, it is considered immutable, although the state it leads to can still be subject to fault challenges. 

Deposit Flow

The deposit flow in Optimism is a mechanism that enables transactions to seamlessly transition from Layer-1 (Ethereum) to Layer-2 (OP Mainnet). This process ensures that transactions are not only executed efficiently but also maintain their integrity and security across layers.

The deposit transaction begins at Layer 1, where a smart contract or an externally owned account (EOA) initiates a deposit to the L1CrossDomainMessenger. This involves specifying the target address on L2, the calldata (formatted as per the ABI of the target L2 account), and a minimum gas limit for the transaction execution on L2:

• Triggering a Transaction: A transaction is initiated using the sendMessage function of the L1CrossDomainMessenger. This function requires the target L2 address, the transaction’s calldata (aligned with the ABI of the target account on L2), and a minimum gas limit necessary for executing the transaction on L2.
• Data Handling and Transmission: The transaction details are then processed through the _send function of the messenger, which ensures that all necessary information is correctly packaged and sent to the corresponding L2 messenger.

Once the data reaches Layer 2, it undergoes the following steps to ensure accurate execution:

• Event Detection: The OP Node on L2 monitors for TransactionDeposited events from L1, extracting the necessary data to process the incoming transaction.
• Executing the Transaction: The extracted data is used to construct and execute the deposit transaction on L2, typically involving the relayMessage function of the L2CrossDomainMessenger. This function conducts the requisite checks before executing the transaction against the designated target contract.

Optimism incorporates several mechanisms to prevent Denial of Service (DoS) attacks during the deposit flow, ensuring both network stability and security:

• Gas Limit Specifications: To prevent abuse and ensure the transaction is processed within resource limits, a specific gas limit is set, which is included in the TransactionDeposited event. This limit reflects the cost of processing the transaction on L2.
• Handling Transaction Failures: If a deposit fails due to issues like insufficient gas, it can be replayed with an adjusted gas limit to accommodate for higher processing costs, ensuring the transaction eventually succeeds.

Withdrawal Flow

The process of withdrawing funds from Layer 2 (such as OP Mainnet) to Layer 1 (Ethereum mainnet) within the Optimism network involves a series of steps designed to ensure the security and verifiability of transactions. This process involves a sequence of transactions to ensure security and verifiability of the withdrawal.

Withdrawal Process

1. Initiation on L2:
   • Users start the withdrawal process by sending a transaction on L2 using the L2CrossDomainMessenger’s sendMessage function.
   • This function takes essential parameters like the target L1 address and the necessary transaction calldata, packaging these into a message set for L1.
2. Verification on L1:
   • Once the transaction reaches L1, a verification process kicks in to confirm its legitimacy. This involves checking the details against a recorded commitment on the L1 blockchain.
   • The transaction must be proven legitimate through a specific proving transaction submitted to L1.
3. Finalization on L1:
   • After ensuring the transaction’s authenticity and following a fault challenge period to prevent errors or fraud, the withdrawal is ready for finalization.
   • The finalization involves executing the transaction on L1, effectively transferring the assets from L2 to the specified L1 address.

Security Measures and Considerations

• Gas Limitations: The system enforces a minimum gas limit to ensure that the L1 transaction can execute properly without running out of gas. Extra gas is accounted for potential computations needed during the withdrawal process.
• DoS Prevention: By requiring specific gas limits and fees, the system prevents denial of service attacks that could occur if malicious entities trigger excessive computations without appropriate fees.
• Fault Challenge Period: This period is critical to safeguard against incorrect or fraudulent withdrawals, ensuring that all transactions are verified and legitimate before being finalized.

Usage and Accessibility

The process is designed to be user-friendly, with most of the technical complexities handled by backend processes. Users interact primarily through simple function calls to initiate and finalize withdrawals.

Superchain

Optimism’s Superchain envisions a multi-chain solution that addresses the limitations of Ethereum’s scalability while maintaining the integrity of the ecosystem. The Superchain builds on the OP Stack and aims to provide horizontal scalability and a unified network of chains, known as OP chains.

The concept of a Superchain represents a major scalability improvement to the OP Stack, aiming to create a network of interconnected chains that share various components and features. To achieve horizontal scalability, multiple chains are necessary, as hardware requirements increase linearly with chain computation. Running chains in parallel is essential to enable scalability without compromising performance.

The current state of blockchain technology faces scalability constraints that hinder the realization of a decentralized web. These scalability issues have prevented many web applications from running on-chain effectively.

In scenarios where blockchain scalability challenges are solved, and on-chain transactions become as cheap as interacting with centralized backends, developers wouldn’t need to worry about backend infrastructure, as the chain guarantees correct execution, uptime, and scalability. Composability, facilitated by shared smart contract execution, would far surpass traditional REST APIs. Additionally, standardized gas markets would reduce infrastructure costs for users, making monetization easier. This would enable highly scalable web applications without the need for a traditional backend, revolutionizing application development.

The Superchain is a conceptual architecture that addresses blockchain scalability. It relies on multiple chains working in parallel to achieve horizontal scalability. By abstracting the notion of chains and making them interchangeable compute resources, the Superchain aims to solve the limitations of traditional multi-chain architectures, including new security models and costly deployments. This allows developers to build cross-chain applications without introducing systemic risk or incurring excessive overhead.

Properties of the Superchain

Property	Purpose
Shared L1 blockchain	Provides a total ordering of transactions across all OP Chains.
Shared bridge for all OP Chains	Enables OP Chains to have standardized security properties.
Cheap OP Chain deployment	Enables deploying and transacting on OP Chains without the high fees of transacting on L1.
Configuration options for OP Chains	Enables OP Chains to configure their data availability provider, sequencer address, etc.
Secure transactions and cross-chain messages	Enables users to safely migrate assets between OP Chains.

Upgrading Optimism to Become a Superchain

The transition of Optimism into a Superchain requires several key changes beyond the Bedrock release. These changes are vital for the deployment and upgradability of multiple chains using the same bridge. 

1. Upgrade Bedrock Bridge to a Chain Factory:
   • The current SystemConfig contract introduced by Bedrock partially defines L2 chains via L1 smart contracts. This concept can be extended by incorporating all L2 chain information on-chain. This includes generating a unique chain ID and configuring values such as block gas limit. By making chain data entirely on-chain, a factory can be developed to deploy configurations and required contracts for each chain. Deterministic contract addresses can also be introduced using CREATE2, simplifying chain interaction and reducing deployment costs.
2. Derive OP Chain Data with the Chain Factory:
   • Building on Bedrock’s L2 chain derivation, where chain data syncs based on L1 blocks, integrating the L1 chain factory enables Optimism nodes to deterministically sync any OP Chain given an L1 address. This process computes chain state locally, ensuring permissionless and secure determination of OP Chain state. While no proof system is needed for chain derivation, Superchain withdrawals still require a proof system.
3. Permissionless Proof System for Withdrawals:
   • Bedrock introduced a permissioned entity (proposer) for user withdrawals, leading to linear overhead as Superchain chains increase and limitations due to L1 resources. To overcome this, two features can be introduced:
     • Withdrawal Claims: Allow anyone to submit withdrawals, eliminating the need for a designated proposer.
     • Remove Proposal Submission Interval: Enable withdrawal claims when users require withdrawals, reducing overhead.
   • These features can be supported by a permissionless proof system in Optimism’s bridge contracts, allowing fault-proof-based withdrawal claims. Claims can be submitted with attached bonds, acting as collateral. Challengers can challenge claims, with successful challenges receiving bonds as rewards. Attestations from chain attestors can be used to challenge invalid claims.
4. Configurable Sequencer per OP Chain:
   • Bedrock’s sequencer address feature in the SystemConfig contract can be expanded for modular sequencing. OP Chains can configure their sequencer addresses during deployment, fostering sequencer decentralization. This modular approach permits experimentation with sequencing models, facilitating the emergence of user-friendly sequencing standards.
5. Shared Upgrade Path for OP Chains:
   • To ensure secure and decentralized upgrades, a decentralized security council can be introduced. This council can manage chain attestation sets, initiate contract upgrades, and execute an emergency bridge pause. This pause mechanism can address emergencies, even if private keys are compromised, by freezing L1 funds to prioritize safety over liveness.
6. Unfreezing the Bridge via L1 Soft Fork:
   • In case of frozen funds due to emergencies, the potential “L1 Soft Fork Upgrade Recovery” mechanism can be considered. This mechanism allows L1 to initiate a bridge upgrade with a soft fork, bypassing Superchain bridge contract permissions. This approach requires further research and community buy-in.
7. Achieving the Core Superchain Properties:
   • These upgrades collectively establish a system that fulfills core Superchain properties, including a shared bridge for OP Chains, cost-effective chain deployment, configuration flexibility, secure transactions, and cross-chain messaging. The combination of these changes ensures Optimism’s evolution into a Superchain ecosystem that offers enhanced scalability, interoperability, and security.

Extending the Superchain – Enhancements to Realize the Vision

The proposed enhancements to extend the Superchain and realize its vision address several pain points in blockchain scalability and functionality:

• Multi-Proof Security:
  • Pain Point: Withdrawal claims rely on a trusted set of chain attestors.
  • Proposed Solution: Introduce permissionless proofs, like Cannon, for dispute resolution. Implement a multi-proof system for redundancy to ensure safety.
• Low Latency L2 to L2 Message Passing:
  • Pain Point: Cross-Chain transactions are slow because they require waiting a challenge period.
  • Proposed Solution: Utilize the OP Stack’s modular proof system to achieve low latency L2 to L2 message passing. This enables different bridge types with varying security and latency.
• Synchronous Cross-Chain Transactions:
  • Pain Point: Cross-Chain transactions are asynchronous, preventing atomic cross-chain transactions.
  • Proposed Solution: Introduce synchronous cross-chain messaging with shared sequencing protocols on both OP Chains, enabling atomic cross-chain interactions, including complex transactions like cross-chain flash loans.
• Alt-Data Availability Layer — Plasma Protocol:
  • Pain Point: Posting transactions to the Superchain is not scalable due to limited L1 capacity.
  • Proposed Solution: Implement a Plasma protocol to extend data availability accessible to OP Chains. Plasma data is cheap, and users interested in transaction data download it, reducing scalability constraints on L1.
• Multi-Chain dApp Frameworks:
  • Pain Points: Lack of easy frameworks for building scalable dApps across multiple OP Chains, and absence of a user-friendly wallet for managing assets and dApps across multiple OP Chains.
  • Proposed Solution (Sketch): Develop tools and frameworks on top of the core Superchain protocols to enhance the developer and user experience. Suggested tools include content-addressable smart contracts, cross-chain contract state management standards, and a Superchain RPC endpoint.

Law of Chains

The Law of Chains, introduced by the Optimism Collective on July 26th, 2023, represents a significant stride towards realizing a unified Superchain that leverages the modular and forkable OP Stack. This framework is designed to ensure that each chain within the Superchain upholds shared standards of openness, neutrality, and user protection, mitigating the risks associated with the proliferation and fragmentation of independent blockchains.

The Law of Chains is not just a set of rules but a neutrality framework guiding the collective governance of multiple blockchain networks under the Superchain umbrella. It emphasizes a communal approach to solving problems, where enhancements benefit all members and users experience a consistent and secure environment across different chains.

Key Principles and Stakeholder Protections

• Stakeholders: The framework categorizes stakeholders into Users, Chain Governors, and Chain Servicers, each with specific rights and responsibilities.
• User Protections: Emphasizes uniform protections across chains, mirroring the security and operational standards of Ethereum to ensure a safe and predictable user experience.
• Governor and Servicer Rights: Maintains economic and operational autonomy for Chain Governors and Servicers, allowing them to innovate while adhering to the collective standards.

The governance model transitions from overseeing a single chain to setting standards across multiple chains, promoting a scalable and decentralized ecosystem. The Law of Chains serves as a guiding document to be socially enforced by Optimism Governance, ensuring that all participating chains meet the established criteria.

Section-by-Section Overview of the Law of Chains

• Introduction: Establishes the Law of Chains as an open neutrality framework for promoting core principles such as user protection, decentralization, and economic autonomy.
• Covered Participants: Defines the three groups of ecosystem participants covered by the Law—Users, Chain Governors, and Chain Servicers.
• The Platform: Discusses the application of the Law to the OP Stack platform itself, emphasizing its role as a public good.
• User Protections: Focuses on ensuring uniform protections for all users across the Superchain, comparable to those on Ethereum.
• Chain Governor Protections: Details the rights of Chain Governors to make economic decisions and configure technical settings within set parameters.
• Chain Servicer Protections: Outlines the expectations and rights of Chain Servicers, particularly concerning economic participation and response to governance changes.
• Platform as Commons: Treats the entire OP Stack platform as a communal resource that must be preserved for the benefit of the collective.
• Users First: Prioritizes user protections over other considerations, ensuring their needs are foremost.
• Enforcement: Specifies that the Law of Chains will be enforced through resolutions passed by Optimism Governance.
• Interpretation: Provides guiding principles for interpreting the Law, focusing on minimizing governance overhead and ensuring long-term relevance.

The initial version of the Law of Chains is open for community feedback, with the goal of refining and officially integrating it into the governance process in upcoming seasons. This approach ensures that the framework evolves in response to community insights and technological advancements.

RetroPGF

Public goods refer to resources or initiatives that benefit the entire community and are not driven by direct profit motives. Optimism recognizes the importance of funding public goods to ensure the sustainability and healthy growth of the ecosystem, ensuring the availability of essential tools, infrastructure and resources.

The Retroactive Public Goods Funding (RetroPGF) initiative within the Optimism Collective is an experiment in non-plutocratic governance and the retrospective allocation of funding for public goods. 

RetroPGF is built on the concept that it is often easier to agree on what was useful in the past than to predict future utility. It involves experiments where members of the Citizens’ House allocate surplus protocol revenue or portions of the RetroPGF token allocation to projects that have demonstrated a positive impact on the Optimism Collective. This aligns with Optimism’s core principle of “impact = profit,” where positive impact should be rewarded with profit.

• RetroPGF provides strong incentives for individuals to create public goods that benefit the Optimism Collective.
• This initiative fosters an ecosystem that is more developer-friendly, informative, and interconnected, thereby driving application usage and increasing demand for blockspace.
• By funding public goods sustainably, the Collective can nurture a robust ecosystem and a more prosperous economy.

Funding for RetroPGF can originate from two key sources:

• RetroPGF Token Allocation: This consists of 20% of the initial OP (Optimism’s native token) supply designated for RetroPGF.
• Allocation of Surplus Protocol Revenue: Additional funding may come from the surplus revenue generated by the Optimism protocol.

RetroPGF is a long-term endeavor aimed at building the future envisioned by Optimism supporters. Regular rounds of RetroPGF will continue, each with its unique characteristics. This process is dynamic and relies on community participation to evolve and improve. 

In the early rounds of RetroPGF, the Optimism Foundation collaborated with the community to decide on scope and voting mechanics. However, as the initiative progresses, the Citizens’ House will have more autonomy in shaping these aspects, with checks and balances from the Token House.

The ultimate goal is to expand RetroPGF’s scope to support the creation of public goods beyond the immediate Optimism ecosystem by continuously refining the tools and processes through regular experimentation.

Identity

Decentralized identity is essential for creating a democratic, secure, and accessible web. It allows individuals to control their personal information, seamlessly manage their identity across different platforms, and enhance privacy without compromising on functionality.

Within the Optimism Collective, decentralized identity is crucial for enabling equitable participation in governance. It underpins a two-house system where both token holders and community members vote in a one-person-one-vote manner, reflecting true community consensus and contributions.

Beyond governance, decentralized identity opens new opportunities for economic empowerment and innovation. It enables secure financial interactions and broader access to global services, allowing users to prove personal attributes securely and privately.

The Collective highlights the use of attestations as key components of decentralized identity. These verifiable claims allow users to demonstrate qualifications or traits without revealing unnecessary personal details, supporting privacy-respecting applications. 

Developers are encouraged to explore decentralized identity applications that leverage attestations, enhancing user autonomy and privacy within the Optimism ecosystem.

Attestions

Attestations are crucial building blocks in decentralized identity systems, serving as verified statements made by a recognized entity about an individual, entity, or object. They play a fundamental role in establishing a trust framework within digital platforms.

The Ethereum Attestation Service (EAS) is a suite of smart contracts designed for the creation, verification, and revocation of both on-chain and off-chain attestations. This service acts like a decentralized database, enhancing the reliability of digital attestations across any OP Chain within the Superchain network.

Benefits of Using Ethereum Attestation Service

• Permissionless: EAS operates through a public contract system, making it accessible to anyone without centralized control, thus facilitating an open verification process.
• Robust Tooling: Developers can benefit from advanced tooling for indexing and access management, which are integral to the AttestationStation.

Privacy is a paramount concern when dealing with attestations, as they can generate immutable records on the blockchain. Here are some privacy best practices:

• Consent: Always secure explicit consent from users when collecting personal information, clarifying the purpose, usage, and storage of the data.
• Sensitive Data Handling: Avoid on-chain storage of sensitive data. Instead, use hashes of such data for future verifications.
• Security: Ensure off-chain data is stored securely using encryption and robust access controls.

The Optimist Profile

The Optimist Profile is a tool designed to enable contributors to publicly share and verify the impact of their contributions to the Optimism Collective. This profile not only facilitates the creation of a detailed on-chain identity but also enhances the web of trust within the community by allowing peer-to-peer attestations regarding contributions.

Features of the Optimist Profile

• Profile Schema: Each profile is anchored by a unique on-chain self-attestation that outlines the individual’s or organization’s identity.
• Contributions: Contributors can make attestations about their own contributions as well as validate the contributions of others, fostering a robust contribution verification system.

Built on the Ethereum Attestation Service, the Optimist Profile utilizes a structured approach to store and retrieve identity and contribution data:

• Profile Schema UID: 0xac4c92fc5c7babed88f78a917cdbcdc1c496a8f4ab2d5b2ec29402736b2cf929
  • Name: Identifies the profile holder.
  • Metadata Pointer: Directs to a URI, IPFS hash, or similar blob storage that holds detailed metadata about the profile.
• RetroPGF 3 Application Schema UID: 0x76e98cce95f3ba992c2ee25cef25f756495147608a3da3aa2e5ca43109fe77cc
  • Display Name: Name of the application.
  • Application Metadata Pointer: Points to blob storage that contains further details about the application.

Why The Project Was Created

Optimism was born out of a mission to scale Ethereum while preserving its core values and making it accessible to people around the world. The creators of Optimism saw the state of Ethereum, burdened by high fees, and recognized that these fees limited its accessibility, particularly for everyday users. Their vision was to bring the promise of Ethereum to a global audience, a vision hindered by transaction fees that could reach up to $100 per swap.

At the technical level, Optimism was developed to address Ethereum’s scalability challenges by introducing a Layer 2 solution that enables faster and more cost-effective transactions while maintaining the security of Ethereum’s architecture. The mission was clear: make Ethereum affordable again by realizing the concept of Layer 2 scaling. 

The Ether Phoenix

But not only was Optimism started with the hope of scaling Ethereum, but also the values that characterize the Ethereum community and ecosystem. The creators of Optimism understood that the essence of humanity lies in its capacity to organize and collaborate. As a result, they sought to address this issue through Ether’s Phoenix, a concept that envisions a world where individuals are rewarded in proportion to their positive impact. In this vision, contributing to public goods, like distributing free software, results in proportional financial rewards—a concept known as the “fairness ratio,” where impact equals profit.

Calculating impact can be challenging, as many public goods are intangible, slow to manifest, and difficult to measure using traditional market mechanisms. To tackle this, Optimism proposed a “retroactive” approach to public goods funding. This way, periodical pauses assess past contributions, rewarding individuals for their role in creating a better world.

Ether’s Phoenix represents not only an algorithm but also a mindset—one that believes in the power of cooperation and optimism. It rewards early cooperators who laid the groundwork for funding public goods. It embodies the idea that building systems to support public goods is a public good in itself.

At the start, Optimism’s contribution to this vision was to allocate 100% of centralized sequencer profits to Ethereum protocol development. While it may not solve all the world’s problems, it represents a step in the right direction, a step toward a more harmonious future where cooperation and optimism prevail, and the community is rewarded for its efforts on building a healthy ecosystem.

Retroactive Public Goods Funding – RPGF

Retroactive Public Goods Funding (RPGF) is an initiative that aims to realize the vision of achieving sustainable funding for the Optimism ecosystem. From Vitalik Buterin words: 

“It is easier to agree on what was useful than what will be useful. The former is still often a source of disagreement, but it’s a type of disagreement where you could still get reasonably good top-level judgements by using some existing voting mechanism (eg. quadratic voting or even regular voting). The latter is much more challenging. For the profit-making sector, the best that we can do is to build out an ecosystem where people can create startups and invest in them, and get rewarded if they end up correct. So rather than reinventing the wheel entirely, we will create a public-goods-oriented version of the exact same mechanism.”

Building ambitious projects without a clear business model is undeniably challenging. Securing funding, attracting top talent, and overcoming the myriad obstacles that come with creating something exceptional become uphill battles. 

Startups, despite their high failure rates, possess a significant advantage—the possibility of an exit. These exits create incentives for investment, hiring, motivation, and equity alignment, as individuals can share in the gains from the project’s success. However, this advantage is largely absent in the realm of nonprofits, open-source software (FOSS), and public goods projects.

In the absence of exit opportunities, even the most talented and well-intentioned builders often veer toward for-profit ventures, potentially compromising their original missions. It’s not solely about amassing wealth; it’s about fairness. Why dedicate oneself to building free software when others reap massive profits from it without any financial upside for the creator?

By drawing inspiration from Vitalik’s ideas, Optimism came up with a mechanism that introduced exits for public goods projects based on the amount of public goods they generate, rather than quarterly profit margins. The goal behind this was to increase the investment capacity and foster more innovation in those technologies that maximize community benefit

The proposal combines protocol-generated revenue, retroactive public goods funding, and a Results Oracle to establish a funding cycle for public good projects akin to the startup model. As a result, the Optimism team has committed to allocating all profits generated from sequencing (before decentralizing the sequencer) to public goods funding experiments, including the potential for the first public goods exit. Moving forward, this commitment underscored the foundational ideas of the inaugural experiment.

The Results Oracle

The Results Oracle is a pivotal component in the concept of retroactive public goods funding (RPGF), and its importance lies in its ability to fund public good projects based on their demonstrated value and impact. Unlike traditional funding mechanisms that rely on projecting the potential future benefits of a project, RPGF recognizes that it’s often easier to evaluate what has already been achieved.

• Agreement on Past Value: Determining the value of past contributions is generally less contentious than predicting future utility. While disagreements may still arise, they can often be addressed using existing voting mechanisms like quadratic voting or conventional voting. This approach provides a more reliable way to assess the historical impact of public good projects.
• Alignment with Profit-Making Mechanisms: The Results Oracle draws inspiration from profit-making sectors where individuals can create startups, invest in them, and receive rewards if they prove to be correct. In essence, it adapts a similar mechanism for public goods projects. Rather than reinventing the wheel, it leverages a familiar and successful model.
• Retroactive Funding: The Results Oracle, unlike other public goods funding DAOs, funds projects retroactively. It recognizes and rewards projects that have already provided tangible value to the community. This retroactive approach encourages builders and contributors by providing concrete incentives for past work.
• Iterative Design: Crafting the perfect design for the Results Oracle is a complex challenge, and naive approaches like coin voting (one person one vote) have known issues. To address this, the design is approached iteratively. Early versions may involve a small group of technically skilled, long-time contributors from the ecosystem, with improvements made over time as the understanding of decentralized governance advances.
• Reward Distribution: The Results Oracle has the capability to send rewards to various types of addresses, including:
  • Individual or organizational addresses primarily responsible for the project.
  • Smart contracts representing fixed allocation tables, distributing funds among contributors.
  • Project tokens, representing contributions and tradeable on open markets.
• Project Tokens: The concept of project tokens introduces a novel idea. These tokens serve as a prediction market for what the Results Oracle will fund. The oracle sets a price floor for the tokens, allowing it to allocate rewards to projects multiple times. This approach enables projects to receive rewards from multiple sources, enhancing their sustainability.

• Disagreements and Judgement: In cases where multiple allocation tables or project tokens for the same project emerge due to disagreements over contributions, the Results Oracle must make judgments. It decides not only which project is valuable but also which token or allocation table (or the distribution split among multiple tokens/tables) best represents the contributions. While this judgment is necessary, it is expected to be exceptional rather than routine.

In essence, this mechanism envisions a future where public goods projects receive financial rewards based on their positive impact, creating an ecosystem where builders of public goods can see tangible returns for their contributions. Overall, this approach seeks to align incentives, attract top talent, and enable the sustained growth of projects that benefit society as a whole.

A Pragmatic Approach to Decentralization

Decentralization is a core principle of the blockchain and cryptocurrency space. However, when it comes to layer 2 (L2) solutions, achieving full decentralization is challenging, primarily due to the reliance on upgrade keys. 

Understanding the Decentralization Challenges in L2s

Every major L2 project relies on upgrade keys for their L1 contracts, which grant a trusted party the power to execute protocol upgrades. While this enables projects to make improvements and fix bugs, it also centralizes control over the L2 balances. If these keys were compromised, it would put all deposited assets at risk.

Having upgrade keys means that even with fault or validity proofs in place, the security can be overridden by upgrades. This raises questions about the effectiveness of security mechanisms if a central authority can alter them at will.

Nevertheless, the main reason for having upgrade keys is the inherent difficulty of writing bug-free, complex code. In the crypto space, where a single vulnerability can have catastrophic consequences, caution is paramount. This complexity poses a high bar for achieving true decentralization.

Decentralizing Optimism with a Multi-Client Architecture

Ethereum provides a valuable case study in achieving decentralized security. Despite experiencing multiple critical bugs and vulnerabilities, Ethereum has remained highly available throughout its existence. This resilience is attributed to Ethereum’s strategic approach to security.

To emulate Ethereum’s success, Optimism is pursuing a pragmatic path to decentralization. This will be implemented following the steps listed below:

• Multi-Client Ecosystem: Ethereum’s strategy revolves around creating a multi-client ecosystem with multiple distinct implementations that can interoperate. The key idea is that bugs are usually uncorrelated between implementations. If one client has a specific bug, another may not suffer from the same issue. This redundancy ensures high availability.

• Decentralizing Optimism: Optimism is designing its architecture to align with Ethereum’s philosophy. It aims to integrate with multiple clients, making it possible to mix and match both the proofs and the clients. This approach maximizes redundancy and reduces reliance on a single central authority.

• Adding ZK Rollups: While Optimism is not immediately adopting zero-knowledge proof technology, it remains open to the possibility in the future. If ZK technology becomes powerful enough to support EVM equivalence, it can be added as another client in the multi-client ecosystem, providing an additional layer of security.

Roadmap

The Path to Technical Decentralization

Optimism, guided by OP Labs, is committed to decentralizing its technical framework known as the OP Stack. This commitment aligns with Optimism’s broader mission to facilitate global coordination through decentralized blockchain technology. The focus is on transforming the OP Stack into an open, modular, and forkable infrastructure that not only scales Ethereum but also maintains its ethos of openness and neutrality.

The journey towards decentralization is central to Optimism’s philosophy of empowering global coordination via blockchain technology. Over the past few years, significant efforts by OP Labs have focused on preparing the OP Stack for this transition. Since the deployment of Bedrock, Optimism has made significant strides toward achieving its goal of technical decentralization. 

The path to decentralization is complex, filled with technical challenges that require meticulous, bug-free coding to avoid vulnerabilities. OP Labs has adopted a pragmatic and cautious approach to decentralization, emphasizing the importance of intentional steps towards activating on-chain fault proofs, crucial for securing the Layer 2 infrastructure.

With Bedrock’s infrastructure in place, the focus has shifted towards:

• Activating Fault Proofs: Ensuring that all transitions within the network can be independently verified, increasing security and trust across the platform.
• Decentralizing Network Governance: Progressing beyond central control to a more community-focused governance model. This includes decentralizing the roles of sequencers and proposers to mitigate risks associated with central points of failure.
• Upgrades and Delays: Ensuring that all upgrades have a minimum delay of 30 days to provide ample time for review and community feedback.

Optimism is aiming to reach several key milestones in the near future:

• Full Implementation of Fault Proofs: This critical step will bolster network integrity by allowing for comprehensive verification of state transitions.
• Community Governance Expansion: Efforts are underway to enhance participation in network governance, ensuring that decision-making reflects the diverse perspectives within the Optimism community.
• Sequencer Decentralization: Continuing to distribute the responsibility of transaction sequencing among multiple parties to enhance network resilience and security.

Community collaboration remains a cornerstone of Optimism’s strategy. The ongoing decentralization process benefits significantly from community feedback, which helps refine and optimize the development of the network. OP Labs encourages all stakeholders to participate in discussions and contribute to the governance processes.

Next-Generation Fault Proofs

The introduction of the Fault Proof System by OP Labs marked a significant step in advancing the technical decentralization of the Optimism ecosystem. This system is designed to enhance security and reliability within the Superchain by validating transaction integrity through a series of checks and balances.

The Fault Proof system is comprised of several components each playing a critical role in maintaining the integrity of transactions within the Superchain:

• Fault Proof Program (FPP): The FPP acts as a deterministic program that checks for discrepancies or faults by accessing data from L1. This is essential for ensuring the accuracy of the data across the network.
• Fault Proof Virtual Machine (FPVM): Also known as “Cannon,” this component executes the programs of the FPP. It simulates a MIPS machine running the L2 Ethereum Virtual Machine (EVM), which allows for precise control and verification of the operations.
• Dispute Game: This component is used to resolve disagreements over the outputs produced by the FPVM, ensuring that only valid outputs are finalized. The initial version utilizes a Bisection game to isolate and address disputes effectively.

The alpha version of the Fault Proof System has been implemented on the OP Goerli Testnet, where it is undergoing extensive testing. This phase is crucial for detecting any issues and ensuring the robustness of the system before it is deployed more broadly.

The Fault Proof System has a modular design that supports Optimism’s decentralization goals by enabling community contributions to its development. This approach allows for greater diversity in the development of the system and enhances the overall resilience of the network.

• Modularity: The separation of the FPP and FPVM allows for independent development and customization of each component, facilitating specific optimizations and innovations.
• Community Engagement: Developers are invited to participate in the testing and development of the Fault Proof System. This involvement is key to refining the system and ensuring its success.

OP Labs plans to expand the capabilities of the Fault Proof System by integrating additional proof mechanisms such as zero-knowledge proofs (ZKPs), which could enhance privacy and scalability. The system will also explore different types of dispute resolution games to accommodate various network scenarios.

Decentralizing the Sequencer

Optimism is undertaking a progressive approach to decentralize the critical function of sequencing transactions on its network. Historically, the Optimism Foundation has been responsible for operating the sole sequencer on the Mainnet, ensuring consistency and reliability in transaction processing. However, centralizing such an important role is at odds with the ethos of blockchain and decentralization. As such, Optimism is laying out a phased plan to open up the sequencer role to allow for more participants and thereby reduce central points of control.

A major step towards this decentralization is the introduction of an economic mechanism aimed at creating a competitive marketplace for sequencing. This move is expected to democratize the opportunity to sequence transactions by allowing multiple entities to participate and benefit from the role. The competition in sequencing is designed to encourage efficiency and innovation, while also redirecting excess sequencer profits towards the development of the protocol itself.

Alongside the economic mechanisms, a governance framework will be established to safeguard against any potential for sequencers to prioritize short-term profits at the expense of the network’s long-term health. This governance mechanism will play a crucial role in ensuring that the sequencing market operates fairly and in the best interest of the entire Optimism ecosystem.

The ultimate goal is to support a system where multiple concurrent sequencers are operational, akin to the diverse and robust networks of Layer 1 protocols like Polygon and Cosmos. By adopting a standard BFT consensus protocol, Optimism aspires to foster an environment where sequencers work in tandem to secure the network, offering more resilience and furthering decentralization.

The exact mechanics for sequencer rotation and the implementation details of the economic and governance mechanisms are still in the works. The gradual shift from a single sequencer to a decentralized model is an acknowledgment of the complexities involved in maintaining network integrity while moving towards an open, permissionless system.

Sector Outlook

How the Superchain solves the issues of traditional multichain architectures

Conventional multi-chain approaches suffer from two main problems:

• Compounded Security Risk: Each new chain introduces a distinct security model, leading to increased systemic risk as more chains are introduced.
• Costly Chain Deployment: Launching new chains demands new validator sets and block producers, resulting in substantial deployment costs.

The Superchain concept leverages Layer 2 (L2) chains within a multi-chain ecosystem. These chains, termed OP Chains, share security, a communication layer, and a technology stack. Unlike traditional multi-chain designs, OP Chains are standardized, allowing them to function as interchangeable resources. Developers can create cross-chain applications while abstracting underlying chain intricacies.

Some of the key properties include:

• Shared L1 Blockchain: A common Layer 1 (L1) blockchain facilitates transaction ordering across all OP Chains.
• Shared Bridge: A unified bridge for OP Chains ensures standardized security properties.
• Cost-Efficient Deployment: OP Chains can be deployed and transacted on without the high L1 fees.
• Configuration Flexibility: OP Chains have configurable options, including data availability providers and sequencer addresses.
• Secure Transactions and Cross-Chain Messages: Safely migrating assets between OP Chains is supported for users.

Once Optimism fulfills these key properties, it can be considered a Superchain. This transformation would involve a network of OP Chains functioning as interchangeable, standardized resources. Developers would target the Superchain as a cohesive unit, abstracting complexities related to individual chains.

The Law of Chains

The Law of Chains is an open framework built on the core principles of decentralization. Base, built by Coinbase, became the first chain adhering to the concept. As part of these partnerships, similar to Base, it is reasonable to expect that more chains agree to share part of their revenue and profits with the broader Optimism Collective. In exchange, those chains could earn $OP tokens.

Infrastructure For Public Goods Funding

Optimism envisions creating a protocol that addresses a significant challenge in blockchain ecosystems and communities: the allocation of funding for projects. Traditionally, decision-making on project funding has been controlled by private investors and opaque platforms. This centralized approach has long-term implications for who benefits from the technology created.

Optimism’s ambition is to establish a protocol that facilitates transparent and community-accountable funding allocation. It aims to make plural funding mechanisms more accessible and accountable to the community. The open-source nature of this protocol is expected to enable experimentation with various funding mechanisms, with multiple funding rounds running concurrently for different ecosystems.

To achieve this vision, Optimism is working on a grants protocol based on the concept of Quadratic Funding (QF). QF matches funds based on the number of contributors rather than the total amount funded, empowering grassroots supporters. Projects with more grassroots support receive more funds, reducing the influence of whales and power brokers.

Optimism’s grants protocol seeks to support retroactive public goods funding (RetroPGF), which rewards projects based on past usefulness rather than untested future solutions. The goal is to establish a sustainable funding cycle for public goods, similar to how for-profit startups receive funding. This is achieved through a Results Oracle, which determines which projects receive funding based on recognized value. RetroPGF 2, for instance, relies on Optimism’s Citizens’ House for decision-making.

Optimism’s grants protocol is designed to be flexible, allowing communities to customize their funding priorities and decision-making processes. It supports a range of voting mechanisms, from pluralistic to centralized, depending on the community’s preferences. While the protocol does not guarantee pluralism, it offers transparency and blockchain-based auditability, making it a transparent alternative to centralized platforms.

Potential Adoption

In response to the widespread adoption of the OP stack, other ecosystems have also launched their rollup or development toolkits to capture market share among developers and projects, such as Polygon’s CDK (Chain Development Kit). Other examples include Arbitrum’s Orbit and zkSync’s Hyperchain, which enable the development of L3s that settle on top of the native L2. The merit to this design is that value accrual is clear, since L3s are paying a settlement fee to the chain.The OP Stack, however, offers a different design where superchains settle directly on Ethereum. As a result, The OP stack embraces interoperability across L2s, whereas other designs are more restricted to the underlying L2.

For Users

Sending transactions on OP Mainnet is similar to Ethereum. Users should provide a gas price equal to or greater than the current L2 gas price. This is the combination of a L2 execution fee and a L1 data fee

For Developers

Differences Between Ethereum and OP Mainnet

	Ethereum	OP Mainnet
Opcode Differences	COINBASE: undefined	COINBASE: undefined
	DIFFICULTY: Random value	DIFFICULTY: Sequencer-set randomness
	NUMBER: L1 block number	NUMBER: L2 block number
	TIMESTAMP: L1 block timestamp	TIMESTAMP: Timestamp of the L2 block
	ORIGIN: tx.origin behavior varies	ORIGIN: tx.origin behavior varies
	CALLER: msg.sender behavior varies	CALLER: msg.sender behavior varies
	PUSH0: Not supported yet (future addition)	PUSH0: Not supported yet (future addition)
Accessing L1 Information	Use L1Block contract for L1 info	Use L1Block contract for L1 info
Transaction Costs	Transaction costs include gas fees	Transaction costs include L2 execution fee and L1 data fee
	EIP-1559 elasticity multiplier: 2	EIP-1559 elasticity multiplier: 6
	EIP-1559 denominator: 8	EIP denominator: 50
	Maximum base fee increase (per block): 12.5%	Maximum base fee increase (per block): 10%
	Maximum base fee decrease (per block): 12.5%	Maximum base fee decrease (per block): 2%
Transaction Pool (mempool)	Public mempool	Private mempool (may change in the future)
	MEV exists	MEV minimized – Bedrock’s mempool is private
Blocks	Block time: 12 seconds	Block time: 2 seconds
	Block target size: 15,000,000 gas	Block target size: 5,000,000 gas
	Block maximum size: 30,000,000 gas	Block maximum size: 30,000,000 gas
	Ethereum JSON-RPC API	JSON-RPC API similar to Ethereum but with additional custom methods.

Currently blocks are produced every two seconds. However, that value may change in the future.

Interacting with OP Mainnet Contracts

OP Mainnet is composed, in part, of a series of smart contracts on both the Ethereum L1 and the OP Mainnet L2. You may want to interact with these contracts for a number of reasons such as:

• Sending messages between L1 and L2.
• Sending tokens between L1 and L2.
• Querying information about the current L1 data fee.

Running a Local Development Environment

A local development environment for OP Mainnet is a way to set up the entire OP Mainnet system on your local machine. This environment includes both L1 and L2 development nodes, allowing you to test your code and contracts before deploying them to testnet or mainnet. Alternatively, you can get a hosted development node from any of these providers.

You might need if you fall into any of the following use cases:

• Interactions Between L1 and L2: If your application involves contracts on both OP Mainnet and Ethereum that need to interact with each other, the local development environment is useful for testing these interactions. It provides a faster testing experience compared to the communication delay between L1 and L2 on the actual OP Mainnet.
• Handling Differences: While OP Mainnet is EVM equivalent (similar to Ethereum), there can be subtle differences. If your application might be affected by these differences, using the local development environment helps ensure everything runs as expected. This prevents unexpected issues when moving to the testnet. Review the differences carefully to determine if your application falls into this category.

The Optimism monorepo includes a devnode setup that you can use and you can find additional instructions in the developer docs.

If your project doesn’t involve complex interactions between L1 and L2 or isn’t sensitive to the differences between Ethereum and OP Mainnet, you may not need to set up a local development environment. You can rely on existing testing tools like Foundry or Hardhat.

Running an OP Mainnet or Testnet Node

If you’re planning to build an application on OP Mainnet, you’ll need access to an OP Mainnet node. You have two choices: use a hosted node from a provider or run your own.

Some providers offer free hosted nodes to get started quickly.

If you are running your own node, it is recommended to:

• Stay updated by subscribing to an update feed (mailing list or RSS) to know when to upgrade.
• Your node should be on a relatively powerful machine with at least 16 GB RAM and a 500 GB SSD drive for OP Mainnet.
• Nodes sync from both other OP Mainnet nodes and Ethereum (L1) if necessary. To sync only from L1, edit the op-node configuration.
• The recommended method is to use Docker and provided Docker images for op-geth and op-node. These images undergo extensive testing
• If you prefer a non-Docker setup, follow these instructions. While they work, keep in mind that Docker configurations are more thoroughly tested.

Testing applications for OP Mainnet

Testing decentralized applications for OP Mainnet is similar to testing on Ethereum, but there are some considerations to keep in mind, especially when dealing with OP Mainnet-specific features.

Unit tests and single-layer integration tests:

• Most tests don’t require OP Mainnet-specific features.
• Run tests that don’t rely on OP Mainnet-specific features in your development stack.
• Ethereum development stacks often provide testing features that are not supported by standard Ethereum clients like geth or op-geth, making testing more efficient.

Multilayer Integration tests:

• Some dApps may need OP Mainnet-specific features not available in development stacks.
• For dApps relying on inter-domain communication or other OP Mainnet-specific features, consider running automated tests on a local development environment.
• While slower, this approach helps identify discrepancies between OP Mainnet, Ethereum, and development stacks.

Integration with other products: 

• Many decentralized applications depend on services provided by other contracts or protocols.
• Use mainnet forking for integration testing if your dApp relies on external contracts or services.
• Alternatively, connect to the OP test network if the required contracts or services are deployed there.

Transaction Fees on Software Development

OP Mainnet is designed with EVM-equivalency in mind, allowing it to reuse much of the same code that Ethereum mainnet developers will be familiar with. One key deviation from this is the matter of transaction fees. Transaction fees on all L2s must differentiate themselves from Ethereum. Here are the specifications as it pertains to Optimism.

OP mainnet transactions consist of both an Execution Gas Fee, as well as an L1 Data Fee. 

Execution Gas Fee:

The Execution Gas Fee on OP Mainnet is determined in the same way as on Ethereum: it is the product of the amount of gas used by a transaction and the gas price set by the sender. This fee adheres to the EIP-1559 model, which Ethereum also uses to set base transaction fees, ensuring predictable costs. The fee is calculated using:

• Base Fee: This is the minimum price per unit of gas for inclusion in a block, adjusted dynamically based on network congestion.
• Priority Fee: An optional additional fee that users can pay to give their transactions higher priority for faster processing.

Because OP Mainnet operates under the same technical specifications for calculating gas usage as Ethereum, transactions that consume a certain amount of gas on Ethereum will use an identical amount on OP Mainnet. The primary difference lies in the gas price, which is typically lower on OP Mainnet, leading to more cost-effective transactions.

L1 Data Fee:

The L1 Data Fee is exclusive to OP Mainnet and covers the costs associated with anchoring data to Ethereum for increased security and data availability. This fee compensates for the Ethereum network’s base fee required to post transaction data and is influenced by Ethereum’s current gas market conditions.

Following the Ecotone upgrade (pending approval), OP Mainnet may utilize an alternative method for posting transactions using blobs, which would adjust the L1 Data Fee based on the blob data gas price on Ethereum. This adjustment aims to optimize costs further as the network scales and adapts to varying congestion and data throughput needs.

The formula for the L1 Data Fee adjusts over time and is set to align closely with real-time Ethereum network conditions, ensuring that transactions on OP Mainnet remain secure and economically efficient. The fee is automatically calculated at the time of transaction submission, ensuring transparency and predictability for users.

The anticipated Ecotone upgrade will potentially revise the way transaction costs are calculated, introducing efficiencies in how data is processed and fees are assessed on OP Mainnet. 

As OP Mainnet continues to evolve, users and developers can expect ongoing adjustments to the fee structure, aiming to balance cost-effectiveness with rapid transaction processing and robust security measures inherent to Layer 2 solutions.

Making OP Mainnet dApps Even Cheaper

OP Mainnet offers significantly lower costs compared to L1 Ethereum, but with optimization, dApps on OP Mainnet can become even more cost-efficient.

Transaction fees on OP Mainnet consist of two components: L2 execution fees and L1 data fees.

• L2 execution fees are based on the gas used for transaction processing.
• L1 data fees are determined by the gas cost of writing transaction data to L1 and the cost of L1 gas, which can be volatile.

In OP Mainnet, L1 data fees usually dominate the transaction cost, making optimization tradeoffs different from Ethereum. Writing transaction call data to L1 is expensive, with a cost of approximately 16 gas per byte.

However, on-chain processing and storage are cost-effective. It’s cheaper to write data to storage than to include it in transaction call data.

The standard ABI, designed for L1 tradeoffs, may not be efficient for OP Mainnet. Consider creating a shorter ABI with only the required bytes and decode data on-chain. View and pure functions can still use the standard ABI at no additional cost

Another recommendation is that you review your contracts and identify values that will never exceed 32 bytes. It is also recommended to utilize smaller data types like uint88 instead of uint256 when possible. For example, when storing ETH balances, uint88 may be sufficient given the limited supply of Ether.

Bridging

Bridging is the process of transferring data and assets between OP Mainnet and Ethereum, as they are fundamentally connected but operate as separate blockchain systems. 

• Sending Tokens:
  • The Standard Token Bridge is a key tool for moving tokens between OP Mainnet and Ethereum.
  • It’s a simple smart contract designed for transferring tokens seamlessly between the two networks.
  • The Standard Token Bridge also allows you to create L2 representations of existing tokens on Ethereum.
• Sending Data:
  • In cases where the Standard Token Bridge doesn’t cover your specific needs, you can send arbitrary data between L1 and L2.
  • This functionality enables contracts on Ethereum to trigger functions on OP Mainnet and vice versa.
  • Developers have access to a straightforward API for initiating cross-chain function calls, simplifying the process.

The Standard Token Bridge

The Standard Token Bridge simplifies the process of transferring assets, including ETH and ERC20 tokens, between Layer 1 (L1) Ethereum and Layer 2 (L2) OP Mainnet. 

Deposits

• Depositing ERC20 tokens: 
  • Use the depositERC20 or depositERC20To functions on the L1StandardBridge contract.
  • You must approve the Standard Token Bridge to access the amount of tokens you want to deposit; failure to do so will result in the deposit failing.
  • Ensure that the ERC-20 token you’re depositing conforms to the standard bridge requirements. The bridge doesn’t support tokens with fees on transfers or tokens that modify balances without emitting a Transfer event.
  • Verify if a token can be used with the standard bridge by checking the token list, which includes the chainId and the associated bridge address.
  • You can also confirm a token’s compatibility by calling its l2Bridge method, which should return 0x4200…0010.
• Depositing $ETH:
  • Utilize the depositETH or depositETHTo functions on the L1StandardBridge.
  • Alternatively, send $ETH directly to the L1StandardBridge. Once detected and finalized on OP Mainnet, your L2 account will be funded with the corresponding $ETH amount.

Withdrawals

• Withdrawing ERC20 tokens:
  • Trigger ERC20 withdrawals through the withdraw or withdrawTo functions on the L2StandardBridge.
• Withdrawing $ETH:
  • Unlike L1, there’s no separate function for withdrawing ETH on L2. Instead, use the withdraw or withdrawTo functions on the L2StandardBridge, specifying the address 0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000 as the L2 token address.

Adding an ERC20 Token to the Standard Bridge

For token developers looking to bridge ERC20 tokens between Ethereum Layer-1 (L1) and Optimism Layer-2 (L2), it is crucial that the L2 version of the token implements the IL2StandardERC20 interface. This interface ensures the token can perform essential functions such as deposits, transfers, and withdrawals on L2.

Considerations Before Bridging:

The Standard Bridge does not support ERC20 tokens that impose fees on transfers or modify balances without emitting a Transfer event.

Deployment Process Overview:

1. Preparation: Developers must prepare the environment by setting up necessary tools and defining parameters such as the L1 token address and network API keys.
2. Deploying on L2: Utilize the OptimismMintableERC20Factory for deploying the L2 token. This factory simplifies the creation of a token that is compatible with the Optimism network.
3. Token Transfers Between L1 and L2:
   • Deposits: Tokens are deposited by interacting with the L1StandardBridge. This requires users to approve the bridge to access their tokens.
   • Withdrawals: Withdrawals are handled through the L2StandardBridge, using the withdraw function which mirrors the deposit process in reverse.
4. Integration with Cross-Domain Messenger: This tool is essential for managing and executing cross-layer communications, which are pivotal for transactions like deposits and withdrawals between L1 and L2.

General Advice for Developers:

• Ensure the token contract on L2 strictly follows the required standards to avoid common pitfalls, such as non-standard token behaviors that could interfere with bridge functionalities.
• Continuously monitor and update the deployment parameters and bridge interactions based on the Optimism network updates and community feedback.

AddingThe Superchain Token List

The Standard Bridge allows a one-to-many mapping between L1 and L2 tokens, meaning there can be multiple OP Mainnet implementations of an L1 token. However, the Superchain Token List maintains a one-to-one mapping between L1 and L2 tokens and serves as the source of truth for the OP Mainnet bridge UI.

To have your token added to the Superchain Token List, create a pull request against the Superchain Token List repository, providing addresses for both L1 and L2 tokens, along with a token logo.

Sending Data Between L1 and L2

To facilitate communication between Layer 1 (L1) Ethereum and Layer 2 (L2) OP Mainnet, you can use a process called “bridging.” This allows contracts on OP Mainnet to trigger contract functions on Ethereum and vice versa.

• Bridging contracts on OP Mainnet and Ethereum can interact with each other using a special function called sendMessage. This function is part of the messenger contracts, namely, L1CrossDomainMessenger for L1 and L2CrossDomainMessenger for L2.
• The sendMessage function is similar to the call function used for contract communication within Ethereum, with an additional gasLimit parameter.
• It enables contracts on one layer to send messages to contracts on the other layer.

The messenger contracts (L1CrossDomainMessenger and L2CrossDomainMessenger) are pre-deployed on both L1 and L2 networks, and their addresses can be found in the Optimism monorepo. These contracts abstract away lower-level communication details and simplify cross-layer messaging.

The speed of cross-layer transactions depends on the direction of the transaction:

• For transactions from Ethereum (L1) to OP Mainnet (L2), it takes approximately a minute for the transaction to move from L1 to L2. L2 nodes wait for five block confirmations on Ethereum to reduce the risk of chain reorganizations.
• For transactions from OP Mainnet (L2) to Ethereum (L1), it involves multiple steps:
  • Waiting for the state root to be written to L1.
  • Providing a Merkle proof of the message on L1.
  • Waiting for the fault challenge period, which is seven days on the mainnet, before finalizing the transaction.

Contracts often use msg.sender to make decisions based on the calling account, such as implementing the Ownable pattern. When receiving messages between layers, msg.sender will be the messenger contract corresponding to the layer you’re on. To determine the actual sender, you can use the xDomainMessageSender function provided by the messenger contracts.

The cost of sending data between L1 and L2 involves gas fees and varies depending on the direction of the transaction.

• For L1 to L2 transactions, the cost primarily comes from sending a transaction on Ethereum, which is determined by Ethereum’s gas prices. Additionally, gas is consumed on L2 for contract execution.
• For L2 to L1 transactions, the cost includes the L2 transaction initiation fee and two L1 transactions (proof and finalization). The L1 transactions are typically more expensive than the L2 initiation.

Messages sent from L2 to L1 cannot be relayed for at least one week due to a challenge period. During this challenge period, anyone can attempt to prove that a transaction result is incorrect by re-executing it on Ethereum. If an incorrect result is proven, it can be replaced with the correct one, with financial penalties for the incorrect result’s publisher. Decisions based on L2 transaction results should be made only after the challenge period has passed to ensure validity. The challenge period on the mainnet is set to seven days, but it may change in the future to balance security and usability.

Known Issues

• Transactions Stuck in the Transaction Pool:
  • OP Chain uses EIP-1559 with different parameters than L1 Ethereum, and the L2 base fee can grow by up to 77% within a short time.
  • If a transaction specifies a maximum fee per gas lower than the block base fee, it may get stuck until the base fee drops below the transaction’s value.
  • The recommendation is to set the maximum fee per gas for transactions to a relatively high value, such as 0.1 gwei, to prevent transactions from getting stuck. This does not increase the transaction cost as the base fee is charged based on a formula. To save on L2 gas costs, minimize the max priority fee.
  • Wallet developers can implement these recommendations for default priority fee and max fee settings.
  • Dapp developers can override wallet defaults and suggest values based on the current base fee.
  • Users can modify transaction fields to set appropriate fees.
• Known Non-Issues – Deposit Transactions:
  • Deposit transactions on L2 do not have a chainId. These transactions are part of the block derivation process and come from a dummy address without a signature.
  • Since the chainID is typically encoded in the signature in Ethereum, deposit transactions lack a recoverable chainID.
  • This is not a problem because deposit transactions originate from the block derivation process, and there is no need to recover the chainID for them.

Networks, Public RPC Endpoints and APIs

Transaction Debugging Tools: 

• Tenderly provides detailed transaction inspection for OP Mainnet and OP Goerli.
  • You can inspect the state of verified contracts at any step of a transaction’s execution. It allows you to step into or over function calls and provides a high level of detail on transaction execution.
  • Tenderly’s dashboard can reduce development time and enhance your understanding of transaction execution flow. It offers the ability to inspect transaction states at every instance and provides transaction tracing capabilities.
• Etherscan supports OP Mainnet and OP Goerli and allows you to view events and revert messages for mined transactions.
  • You can access additional L2 features offered by Etherscan on their Explorers page.
  • Etherscan provides valuable information about transactions, including events and revert messages, for both OP Mainnet and OP Goerli.
• Blockscout is compatible with both OP Mainnet and OP Goerli and allows you to view and read events on these networks.

Economics

The Optimism Collective operates on the principle that a thriving ecosystem is built on healthy public goods. This ecosystem is designed to benefit three key groups:

• Tokenholders:
  • Value accrues to tokenholders through the productive reinvestment of sequencer revenue.
  • Sequencer revenue is primarily allocated to support public goods, fostering the growth of the ecosystem and increasing demand for blockspace.
• Contributors and Builders:
  • Contributors and builders directly benefit from retroactive public goods funding and the markets it enables.
  • A symbiotic relationship exists where builders thrive in an ecosystem with well-funded tools, educational resources, applications, and infrastructure.
• Users and Community Members:
  • Users and community members benefit from ongoing airdrops of the OP token.
  • Project incentives made possible by OP ecosystem funding also contribute to their benefit.
  • Public goods play a crucial role in enhancing the overall experience and value proposition for users and community members.

Business Model

The revenue model of Optimism (OP) is built around the concept of demand for OP blockspace, which generates sustainable funding for the ecosystem.

• Source of Revenue:
  • Funding for the OP economy primarily comes from the ownership of OP Mainnet and the value of its blockspace.
  • Currently, funding is sourced directly from the centralized sequencer and is channeled to The Optimism Foundation for redistribution.
  • In the future, revenue can be generated by selling the right to participate in Optimism’s decentralized sequencing network.
• Sustainable Revenue:
  • The sustainable source of revenue that drives OP’s economic model is the right to blockspace.
  • This revenue source grows with the network itself, making it a dynamic and scalable funding mechanism.
• Distribution to Public Goods:
  • Optimism recognizes the importance of public goods and their role in building strong communities.
  • Revenue generated is distributed back to the ecosystem, primarily through Retroactive Public Goods Funding (RetroPGF).
  • RetroPGF is designed to incentivize individuals, teams, projects, or communities to contribute to the public good of the Optimism Collective.
• Community Decision-Making:
  • The Citizens’ House plays a vital role in the distribution of funds. It conducts quarterly votes to decide how funds are allocated.
  • This democratic process directly rewards community members for their positive contributions to the ecosystem.
• Benefits for Builders:
  • RetroPGF also provides potential exit liquidity for public goods projects, creating a market for early investment.
  • Builders can be compensated for their contributions without relying solely on direct revenue.
  • They can raise capital based on the early potential and promise of their projects.
• Long-Term Goals:
  • The Optimism Foundation expects this funding mechanism to drive a wide range of pro-social downstream effects.
  • The Collective can capture and expand upon these effects through frequent experimentation and iteration.
• Value Creation and Demand:
  • Funding public goods stimulates growth and network revenues from the ground up.
  • By investing in valuable developer tools and core infrastructure, the ecosystem becomes more accessible and attractive for builders.
  • This, in turn, drives application usage and generates more demand for blockspace.
• Governance and Experimentation:
  • Optimism’s governance structure supports experimentation around the allocation of public goods funding.
  • The Foundation uses a two-house system and involves Citizens with local knowledge and vested interests in governing RetroPGF.

Fee Breakdown

Transaction fees on OP Mainnet are similar in concept to fees on Ethereum but have some unique aspects due to being on Layer 2. 

L2 Execution Fee

Transactions on OP Mainnet, like Ethereum, require users to pay for the computation and storage they use. This is known as the execution fee.

The execution fee is calculated by multiplying the gas used in a transaction by the gas price attached to that transaction.

The gas price consists of two components: the base fee and the priority fee.

• The base fee is charged for each unit of gas used and is determined by the previous block’s base fee and block congestion
• The priority fee is the amount paid by the user and should be kept as low as possible.

L1 Data Fee

Unlike Ethereum, all transactions on OP Mainnet are also published to Ethereum for security reasons. As a result, users need to pay for submitting their transactions to Ethereum, known as the L1 data fee. This fee is influenced by the current gas price on Ethereum, the gas cost of publishing the transaction, a fixed overhead cost, and a dynamic overhead cost.

Tokenomics

$OP is the governance token of Optimism’s network, distributed through airdrops, allowing community participation in decision-making. The $OP token enables community governance, allowing stakeholders to participate in protocol decisions. $OP was designed to govern upgrades to the protocol, network parameters, and incentives within the ecosystem.

Token Distribution

Category	Allocation	Explanation
Ecosystem Fund	25%	This proactive initiative is designed to catalyze growth within the Collective by extending financial support to projects and active communities.
Retroactive Public Goods Funding (RetroPGF)	20%	As the mainstay of the Optimism Collective, RetroPGF ensures that those contributing valuable public goods are fairly compensated for their societal impact.
User airdrops	19%	Planned airdrops aim to acknowledge and incentivize users who engage in constructive community actions, starting with Airdrop #1.
Core contributors	19%	Recognition for the dedication and work of the individuals who laid the groundwork for the Optimism Collective.
Investors	17%	Early supporters and investors who provided capital and resources crucial to the Collective’s inception and growth.

• Ecosystem Fund (25%): Allocated to stimulate development within the Optimism Collective by funding projects and communities that contribute to ecosystem growth.
• Retroactive Public Goods Funding (RetroPGF) (20%): Designed as Optimism’s primary vehicle for compensating contributors of public goods, ensuring they are rewarded for their impactful contributions.
• User Airdrops (19%): Aimed at rewarding users for constructive behaviors that support community growth, beginning with the first of several planned airdrops.
• Core Contributors (19%): Dedicated to acknowledging the efforts of those who have been instrumental in establishing the Optimism Collective.
• Investors (17%): Funds allocated to the early financial backers who supported the development and growth of the Collective.

The distribution approach involves multiple airdrops instead of a one-time event, reflecting a strategic effort to engage and reward community members over time. Optimism’s total token supply is capped at 232232 (4,294,967,296) $OP tokens, with a planned inflation rate post-distribution to manage ecosystem incentives effectively.

Optimism had a unique approach to distribution, opting for a season of airdrops rather than a single airdrop. 

Token Supply Inflation

$OP will unlock over the course of 4 years following the supply schedule shown in the image below:

Optimism Airdrop #1

The initial Optimism airdrop occurred on June 1, 2022, and targeted 248,699 addresses distributing 5% of the $OP token supply. It aimed to reward early users and Ethereum community members who demonstrated positive-sum behavior. 

Optimism Airdrop #2

On Feb 10, 2023, a surprise airdrop delivered 11.7 million $OP tokens to over 300,000 addresses of users who positively contributed to the network’s governance.

Optimism Airdrop #3

On September 18, 2023, Optimism distributed 19,411,313 $OP tokens to 31,870 addresses. This airdrop rewarded users who delegated their tokens to active voters in governance from January 20 to July 20, 2023, emphasizing the importance of participatory decision-making.

Optimism Airdrop #4

Executed on February 20, 2024, this airdrop delivered 10,343,757.81 $OP tokens to 22,998 unique addresses. Celebrating contributions across the Superchain, this airdrop acknowledged the creators and innovators enhancing the Optimism and broader crypto ecosystems.

Future Airdrops (#5, 6, …)

Optimism reserves 14% of the initial $OP token supply for future airdrops, aiming to continue rewarding community members who positively impact the ecosystem. These future distributions are designed to sustain engagement and contribution across the network, reinforcing the “impact equals profit” ethos.

Governance

Optimism is governed by a collaboration between the Optimism Foundation and the members of the Optimism Collective. The Foundation would initially steward the Ecosystem Fund and coordinate retroactive public goods and airdrop distributions.

The Optimism Collective

On April 26th, 2022, the Optimism Collective was unveiled as a response to the growing need for scalability in the crypto space without compromising on the core values of decentralization and community. 

The Optimism Collective was introduced as a groundbreaking experiment in digital democratic governance. Its core mission was to facilitate the rapid and sustainable growth of decentralized ecosystems. This mission was to be realized through the stewardship of the newly formed Optimism Foundation.

The governance structure of the Optimism Collective was outlined, comprising two houses: the Token House and the Citizens’ House.

• The Token House was established through Airdrop $1 and consisted of token holders who engaged in positive-sum, community-oriented behavior. Token holders had the power to vote on protocol upgrades, project incentives, and more, using the $OP token.
• The Citizen’s House was designed to oversee the distribution of retroactive public goods funding generated from the network’s revenue. Citizenship was conferred through “soulbound” non-transferrable NFTs, ensuring a non-plutocratic mechanism for governance.

The two houses were expected to work together, directing revenue generated from OP Mainnet to support public goods and the growth of the collective. This symbiotic relationship was envisioned as a powerful flywheel, where funding public goods would enhance the value of Optimism blockspace, leading to more revenue for public goods and continuous growth.

As the Citizen and Token Houses mature via iterative governance experiments, responsibilities from the Optimism Foundation would be shifted to the greater Optimistic ecosystem.

The Token House

The Token House governance within the Optimism Collective operates under a structured framework outlined in the Governance Toolkit, which includes the following:

• Token House Governance Contract: This is the on-chain voting contract where all Token House qualifying governance proposals are submitted for voting.
• Optimism Governance Portal: This is a user-friendly interface allowing Token House members to delegate their OP tokens and vote on-chain.
• The Optimism Forum: This platform serves as a hub for discussions and deliberations about governance proposals.
• Discord: Used for informal governance discussions and feedback.

Token House governance decisions are made through governance proposals. These proposals follow a structured process, such that all Token House proposals go through a 5-week cycle structured as follows:

• Weeks 1-3 – Feedback and Review: Proposals other than grants should be posted on the Forum for review by the Optimism community. Proposal authors are expected to be responsive to delegate feedback. These proposals should follow specific formatting and information guidelines.
• Week 4-5 – Voting: In the fourth and fifth weeks, all delegates, including self-delegated $OP token holders, are invited to vote on proposals via the Optimism Governance Portal. Non-grant proposals are included in on-chain voting only if they meet specific criteria, including approval from delegates with >0.25% voting power.

To be approved, a Token House governance proposal must meet these minimum vote thresholds:

• Quorum: This is the minimum number of total $OP votes, including abstain votes, required for a proposal to proceed. Quorum is measured as a percentage of the total votable $OP supply.
• Approval Threshold: The minimum number of $OP votes required in favor of approving a proposal, measured as a percentage of votes cast to approve relative to the total number of yes/no votes.

The exact requirements for quorum and approval threshold may vary depending on the Proposal Type. Valid Proposal Types can be fall into one of the following categories:

• Governance Fund: Proposals related to $OP grants for incentivizing future growth within the Optimism ecosystem.
• Protocol Upgrade: Proposals for scheduled changes to the on-chain smart contracts of the mainnet Optimism protocol.
• Inflation Adjustment: Proposals for changes to the inflation rate of newly minted $OP tokens.
• Director Removal: Proposals for the removal of a director of the Optimism Foundation.
• Treasury Appropriations: Proposals for determining the amount of $OP the Optimism Foundation may spend or distribute annually.
• Rights Protections: Proposals related to changes in the founding documents of the Optimism Foundation, requiring consent from $OP holders.
• Code of Conduct Violation: Proposals related to violations of the Code of Conduct.
• Grant Clawback: Proposals for clawing back locked grants that fail to meet critical milestones.

Each proposal type has specific submission requirements, vote duration, quorum, and approval threshold criteria.

The Citizen’s House

Citizens’ House governance within the Optimism Collective operates through a structured process known as RetroPGF (Retroactive Public Goods Funding) rounds. These rounds involve voting and disbursements to reward public goods projects that have made substantial impacts.

Each RetroPGF round begins with the definition of the overall amount of rewards to be allocated and the scope of impact. This sets the boundaries for the round. Next, projects that have contributed to public goods are notified and invited to create a profile in the RetroPGF Application Manager. 

During the voting phase, citizens who hold “soulbound” non-transferrable NFTs, conferring citizenship, participate in the voting process. They cast their votes to determine which projects should receive retroactive rewards based on their impact. After the voting period concludes, the overall reward amount for the round is divided among the winning projects. The allocation is based on the simple weighted average of the Citizens’ House vote.

Note that, in order to ensure legal compliance,  the Optimism Foundation collects necessary information from the winning projects, including Know Your Customer (KYC) details. This step is essential for distributing the grants in accordance with relevant regulations.

It is also worth noting that the Foundation holds administrative power during the rounds. The Optimism Foundation moderates governance proposals to ensure their validity and suitability for voting.Handling of conflicting proposals submitted simultaneously or closely together is managed by the Foundation as well.

Token House Governance

The governance of the Optimism Collective is underpinned by key documents which evolve over time:

• The Working Constitution: This document outlines the provisions and principles governing the Collective and is designed to be in effect for a maximum of four years from its adoption. It sets the stage for a Bedrock Constitution that will integrate learnings from earlier governance experiments.
• The Collective’s Operating Manual: Detailing current governance processes for the Token House, this manual is subject to evolution alongside the growth of the Collective. The official and most updated version is maintained in The Optimism Foundation’s GitHub repository.

The Token House operates on a seasonal basis, segmented by Reflection Periods. During these Reflection Periods, Special Voting Cycles may occur to consider proposals derived from the period’s reflections. Regular voting within each Season occurs in three-week cycles, beginning and concluding at specified times on Thursdays and Wednesdays, respectively.

Reflection Periods allow The Optimism Foundation to propose changes to the Operating Manual and to table governance proposals to refine the Collective’s structure based on the previous season’s feedback.

The Token House Governance has undergone a series of evolutionary phases designed to empower and incentivize growth within the Optimism ecosystem. Each phase has been marked by specific goals and methods of fund distribution. The Token House is entering its fifth season (January 4th – May 8th, 2024), continuing its governance activities as scheduled.

Historical Context and Phases:

• Phase 0: Launched to reward projects that have contributed to the growth of Optimism, with allocations determined by on-chain metrics as of April 1, 2022.
• Phase 1: Focused on distributing grants to active projects in the Optimism ecosystem, with subsequent funding rounds permitting projects to apply based on the success of their initial allocations.
• Phase 2: Aimed at aligning grants with Mission Requests, encouraging projects to seek funding that resonates with the overarching goals of Optimism.

Within the framework of the Token House governance, the Governance Fund is set up to distribute 5.4% of the total initial token supply, which amounts to 231,928,234 $OP tokens. This fund is dedicated to fostering the development and expansion of projects and communities within the Optimism ecosystem. The intention behind the Governance Fund is to proactively offer incentives that catalyze future growth and support the thriving ecosystem surrounding Optimism.

The distribution from the Governance Fund is carefully tracked and is aimed at ensuring that projects contributing positively to the Optimism environment are rewarded and empowered. The distribution process is designed to be transparent and aligned with the collective goals of the Optimism community.

Citizen House Governance

The Citizen House is an experiment in non-plutocratic governance within the Optimism Collective, tasked with allocating Retroactive Public Goods Funding (Retro Funding). The House’s remit is expected to grow, but currently, it focuses on managing and voting on Retro Funding, under guidance from the Optimism Foundation.

The Citizen House’s current responsibility is managing the allocation of funds for Retro Funding. This stewardship involves defining the scope of each funding round and supervising the voting process. It’s worth noting that possessing a temporary voting badge does not ensure ongoing participation in the Citizen House, as the criteria for involvement will likely evolve with each iteration of Retro Funding.

Funds for Retro Funding are sourced from two main channels:

• A dedicated token allocation, which is 20% of the initial supply of $OP tokens.
• Any surplus revenue generated by the protocol.

As the Citizen House matures, it will broaden its governance functions beyond Retro Funding, including collaborating with the Token House on the surplus revenue allocation and refining the criteria for citizenship within the House.

Retro Funding Mechanics

At the core of Retro Funding lies the principle that it’s simpler to reach consensus on past contributions than to predict future utility. The process involves Citizens’ House members directing funds from surplus revenue or a specific token allocation to projects they identify as impactful to the collective. This mechanism is pivotal to the philosophy of impact equaling profit, incentivizing the creation of public goods that propel the ecosystem forward.

Retro Funding is not just about rewarding past achievements; it opens a gateway for early investment in public goods projects, enabling builders to secure capital and gain recognition for their early-stage ideas and contributions.

Retro Funding is approached as a series of trials, each designed to refine the processes of defining, evaluating, and funding impact. These experiments are not one-off events but a continual cycle of learning and adapting, with several rounds having already taken place:

• Round 1 in late 2021: $1 million allocated across 58 projects.
• Round 2 in Q1 2023: 10 million $OP tokens distributed across 195 projects.
• Round 3 in Q4 2023: 30 million $OP tokens distributed across 501 projects.
• Round 4 anticipated for Q2/Q3 2024.

The framework for Retro Funding encapsulates three aspects ripe for exploration:

1. Impact Scoping: Determining what types of initiatives the Collective should fund.
2. Impact Scoring: Establishing a system to assess the effect of projects.
3. Impact Settlement: Refining the voting mechanism to ensure equitable and accurate fund allocation.

As the process evolves, the Citizen House will increasingly influence the direction and methodology of Retro Funding, shaping a sustainable model for funding public goods.

Citizenship

The Citizens’ House within the Optimism Collective operates on the principle of identity-based governance, which is distinct from the more common token-voting governance found in the Token House. In the Citizens’ House, the focus is on representing individual human stakeholders of the Collective, including builders, users, and community members who share the project’s values and have a long-term interest in the Collective’s success.

The Citizenship Selection Process consists of the following stages:

• Bootstrapping with Temporary Badges: In the initial stage of establishing the Citizens’ House, participants are issued temporary badges that grant them the ability to vote in RetroPGF rounds. These badges are distributed as part of the bootstrapping process.
• Collaborative Criteria Development: In future stages, both the Token House and Citizens’ House will work together to formulate ongoing criteria for selecting individuals to become Citizens. This collaborative approach means that the criteria for Citizenship will evolve over time, reflecting the dynamic nature of the Optimism ecosystem.
• Changing Membership: Holding a voting badge in the current stage does not guarantee voting rights in future RetroPGF rounds. Membership in the Citizens’ House will be determined by governance decisions and may change over time.

When it comes to the identity layer, Optimism has an impartial and permissionless attestation contract known as the AttestationStation. The Optimism Governance, which encompasses both the Token House and Citizens’ House, has authority over a function that interacts with the AttestationStation. This function uses any data included in the AttestationStation to determine the set of Citizens for the Citizens’ House.

The system is designed to be flexible and future-proof. Instead of defining strict citizenship criteria from the outset, the Optimism Collective embraces the principle of iterative governance. This approach allows the Collective to adapt and refine its criteria for selecting Citizens based on changing circumstances and needs.

Becoming a Citizen

In the current phase of Citizens’ House governance, the number of voting badges is increasing with each round of RetroPGF. For instance, RetroPGF round 1 had 24 badgeholders participating, round 2 saw 71 badgeholders participating, and round 3 will extend voting badges to 208 community members.

The long-term vision is to widely distribute Citizenship to a diverse group of individuals across the Optimism ecosystem, encompassing various subcultures and industries.

Optimism governance retains the authority to set criteria for Citizenship, implying that eligibility to vote may be subject to rules and restrictions that are currently unknown. Therefore, participating in RetroPGF 3 does not guarantee permanent inclusion in the Citizens’ House for future iterations of RetroPGF.

How To Be a Delegate

Becoming a delegate within the Optimism Collective involves understanding and engaging with the governance structure of the ecosystem. Delegates play a crucial role in shaping the future of Optimism by actively participating in governance through proposal submissions and voting. 

For those interested in becoming a delegate, the process involves several key steps:

• Educate Yourself: Thoroughly understand the responsibilities and expectations of a delegate, which are detailed in the Working Constitution and other governance documents.
• Registration: Register as a delegate on the Optimism Governance Portal. This portal serves as the central hub for delegates to manage their participation in governance activities.
• Engagement: Actively participate in the governance process by submitting proposals, voting on various governance issues, and engaging with the community to discuss and deliberate on important topics.
• Self-Delegation: Consider self-delegating your $OP tokens to enhance your influence and participation in the voting process. This step is optional but can signify a strong commitment to the Collective’s governance.

The Working Constitution of the Optimism Collective

The Working Constitution of the Optimism Collective serves as the foundational document that outlines key principles and provisions for the governance of the Collective.

• A “Working” Constitution: Recognizes the dynamic nature of the Optimism Collective experiment.
  • Commits to continuous experimentation in governance over a limited time frame.
  • Specifies that the Working Constitution will remain effective for no more than four years, after which a permanent “Bedrock Constitution” will be established based on lessons learned from prior governance experiments.
• Equal Coexistence of OP Citizens and OP Holders: Emphasizes the need to balance short-term incentives with the Collective’s long-term vision.
  • Introduces a bicameral governance system to prevent misaligned incentives or excessive concentration of power between OP Holders and OP Citizens.
• Role of the Optimism Foundation: The Optimism Foundation, based in the Cayman Islands, acts as a steward of the Optimism Collective’s growth and development.
  • The Foundation’s Board of Directors facilitates Collective governance, allocates treasury assets for public goods funding and ecosystem incentives, amends the Working Constitution, and takes actions to align with the Collective’s mission.
  • The Foundation aims to gradually decentralize its role over time.
• Rights of OP Citizens and OP Holders:
  • OP Citizens have the authority to allocate Retroactive Public Goods Funding and exercise additional rights as granted over time.
  • OP Holders can remove a director of the Optimism Foundation and veto changes to the Foundation’s founding documents that would materially reduce OP Holder rights.
• Interpretation Guiding Principles:
  • Governance Minimization: Strives for minimal governance to reduce overhead and promote permissionless innovation.
  • Forking: Recognizes the right to fork and exit as essential to protect individual freedoms, encouraging members to fork the system if governance is captured.
  • Anti-Plutocracy: Advocates for governance influence beyond financial stake, emphasizing the importance of Citizenship.
  • Impact=Profit: Highlights the Collective’s primary function as minimizing the gap between collective impact and individual profit, aiming to reward positive impact fairly and consistently.

Submitting Proposals

As a delegate, actively submitting proposals is a key responsibility. Understanding the types of proposals you can submit and the process for each is crucial for effective participation:

• Governance Fund Grant Proposals: Apply for funding from the Governance Fund by submitting an application to a Mission Request. These proposals are evaluated by the Optimism Grants Council or the Foundation, depending on the nature of the request.
• Non-Grant Proposal Types: You can also submit other types of proposals that do not require grant funding. Although there is no minimum holding requirement to submit a proposal, all non-grant proposals must be approved by at least four delegates with sufficient voting power to advance to the voting stage.

Both types of proposals and their specific processes are detailed in the Operating Manual, which serves as the source of truth for all governance-related processes.

Operating Manual for the Optimism Collective

The Operating Manual is a document that outlines the governance proposal process within the Optimism Collective. It is designed to evolve along with the Collective and is maintained on the Ethereum-Optimism GitHub. The manual provides detailed guidelines for both the Token House and the Citizens’ House, which are the two main bodies responsible for governance within the Collective.

Governance Structure

• Token House: Composed of $OP holders, this house is responsible for submitting, deliberating, and voting on various types of governance proposals. $OP holders can vote directly or delegate their voting power to another eligible party. These delegates play a significant role in the governance process by influencing decision-making.
• Citizens’ House: Focuses on allocating rewards to providers of public goods through Retroactive Public Goods Funding (RetroPGF). Citizenship, often linked to specific contributions or activities like participation in RetroPGF Round 3, is currently considered temporary.

Both houses are expected to operate under strict adherence to the Optimism Collective’s Rules of Engagement and Code of Conduct, ensuring a responsible exercise of authority.

Governance Toolkit

The toolkit available to the Token House includes:

• Token House Governance Contract: The primary on-chain voting contract for governance proposals.
• Optimism Governance Portal: Allows members to delegate and vote their $OP on-chain.
• Citizens’ House Snapshot Space: Enables Citizens’ House members to veto proposals from the Token House.
• Optimism Forum and Discord: Platforms for discussion, feedback, and deliberation about governance proposals.
• GitHub and Charmverse: Additional resources for managing grants and engaging with the community-led Optimism Grants Council.

Proposal Process

The proposal process is structured to facilitate clear and organized governance actions:

• Submission and Drafting: Proposals can be submitted by any community member and must be drafted according to the guidelines provided in the Operating Manual. Initial drafts are posted on the Governance Forum for community feedback.
• Approval and Voting: Proposals require explicit approval from four top delegates in the Token House or four citizens in the Citizens’ House to proceed to voting. The detailed voting process, including quorum and threshold requirements, is outlined in the manual to ensure transparency and fairness.
• Implementation: Successful proposals are implemented with the oversight of the Optimism Foundation, which ensures that all actions are secure, compliant, and aligned with the Collective’s objectives.

Administrative and Implementation Details

The Optimism Foundation plays a crucial role in administering the governance process. This includes moderating proposals, managing voting procedures, and handling the logistical aspects of proposal implementation. The Foundation aims to gradually decentralize its role, reflecting the evolving nature of the Collective’s governance model.

The Operating Manual is subject to updates and amendments, which are documented and released in versions coinciding with governance experiments or “Seasons”. These updates are intended to refine the governance process and adapt to the Collective’s growing needs.

Code of Conduct

Delegates must adhere to the Code of Conduct outlined by the Optimism Collective. This code establishes the behavioral standards expected within all community spaces and when representing the community, both online and offline.

Scope and Application

The Code of Conduct applies to all delegates, Citizens, and grant recipients, collectively referred to as “Optimists”. It governs behavior within forums such as Discord, Reddit, and any official community interactions to ensure a respectful and inclusive environment.

Key Principles

• Inclusivity and Civility: Optimists are expected to uphold the highest standards of inclusivity and civility. Discrimination, harassment, and other severe violations lead to immediate suspensions for one month, reinforcing the community’s commitment to a safe and welcoming environment.
• Transparency and Accountability: Delegates must avoid conflicts of interest and openly disclose any potential conflicts. Voting on one’s own proposals or any form of self-dealing is strictly prohibited to maintain fairness and integrity within the governance process.
• Reporting and Enforcement: Violations of the Code of Conduct should be reported through specified channels, ensuring proper review and action. The Code of Conduct Council reviews all submissions confidentially, and enforcement actions are taken based on the severity of the violation.

Expectations and Responsibilities

• Active Engagement: Optimists should actively discourage misconduct and report serious or repeated offenses according to the outlined procedures. This proactive approach helps maintain the ethical standards of the community.
• Adherence to Governance Standards: All activities, especially those related to governance, should align with the Code of Conduct to foster an environment of trust and mutual respect among all members.
• Consequences of Violations: The consequences for violating the Code of Conduct can range from temporary suspensions to permanent loss of delegate or Citizen status, depending on the severity and frequency of the infractions.

The Optimism Foundation

The Optimism Foundation is a Cayman Islands foundation company that plays a vital role in supporting the Optimism Collective, the development of the Optimism ecosystem, and the underlying technology.

The Foundation serves as a formal legal entity, allowing it to engage in legally binding agreements with third parties. This capability enables the Foundation to enter contracts with service providers, administer intellectual property rights, and fulfill necessary governmental reporting and filings. This legal status enhances the Foundation’s ability to act quickly, predictably, and securely, ultimately benefiting the early developmental stages of the Collective.

The Foundation is also responsible for stewarding the early evolution of collective self-governance. It monitors and moderates governance proposal processes, implements approved governance proposals, and helps develop frameworks like the Working Constitution and the Operating Manual to facilitate participation. Additionally, the Foundation supports the Optimism protocol as an open-source project, encouraging technical development and research in areas such as scalability, security, and decentralization.

As time goes by, the Foundation’s ultimate goal is to coordinate contributors in creating the technical and governance foundations necessary for the gradual decentralization of its role over time. As the ecosystem matures, the Foundation aims to step back, allowing the broader governance community to take on more responsibilities.

While the Working Constitution of the Collective is limited to a four-year period, the Foundation intends to gradually transition responsibilities to the broader governance community well before this milestone. Its role will evolve to align with the Collective’s commitment to sustained decentralization.

The Foundation Structure and Accountability

The Optimism Foundation operates under a governance structure that includes a Board of Directors and a Supervisor. The Board manages the business and affairs of the Foundation. The Supervisor, DS Limited, oversees the Foundation’s directors and ensures compliance with legal obligations.

Community Governance Through Experimentation

The Optimism Collective is building community governance through experimentation. This refers to an iterative process of time-bound governance experiments known as “Seasons”. Seasons allow the Collective to test new strategies in order to incrementally improve the engagement of the community, incorporating reflection and feedback as fundamental stages of the process. 

The results of this research are compiled into governance roadmaps and a searchable library known as “The Collective DAO Archives.” This resource provides insights into DAO governance timelines and a comprehensive collection of DAO policies, programs, and processes.

The design of Season 4 is influenced by ongoing research into the development and processes of DAOs. Key concepts include adopting multiple decision-making models, creating prioritization frameworks, and ensuring flexible funding structures. 

Key elements of Season 4 include:

• “Collective Intents,” which are flexible goals guiding the Collective’s efforts, and “Missions and Alliances” to fund initiatives aligned with these Intents.

• “Collective Trust Tiers“, which introduce accountability by setting funding limits based on contribution, reputation, and impact. Trust Tiers also incorporate attestations to accumulate on-chain reputation.
• Missions  are the specific initiatives proposed to achieve the goals known as “Collective Intents”. There are two types of missions:
  • Proposed Missions: These are submitted under a specific Collective Intent. They enable the Governance Fund to support a broader range of initiatives aligned with those Intents.
  • Foundation Missions: Defined by the Foundation, these missions are similar to public Requests for Proposals (RFPs) for the Partner Fund and also work towards fulfilling Collective Intents.
    

• Alliances represent groups of contributors who collaborate on a Mission from start to finish.These Alliances can consist of pre-established organizations or a group of individual contributors who come together specifically to accomplish a Mission’s goals.

By forming Alliances, contributors can work together efficiently and effectively to achieve the intended outcomes of Missions.

Risks

Decentralization introduces complexities in managing updates and vulnerabilities. Proper risk management involves having strategies in place to address these complexities while ensuring the security of the network. Failure to manage this complexity can lead to security breaches and reputation damage.

• Decentralization Begets Complexity:
  • Complex Release Coordination: As Optimism grows and decentralizes, the release process becomes more complex. Coordinating with numerous infrastructure providers, bridges, and multiple mainnet forks introduces challenges in deploying updates and security patches. Each additional participant adds a layer of complexity to the process.
  • Security Vulnerability Risk: Security releases require careful handling. If a vulnerability is discovered, immediate public disclosure and patching might not be feasible, as there’s a risk of malicious actors reverse-engineering the vulnerability before users can upgrade. 
  • To address these challenges, Optimism implemented an adaptive disclosure protocol. They initially share a private patch with key stakeholders to quickly mitigate the issue. Once they are confident that the patch is widely deployed, they publicly release the fix. However, they acknowledge that as the ecosystem grows, this approach may become impractical.
• Every line of code counts:
  • Backwards Compatibility Modifications: For instance, a but in Optimism’s Geth fork arose from modifications made to the go-ethereum codebase to maintain backwards compatibility with Optimism’s old system (OVM 1.0). 
  • Simplicity as a Design Philosophy: Optimism’s design philosophy emphasizes simplicity. For risk management, it’s essential to minimize code differences from established and tested codebases, prioritize simplicity, and diligently review and test code changes. 
• The importance of Bug Bounty Programs: Optimism recognizes the value of whitehat security researchers in identifying and reporting vulnerabilities. They actively maintain a bug bounty program to incentivize ethical hackers to help identify and fix issues. Without such programs, critical vulnerabilities may go unnoticed and unaddressed, increasing the project’s risk profile.

Security

OP Mainnet’s Security Model

OP Mainnet is an ongoing project with a strong focus on enhancing security for its users. It’s essential to understand that, currently, the security of OP Mainnet relies on a multisig wallet managed by anonymous individuals. This multisig wallet plays a crucial role in upgrading core OP Mainnet smart contracts without experiencing upgrade delays.

Note that like any complex system, the Optimism codebase may contain undiscovered bugs that could potentially lead to the loss of assets within the system. While the smart contract codebase has undergone multiple audits, audits do not guarantee bug-free code. Using OP Mainnet inherently involves a level of risk associated with potential bugs within the Optimism codebase, and users should be aware of this risk and exercise caution.

Currently, OP mainnet does not have fault proofs. The security of the system relies on the multisig wallet and the ability to upgrade within a 7-day challenge window. The multisig wallet is managed by a group of anonymous individuals, and anonymity is maintained to enhance the security of the multisig.

Optimism has outlined a detailed Pragmatic Path to Decentralization, which provides insights into how the multisig may be gradually removed to achieve true fault-proof security on OP Mainnet.

OP Mainnet offers one of the largest bug bounties, with potential rewards of up to $2,000,042 for finding critical bugs in the Optimism codebase. Additionally, you can contribute to network security by running your own verifier node to detect network faults.

Audits

The Optimism OP Stack has been assessed through a series of security audits to ensure robustness and reliability. Here is a chronological summary of the key security audits conducted:

1. Trail of Bits – October to November 2020: Focused on the Optimism Virtual Machine (OVM) and related rollup contracts, Trail of Bits conducted a comprehensive review to ensure the system’s security integrity.
2. Dapphub – November 2020: Their examination of ECDSA Wallet Contracts provided insights into potential vulnerabilities and led to improvements in the security practices within Optimism’s infrastructure.
3. OpenZeppelin – March 2021: Provided a security review of the OVM and rollup contracts, further strengthening the trust in the Optimism protocol’s secure operation.
4. ConsenSys Diligence – March 2021: A differential fuzzing on the OVM_SafetyChecker smart contract was carried out, offering an external perspective on the robustness of Optimism’s code.
5. OpenZeppelin – May 2022: A subsequent audit, focusing on Bedrock contracts, reassured stakeholders of ongoing diligence in maintaining high-security standards.
6. Trail of Bits – May 2022: Evaluated the OpNode service, delving into the intricacies of the system to recommend improvements for better security measures.
7. Sigma Prime – August 2022: Their Golang Signer security review provided another layer of assurance regarding the security measures in place within Optimism’s environment.
8. OpenZeppelin – September 2022: This audit of the Bedrock and Periphery ensured the newest features and updates continued to adhere to stringent security protocols.
9. Spearbit – October 2022: A security review by Spearbit provided an independent verification of the safety and security of Optimism’s protocols and procedures.
10. Trail of Bits – November 2022: Invariant Testing to examine the security of Optimism’s codebase and assess its resilience against potential threats.
11. Trail of Bits – January 2023: Focused on system configuration and withdrawal updates, providing insights into potential improvements and reaffirming the security stance of Optimism’s operations.
12. Trust Security – January 2024: An audit for the Bedrock upgrade showcased proactive steps taken by Optimism to address vulnerabilities, with special attention to storage slot safety, reentrancy protection, and gas-related flaws.
13. Cantina – February 2024: Reviewed the MCP L1 contract, providing recommendations to ensure the seamless operation and security integrity of Optimism’s platform.

Past Security Incidents

Fixing a Critical Bug in Optimism’s Geth Fork

In February 2022, the Optimism team was alerted by Jay Freeman about the existence of a critical bug in Optimism’s Geth fork. 

Bug Details

The bug in question enabled an attacker to mint $ETH on the Optimism network by repeatedly triggering the SELFDESTRUCT opcode on a contract that held an $ETH balance.

Technical Specification

Jay Freeman’s detailed explanation of the bug in Optimism’s OVM 2.0 provides valuable insights into the technical aspects of the issue. 

• OVM 1.0 and Solidity Compatibility:
  • In OVM 1.0, the use of the OVM_ETH ERC20 token presented an issue with compatibility at the level of Solidity source code.
  • Contracts compiled for the Ethereum Virtual Machine (EVM) couldn’t run on OVM 1.0 without modification.
• Gas Token and Native Ether Support:
  • One major issue with late 2020 Optimism was the absence of native support for a “gas token.”
  • On Optimism’s Layer 2 (L2), Ether was represented as an ERC20 token (OVM_ETH).
  • Some EVM opcodes like BALANCE and SELFBALANCE did not work as expected, returning 0.
• EVM Equivalence Upgrade (OVM 2.0):
  • OVM 2.0 aimed to address compatibility issues with existing smart contracts and developer tooling.
  • This upgrade was essential for projects like Orchid that required code deployable on multiple networks.
• Issues with OVM 2.0 Implementation:
  • Jay Freeman discovered that OVM 2.0 still stored user account balances in the storage state of an ERC20 contract (OVM_ETH).
  • This design inconsistency caused difficulties in maintaining accurate blockchain explorers and understanding account balances.
• StateDB and UsingOVM Redirection:
  • The implementation used patches to go-ethereum’s StateDB to redirect balance operations when UsingOVM was true.
  • This redirection was necessary to handle historical state synchronization.
• SELFDESTRUCT Opcode and Its Challenges:
  • SELFDESTRUCT is a problematic opcode in the Ethereum VM, allowing contracts to destroy themselves and release their balance to a beneficiary.
  • It poses challenges due to its potential to quickly release large amounts of state, requiring atomic operations.
• Bug in SELFDESTRUCT Handling:
  • The critical bug in Optimism’s implementation was related to the SELFDESTRUCT opcode.
  • When a contract self-destructed, its balance was both given to the beneficiary and retained, effectively duplicating funds.
  • The code did not correctly handle balance updates when SELFDESTRUCT was executed.
• Fix and Implementation of Inflation Logic:
  • Optimism introduced a fix for this bug by adding conditional logic in the opSuicide function.
  • This logic addressed the inflation issue by subtracting the balance if certain conditions were met.
  • The block number 3135900 was set as the cutoff for implementing this fix.
• Exploitation of the Bug:
  • Jay Freeman described a potential exploit for this bug using a Solidity contract. The contract, when self-destructed, transferred its balance to the beneficiary while retaining the funds, effectively creating new tokens.
  • The exploit allowed for the rapid duplication of funds, compounding earnings with each execution.
• Analysis of Exploitation Attempts:
  • Jay Freeman found evidence of one user experimenting with this bug on Optimism’s block explorer.
  • The user’s attempts were observed on Christmas Eve 2021, but it appeared that they did not fully understand the exploit’s potential.
• Final Observations:
  • The bug had not been widely exploited, and the extent of its exploitation on other Optimism forks like Boba and Metis was uncertain.
  • Jay Freeman provided a concrete example of how this bug could be exploited for financial gain.

Response and Resolution

Upon receiving the alert from Jay Freeman, the Optimism team swiftly analyzed the situation and confirmed the existence of the critical bug. Importantly, it was found that the bug had not been exploited maliciously. 

To mitigate the risk and fix the bug, the Optimism team developed and tested a solution. The fix was promptly deployed to both the Kovan testnet and the Mainnet, including all infrastructure providers, within hours of confirmation.

Later, the team extended their appreciation to Infura, QuickNode, and Alchemy for their rapid response and assistance during this incident.

Additionally, other projects and bridge providers that relied on Optimism forks were alerted to the issue, and they also applied the necessary fix to ensure their networks’ security.

Privileged Roles in OP Mainnet

As OP Mainnet progresses on its path to decentralization, certain “privileged” roles remain integral to its operational and security framework. These roles, equipped with specific capabilities, help manage and safeguard the network’s infrastructure. Understanding these roles, the risks they pose, and the mitigations in place is crucial for anyone involved in overseeing or reporting on OP Mainnet’s governance and operational protocols.

Privileged Roles Table

Role	Function	Risks	Mitigations
L1 Proxy Admin	Upgrades most OP Mainnet system contracts on L1.	Could upgrade contracts to malicious versions or interfere with the Standard Bridge.	Managed by a 2-of-2 multisig (Optimism Foundation 5/7 multisig and Security Council multisig).
L2 Proxy Admin	Upgrades most OP Mainnet system contracts on L2.	Similar risks as L1 Proxy Admin regarding contract upgrades and interference.	Controlled by a 5-of-7 multisig, enhancing decision-making security.
System Config Owner	Manages SystemConfig contract settings, affecting network operations and transaction costs.	Potential to cause network outages or overcharge users for transactions.	Also a 5-of-7 multisig, can be overridden by L1 Proxy Admin.
Batcher	Submits transaction batches to Ethereum on behalf of OP Mainnet Sequencer.	Susceptible to attacks that could lead to L2 reorgs or sequencer outages.	Hot wallet address that can be quickly replaced by L1 Proxy Admin in case of compromise.
Proposer	Submits state proposals to the L2OutputOracle contract for withdrawal execution.	Could propose invalid state changes affecting withdrawal transactions.	Can be replaced by L1 Proxy Admin; invalid proposals can be challenged within 7 days.
Challenger	Challenges invalid state proposals made by the Proposer.	Could fail to challenge invalid proposals or wrongly invalidate valid ones.	Role can be reassigned by L1 Proxy Admin to ensure proper functioning.
Guardian	Can pause all withdrawals from OP Mainnet as a security measure.	If compromised, could pause withdrawals indefinitely, affecting liquidity.	Tight control over pausing capability; can be overridden by L1 Proxy Admin.
Mint Manager Owner	Controls the MintManager contract that mints new OP tokens.	Could unauthorizedly mint or prevent minting of OP tokens.	Governed by a 3-of-5 multisig to ensure balanced control.

Each privileged role within OP Mainnet is safeguarded by a combination of multisig governance and administrative protocols, providing security layers against potential compromises. These roles are essential during OP Mainnet’s transition towards greater decentralization, requiring continuous monitoring and adjustments to adapt to evolving security needs. This structured presentation of roles ensures that stakeholders can quickly understand the operational dynamics and security frameworks of OP Mainnet.

Pausing and Unpausing the Bridge

The Optimism Portal, a L1 message-passing contract used across standard OP Stack chains, serves as the primary channel for communication between an OP Stack chain and its Ethereum parent chain. This contract is pivotal in handling L2-to-L1 transactions, which facilitate messages and other transactions from the L2 chain back to L1.

Pause Functionality

As a crucial safety feature, the Optimism Portal is equipped with pause functionality, which is controlled by a designated Guardian address. This mechanism allows the Guardian to halt all outgoing L2-to-L1 transactions temporarily. This pause function is particularly vital as it helps mitigate risks associated with withdrawal bugs, which have historically led to significant vulnerabilities in other bridging systems.

When the pause function is activated, the OptimismPortal will prevent the execution of all L2-to-L1 transactions. It’s important to note that this does not affect L1-to-L2 transactions, which continue to operate as normal. The pause impacts all L2-to-L1 transactions uniformly and cannot be applied selectively to specific users, contracts, or transaction types. It is intended as a broad safety measure, to be used only during significant security threats to the network.

Guardian Role and Functions

The Guardian address responsible for this function is initially set during the deployment of the OP Stack chain. It can be a standard address or configured as a more secure smart contract to incorporate additional controls and governance mechanisms. Modifying the Guardian address involves upgrading the Optimism Portal proxy contract to a new implementation that specifies a different Guardian address. If necessary, the Guardian role can also be effectively removed by setting it to an inaccessible address, like the zero address, thereby disabling the pause functionality.

Using the Pause and Unpause Functions:

The Guardian can activate the pause at any moment by calling the pause function on the Optimism Portal contract. To resume normal operations, the unpause function is used, restoring the ability to execute L2-to-L1 transactions. These functions ensure that the platform can maintain integrity and protect user assets while addressing potential vulnerabilities promptly. 

Security Policy, Vulnerability Reporting, and Bug Bounties

Optimism prioritizes security across its operations, specifically within the OP Stack and OP Mainnet environments. The organization upholds a stringent protocol for bug reporting and management, encouraging responsible disclosure practices to safeguard user interactions and system integrity.  

Vulnerability Disclosure Protocol

Optimism maintains a proactive approach to vulnerability management:

• Vulnerabilities are initially fixed in silence and included in subsequent releases without immediate public acknowledgment. 
• Disclosure is staggered: the existence of a fix is disclosed 4-8 weeks post-release, followed by detailed vulnerability information after an additional 4-8 weeks, ensuring system stability and security.
• Public disclosure of vulnerabilities is prohibited. Instead, researchers should use designated channels to report potential security issues. Testing for vulnerabilities should not be conducted on public networks (testnet or mainnet) to prevent risks to the system and users.

Optimism Bug Bounty Program on Immunefi

Optimism offers a substantial bounty of up to $2,000,042 for critical vulnerabilities that are discovered within the OP Mainnet codebase. The Optimism Bug Bounty Page on Immunefi provides comprehensive details, including scope, reporting instructions, and reward processes.

Immunefi Bug Bounty Details

• Program Link: Optimism on ImmuneFi
• Start Date: January 14, 2022
• KYC Requirements: Yes, to process reward payouts
• Last Updated: April 9, 2024

The bounty program aims to prevent theft or loss of assets through vulnerabilities in the smart contracts and critical blockchain client services like op-node and op-geth. It covers various components of the OP Stack, emphasizing the importance of security in decentralized systems.

Rewards are tiered based on the impact of the vulnerability, using the Immunefi Vulnerability Severity Classification System. This structured approach helps quantify the threat and aligns the reward with the potential risk mitigated by the disclosure.

Scope of the Program:

• Vulnerabilities not explicitly covered by existing bounties should still be reported through the Optimism Immunefi program. This ensures all potential threats are assessed and appropriately rewarded. 
• For vulnerabilities related to Optimism’s websites, email servers, or other infrastructures, reports should be directed to security@oplabs.co with detailed reproduction steps.

Team

Optimism, initially born out of the Plasma Group, carries forward the mission to scale Ethereum and improve transaction throughput significantly. Plasma Group was initially a non-profit research organization dedicated to Ethereum’s scalability. It was co-founded by a team passionate about implementing the Optimistic Rollup as a Layer 2 scaling solution for Ethereum.

Some of the core contributors include:

• Jinglan Wang – CEO and Executive Director
• Ben Jones – Co-Founder and Director
• Karl Floersch – Co-Founder and CEO
• Kevin Ho – Co-Founder and Protocol Product Manager
• Prithvi Subburaj – COO
• Mark Tyneway – Co-Founder and Systems Engineer
• Eva Beylin – Board Member
• Abbey Titcomb – Board Member
• Joshua Stein – Board Member
• Nick Balestra-Foster – Director of Engineering
• Matthew Slipper – Head of Engineering
• Kathy Zheng – Head of Design
• Kevin Zhijie Chen – Head of Security
• Smit Vachhani – Head of DeFi
• Tasia Potasinski – Head of Marketing
• Tess Rinearson – Head of Emerging Product
• Mattie Fairchild – Head of Developer Relations
• Stephanie V. – Head of People
• Vivian (Wei) Tao – Head of Global Partnerships
• Lynnette Nolan – Head of Communications
• Haonan Li – Head of Cryptoeconomics

Project Investors

Optimism has successfully completed three major funding rounds, securing a total of $178.5 million in investments. The funding journey highlights strategic partnerships with key venture capitals and investors, focused on advancing Ethereum’s scalability.

Detailed Breakdown of Funding Rounds:

1. Seed Round – January 15, 2020:
   • Amount Raised: $3.5 million
   • Investors: Paradigm, IDEO CoLab Ventures
   • Purpose: This initial funding kickstarted Optimism under its new setup, transitioning from a non-profit research team (Plasma Group) to a for-profit entity aiming to implement the Optimistic Rollup solution.
2. Series A – February 24, 2021:
   • Amount Raised: $25 million
   • Lead Investor: Andreessen Horowitz (a16z)
   • Other Participants: Wintermute, Nascent
   • Focus: This round supported early development, allowing Optimism to enhance its technological infrastructure and expand its team.
3. Series B – March 17, 2022:
   • Amount Raised: $150 million
   • Lead Investors: Andreessen Horowitz, Paradigm
   • Other Participants: Wintermute, Nascent

Additional Information

Glossary

General Terms

• Address Aliasing: A modified representation of a contract’s address when it submits a deposit from L1 to L2.
• Block: A sequential list of transactions stored along with properties in the block header. This term can refer to both L1 and L2 blocks.
• Block Time: The interval at which new blocks are produced. For L2 on Optimism, this is every 2 seconds.
• EOA (Externally Owned Account): Addresses controlled by users, not contracts.
• Execution Engine: Computes state roots, receipts roots, and block hash by executing transactions within blocks on both L1 and L2.
• Optimism Collective: A group committed to building a beneficial economy, following the principle that positive impact equals profit.
• L2 Output Root: A 32-byte value representing the current state of the L2 chain.
• L2 Output Oracle Contract: An L1 contract where L2 output roots are posted by the sequencer.
• Predeployed Contract: A contract included in the L2 genesis state.
• PGA (Priority Gas Auction): A bidding process to prioritize transaction processing based on gas price.
• Receipt: Generated by a transaction, including a status code, gas used, log entries, and a bloom filter.

OP Profile & Identity

• Attestations: Statements providing evidence or information.
• Attestation Recipient: The entity receiving the attestation.
• Attestation Issuer: The entity issuing the attestation.
• Attestation Verifier: The entity verifying the attestation’s validity.
• Ethereum Attestation Service (EAS): An infrastructure for making attestations on or off-chain.
• Sybil-resistance: Preventing the creation of multiple fake identities.

OP Stack & OP Superchain

• Attestation-Based Fault Proof: A fault proof verified by supplying an attestation proof.
• Cannon Fault Proof: An onchain game-based fault proof ensuring truthful outcomes.
• Chain: A state transition system with a cryptographic commitment.
• Chain Proof: Evidence supporting the validity of a withdrawal claim.
• Fault Proof: A proof relying on the absence of counter-evidence for correctness.
• L1 Origin: The L1 block corresponding to an L2 block’s sequencing epoch.
• Merkle Patricia Trie: A tree structure mapping keys to values, enabling Merkle proofs.
• OP Chain: Part of the Optimism Superchain, governed by the Optimism Collective.
• OP Mainnet: The first chain to adopt the Superchain vision, powered by the OP Stack.
• Rollup Chain: A chain where all transaction data is submitted to L1.
• Sequencer: Entity or contract prioritized for submitting transactions to an OP Chain.
• Superchain: A platform of interconnected chains sharing security and technology.
• Validity Proof: A proof allowing immediate validation of a withdrawal claim.

Protocol

• Batcher: A component making channels available on a data availability provider.
• Deposit: An L2 transaction derived from an L1 block.
• Finalization Period: The minimum time before a withdrawal can be finalized.
• Relayer: An EOA that finalizes a withdrawal on L1.
• Safe L2 Block: An L2 block derived entirely from L1 data.
• Sequencer Batch: A list of L2 transactions for constructing L2 blocks.
• System Configuration: Dynamically configurable rollup parameters.
• Unsafe L2 Block: An L2 block not derived from L1, needing confirmation.
• Withdrawal Transaction: An L2 to L1 transaction for transferring data or value.

FAQ

How does OP Mainnet function?

• OP Mainnet functions as an optimistic rollup, where transactions are executed off-chain by a single sequencer to reduce costs. Data integrity and security are maintained by Ethereum mainnet through a verification challenge mechanism.

What is the concept behind a rollup?

• A rollup is a layer 2 solution that enables transactions on an ancillary blockchain while leveraging the security and data integrity of Ethereum’s mainnet. It posts transaction data as calldata to Ethereum, ensuring that the results are verifiable either through economic-based challenges or cryptographic proofs.

Is OP Mainnet a sidechain?

• No, OP Mainnet is not a sidechain. Unlike sidechains, which have their own consensus mechanisms, OP Mainnet’s verification is conducted through Ethereum mainnet smart contracts, ensuring Ethereum-like availability and integrity.

What should be done if a transaction is stuck or pending?

• For a transaction stuck due to a low gas fee, submit another transaction with the same nonce and a higher fee to prompt quicker processing by the sequencer.

How are transaction gas fees on OP Mainnet calculated?

• OP Mainnet transaction fees comprise two parts: the L2 execution fee and the L1 data fee. The former covers the execution cost on L2, while the latter estimates the cost for including the transaction data on L1.

Will transaction costs on OP Mainnet decrease in the future?

• While OP Mainnet aims to reduce costs by optimizing transaction data size and improving compression algorithms, the inherent need to write transactions to the Ethereum mainnet sets a baseline for the minimum possible cost.

Is there a mandatory waiting period for withdrawals from OP Mainnet?

• Yes, withdrawals through the OP Mainnet Gateway require a seven-day waiting period, although third-party bridges may offer faster services for an additional fee.

How can token allowances be managed or revoked?

• Token allowances can be managed and revoked using platforms like revoke.cash to ensure safe and secure transactions within decentralized applications.

What is OP Mainnet’s roadmap to achieving full decentralization?

• OP Mainnet’s path to decentralization includes releasing multi-client proof contracts and supporting the creation of alternative clients, with the ultimate goal of relinquishing control over contract upgrades to a trusted entity or the community.

What changes were introduced with the Bedrock update?

• The Bedrock update brought in reduced L1 security fees, consistent block production every two seconds, adoption of EIP 1559 fee mechanisms, and a new process for handling transactions that include a private mempool for transaction ordering.

Is it possible to front-run transactions on OP Mainnet?

• Currently, front-running is challenging due to the private nature of the transaction pool. However, as the network moves towards decentralization, and if the transaction pool becomes public, front-running could become feasible.

What happens if the L1 gas price spikes during a transaction process?

• Once the sequencer processes a transaction, the user’s fee is locked in, and any subsequent spike in L1 gas prices is borne by Optimism.

What software license is used by The Optimism Foundation?

• The Optimism Foundation typically uses the MIT License for its software. Any software forked from go-ethereum is licensed under GNU GPLv3, as per the original licensing terms.

What governance rights does the OP token confer?

• The OP token allows holders to participate in the governance of the Optimism protocol, which is stewarded by the Optimism Foundation in accordance with the Optimism Collective’s Working Constitution.

What is the core ethos behind Optimism?

• Optimism is focused on scaling Ethereum’s technology and values, particularly by supporting the development and profitability of impactful public goods within the decentralized ecosystem.

How are public goods defined within the Ethereum ecosystem?

• Public goods in the Ethereum ecosystem are resources, services, or information that cannot be monetized directly. Examples include open-source projects like geth, which provide foundational support to various applications and platforms in the ecosystem.

Why is there a need for a new public goods funding mechanism?

• With limited resources from the Ethereum Foundation, the Optimism Collective seeks to establish a decentralized and sustainable funding mechanism that operates in parallel to existing structures, ensuring continuous support for the ecosystem.

Security FAQs

Is every OP Stack chain safe?

• The security of an OP Stack based blockchain varies with the components it utilizes. Due to the OP Stack’s flexible and permissionless design, it’s feasible for chains to be established without incorporating essential security features, opting instead for different OP Stack components. 
• While aiming to offer secure defaults, users should be aware that any system, including those built on the OP Stack, could harbor undiscovered bugs potentially leading to the loss of assets. Although many parts of the OP Stack have undergone audits, these do not eliminate all risks associated with new technologies, and an audit’s completion doesn’t guarantee a bug-free codebase.

How does the flexibility of the OP Stack affect its security?

• The OP Stack’s security is influenced by its flexible nature, allowing for a variety of configurations. However, modifying the OP Stack can be risky and is not recommended for those unsure about the implications of their changes. 
• The OP Stack currently advises against modifications outside its standard Rollup configuration and does not provide support for such changes.

Can one use fault proofs with the OP Stack?

• Currently, the OP Stack does not support fault proofs. 
• The absence of fault proofs doesn’t significantly impact the security of a system that can be upgraded quickly, as the security in such cases relies on the upgrade mechanism. 
• The development of fault proofs is a high priority for the OP Stack, aiming to enhance security options available before fault proofs are integrated into production.

How can one contribute to the security of the OP Stack?

• Contributing to the OP Stack’s security can be as simple as identifying bugs and vulnerabilities. 
• The OP Mainnet, powered by the OP Stack, offers substantial bug bounties for discovering critical flaws, with rewards up to $2m. 
• Additionally, contributing to the OP Stack’s decentralized development by creating software that adheres to its design principles, such as alternative client or proof implementations, can further enhance its security.

Community Links

• Website
• Bridge
• Block Explorer
• Status
• Current Gas Price
• Community Docs
• Developer Docs
• Ecosystem
• Twitter
• Discord
• Governance Forum
• Governance Library
• Coingecko
• DefiLlama