DOCSEARCHbyAlgolia
Submit Docs

Optimism Developer Documentation

website·Indexed 41 days ago

https://docs.optimism.io

Guides and reference for building applications on OP Mainnet and OP Stack chains. Includes documentation on bridging tokens and data between L1 and L2, cross-chain interoperability, transaction fee estimation, and the Actions SDK for integrating DeFi operations like lending and swapping.

Tokens
281.9K
Snippets
1.1K
Records
2.1K
Agent score
74%

What's inside Optimism

  1. Overview of production OP Stack chain launch requirements

    Launching a production OP Stack chain requires two critical components that are difficult to retrofit: a fault-proof system to secure withdrawals and a high-availability (HA) sequencer topology to eliminate single points of failure. The architecture involves op-deployer for L1 contracts, a cluster of op-node and op-reth sequencers managed by op-conductor, and L1-facing services including op-batcher, op-proposer, op-challenger, and op-dispute-mon.

  2. Overview of the OP Stack Batcher

    The batcher (op-batcher) is a critical component that bridges L2 chain data to L1. It reads transaction data from the sequencer and submits compressed batches to the BatchInbox contract on L1. Its primary responsibilities include batch submission, ensuring data availability on L1, optimizing costs through data compression, and managing data channels for submission timing.

  3. Overview of OP Stack Interoperability

    OP Stack interoperability is a set of protocols that allow OP Stack chains to read each other's state. This enables a network of chains to function as a single blockchain, supporting native minting and burning of ETH and ERC-20 tokens between chains, low-latency cross-chain contract composition, and horizontal scaling of applications across multiple chains. Note that interop is in active development and some features may be experimental.

  4. Overview of Custom Gas Token (CGT) v2

    Custom Gas Token (CGT) allows OP Stack chains to use any asset (e.g., stablecoins, governance tokens, or new native assets) as the native fee currency instead of ETH. CGT v2 (introduced in op-contracts/v6.0.0) decouples native asset management from core bridging infrastructure, moving bridging and converters to the application layer for greater flexibility in supply management and token choice.

  5. Overview of the kona-engine Execution Engine

    The kona-engine crate provides a modular execution engine for OP Stack rollup nodes. It acts as the bridge between the rollup protocol and the execution layer (EL), managing Engine API interactions via a priority-ordered task queue. Key components include the Engine Task Queue, Trait Abstractions for tasks/errors, an HTTP Engine Client, and the EngineActor for service layer integration.

  6. Overview of upgrading OP Stack chains to super-root dispute games

    This process upgrades a single OP Stack chain from output-root dispute games to super-root dispute games using a single opcm.upgrade call against the chain's AnchorStateRegistry and DisputeGameFactory. The chain's permission model is preserved during the upgrade:

    • Permissioned chains: Move from PERMISSIONED_CANNON to SUPER_PERMISSIONED (Game Type 5).
    • Permissionless chains: Move from CANNON or CANNON_KONA to SUPER_CANNON_KONA (Game Type 9).

    Existing pre-migration dispute games continue to resolve, and proven withdrawals remain valid. This is an opcm.upgrade (preserving per-chain registries), not an opcm.migrate.

  7. Overview of OP Stack P2P Networking

    The OP Stack uses P2P networking on the consensus layer to share the sequencer's view of the L2 chain. L2 blocks shared via P2P are considered "unsafe" and are reorganized to match the canonical chain (prioritizing L1). Because P2P behavior does not affect rollup security, peer banning and scoring policies are left to the user's configuration.

  8. Overview of the Cannon Fault Proof VM

    Cannon is the default Fault Proof Virtual Machine (FPVM) used in the Dispute Game for OP Stack Blockchains. It is designed to resolve disputes by identifying a single MIPS instruction that participants disagree on and verifying its execution onchain. Cannon consists of two primary components:

    1. Onchain (MIPS64.sol): An EVM implementation used to verify the execution of a single MIPS instruction.
    2. Offchain (mipsevm): A Go implementation used to produce the proof for any MIPS instruction to be verified onchain.

    The program executed within Cannon is the kona-client, which is compiled as a big-endian 64-bit MIPS (MIPS64) ELF binary targeting mips64-unknown-none.

  9. Overview of Actions SDK for DeFi

    The Actions SDK is an open-source TypeScript development toolkit designed to simplify the integration of DeFi actions (such as Lend, Borrow, Swap, and Pay) into applications. It uses a modular provider system to allow developers to choose specific services and protocols, supports embedded wallets for email-based authentication, and provides a centralized configuration to manage allowed/blocked assets, markets, chains, and protocols.

    Warning: The Actions SDK is currently under construction and is intended for early testing purposes only; it is not yet ready for production use.

  10. Overview of OP-Challenger in the Fault Proof System

    The op-challenger acts as the honest actor in the OP Stack's fault dispute system. Its primary purpose is to secure the OptimismPortal and ensure dispute games resolve to the correct chain state. It relies on a synced, trusted rollup node and a trace provider (such as Cannon) to verify claims.

    Key responsibilities include:

    • Monitoring and interacting with dispute games.
    • Defending valid output root proposals.
    • Challenging invalid output root proposals.
    • Assisting the op-proposer in resolving claims and games after chess clocks expire.
    • Claiming paid-out bonds for both the challenger and proposer.

  11. Overview of the Lagoon Hardfork

    Lagoon is a network upgrade for the OP Stack designed to activate Superchain interoperability. This includes cross-chain messaging, interop fault proofs, and interop bridging contracts. Additionally, it introduces execution layer updates regarding post-execution transactions and sequencer-defined metering. As of the current development phase, superchain-wide activation defaults are not yet set in the superchain-registry; activations are being handled on a per-chain basis.

  12. Overview of op-challenger responsibilities

    The op-challenger is a critical fault proofs component that protects an OP Stack chain by monitoring dispute games. Its primary responsibilities include:

    • Monitoring dispute games created by the fault proof system
    • Challenging invalid claims in dispute games
    • Defending valid state transitions
    • Resolving games when possible.