Using the Predeploys Address Set

The OP Stack predeploys are a set of smart contracts deployed at deterministic addresses during the chain's genesis. These are not merely convenience contracts; they are the canonical interfaces for core protocol functions including cross-chain messaging (L2ToL1MessagePasser at 0x4200000000000000000000000000000000000016), gas fee calculation (GasPriceOracle at 0x420000000000000000000000000000000000000F), and the wrapped native token (WETH9 at 0x4200000000000000000000000000000000000006). Unlike contracts deployed post-genesis, these addresses are invariant and must be used directly by all system participants—wallets, bridges, indexers, and applications—to interact correctly with the protocol.

Hardcoding these addresses in application logic, bridge contracts, or off-chain services is a critical integration risk. While the addresses are fixed for a given chain, the Superchain's evolution through upgrades and new chain deployments means that a hardcoded address from one OP Stack chain may be incorrect on another. Furthermore, protocol upgrades can change the internal logic of a predeploy while preserving its address and interface, making direct address usage the only future-proof integration pattern. For example, the fault-proof system upgrade fundamentally altered the withdrawal proving flow, but the OptimismPortal address remained the single entry point. Integrators who used the canonical address required no migration; those who bypassed it faced broken withdrawal flows.

For operators, builders, and risk teams, the predeploy address set is the authoritative map for security review and monitoring. A bridge operator must verify that their off-chain relay service monitors the correct L2ToL1MessagePasser for withdrawal initiations. An exchange must confirm that its deposit detection logic queries the correct OptimismPortal for L1-to-L2 transactions. Chainscore Labs can audit integration codebases to ensure correct predeploy address usage, assess upgrade safety by verifying that all protocol interactions flow through canonical addresses, and build monitoring systems that track state changes on these critical contracts to provide early warning of anomalous protocol behavior.

The OP Stack predeploy system provides a canonical set of smart contracts at fixed addresses on every OP Stack chain, including L2ToL1MessagePasser (0x4200000000000000000000000000000000000016), GasPriceOracle (0x420000000000000000000000000000000000000F), and WETH (0x4200000000000000000000000000000000000006). These addresses are guaranteed to remain constant across all OP Stack chains and future upgrades, forming a stable interface layer that builders can rely on. However, the internal logic deployed at these addresses is not guaranteed to remain static. The OP Stack uses a proxy-like architecture where the predeploy address is permanent, but the contract implementation can be upgraded through network hard forks or Superchain-wide upgrades.

This dual-layer design creates a critical safety rule for builders: always reference predeploys by their canonical address, never by their bytecode or internal storage layout. A contract that hardcodes the storage slot of a predeploy's internal variable, or that copies a predeploy's bytecode into its own constructor, will silently break when the predeploy implementation is upgraded. The L1Block predeploy (0x4200000000000000000000000000000000000015) is a concrete example: its interface for reading L1 block attributes is stable, but the internal mechanism for how those values are set has changed across protocol upgrades. Contracts that interact with predeploys through their public interfaces remain compatible; contracts that reach into internal state do not.

For chain deployers, modifying predeploys requires understanding that these contracts are embedded in the genesis state and validated by the op-program fault proof. Any change to a predeploy's bytecode alters the state root and must be coordinated with the derivation pipeline and all downstream tooling. Block explorers, indexers, and wallets often hardcode assumptions about predeploy interfaces—a modified GasPriceOracle that changes the fee calculation signature will break every wallet's fee estimation. Chainscore Labs can audit predeploy modifications for downstream compatibility risks and review integration code to ensure it uses only the stable address layer, not the mutable implementation layer.