Merge branch 'main' into superchain-ops-upgrades

Author: bradleycamacho

pages/app-developers/tools/connect/_meta.json

@@ -1,4 +1,4 @@
 {
     "networks": "Networks and RPC endpoints",
-    "rpc-providers": "RPC and Node providers"
+    "rpc-providers": "Superchain RPC directory"
 }

pages/app-developers/tools/connect/rpc-providers.mdx

@@ -115,7 +115,7 @@ The transaction that receives the message on the destination chain calls a contr
 This call can be at the top level, directly from the externally owned account, or come through a smart contract.
 The call to `CrossL2Inbox`, also known as the *executing message*, needs to [identify the initiating message uniquely](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L35-L42), using the chain ID of the source chain, the block number, and the index of the log event within that block, as well as a few other fields as a sanity check.
 
-`CrossL2Inbox` can either [validate the message exists](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L171-L185), or [call a contract if the message exists](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L171-L185).
+`CrossL2Inbox` can either [validate the message exists](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L76-L83), or [call a contract if the message exists](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/src/L2/CrossL2Inbox.sol#L76-L83).
 
 ## Block safety levels
 

pages/interop/explainer.mdx

@@ -1,5 +1,5 @@
 ---
-title: Upgrade 15 - Isthumus Hard Fork
+title: Upgrade 15 - Isthmus Hard Fork
 description: Learn how to prepare for Isthmus hard fork breaking changes.
 lang: en-US
 content_type: notice

pages/notices/upgrade-15.mdx

@@ -27,7 +27,7 @@ options are from the `--help` in [v1.7.6](https://github.com/ethereum-optimism/o
 
 ## Proposer policy
 
-The proposer policy defines high-level constraints and responsibilities regarding how L2 output roots are posted to L1. Below are the [standard guidelines](/superchain/standard-configuration) for configuring the batcher within the OP Stack.
+The proposer policy defines high-level constraints and responsibilities regarding how L2 output roots are posted to L1. Below are the [standard guidelines](/superchain/standard-configuration) for configuring the proposer within the OP Stack.
 
 | Parameter        | Description                                                                         | Administrator  | Requirement                                                | Notes                                                                                                                                         |
 | ---------------- | ----------------------------------------------------------------------------------- | -------------- | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |

pages/operators/chain-operators/configuration/batcher.mdx

@@ -14,7 +14,7 @@ categories:
   - node-management
   - genesis-creation
   - deployment-artifacts
-is_imported_content: 'false'
+is_imported_content: 'false' 
 ---
 
 import { Card, Cards } from 'nextra/components'
@@ -29,4 +29,7 @@ This section provides information on OP Stack genesis creation, deployment overv
   <Card title="Op stack deployment overview" href="/operators/chain-operators/deploy/overview" />
 
   <Card title="Op stack smart contract deployment" href="/operators/chain-operators/deploy/smart-contracts" />
+
+  <Card title="Learn how to validate your OP Stack deployment using op-validator" href="/operators/chain-operators/deploy/validate-deployment" />
+  
 </Cards>

pages/operators/chain-operators/configuration/proposer.mdx

@@ -89,88 +89,6 @@ Once you have `genesis.json` and `rollup.json`:
 2.  Configure op-node with rollup.json.
 3.  Set up additional off-chain infrastructure as needed (block explorer, indexers, etc.). For more on architecture, see [Architecture overview](/operators/chain-operators/architecture).
 
-## Legacy method: using foundry script
-
-The following guide shows you how to generate the L2 genesis file `genesis.json`. This is a JSON
-file that represents the L2 genesis. You will provide this file to the
-execution client (op-geth) to initialize your network. There is also the rollup configuration file, `rollup.json`, which will be
-provided to the consensus client (op-node).
-
-<Callout type="warning">
-  The following genesis creation information is the legacy method for creating OP Stack configuration files.
-  This method is not recommended. It's preserved here for historical context.
-</Callout>
-
-
-### Solidity script (Legacy)
-
-You can also use the foundry script
-located in the monorepo to generate an "L2 state dump" and then pass this into the op-node genesis subcommand.
-The foundry script can be found at
-[packages/contracts-bedrock/scripts/L2Genesis.s.sol](https://github.com/ethereum-optimism/optimism/blob/develop/packages/contracts-bedrock/scripts/L2Genesis.s.sol).
-
-<Callout type="info">
-When generating the genesis file, please use the same `op-contracts/vX.Y.Z` release commit used for L1 contract deployments.
-</Callout>
-
-### Configuration
-
-Create or modify a file `<network-name>.json` inside the `deploy-config`
-folder in the monorepo. The script will read the latest active fork from the
-deploy config and the L2 genesis allocs generated will be compatible with this
-fork. The automatically detected fork can be overwritten by setting the
-environment variable `FORK` either to the lower-case fork name (currently
-`delta`, `ecotone`, or `fjord`) or to `latest`, which will select the latest fork
-available (currently `fjord`).
-
-By default, the script will dump the L2 genesis allocs (aka "state dump") of the detected or
-selected fork only, to the file at `STATE_DUMP_PATH`. The optional environment
-variable `OUTPUT_MODE` allows you to modify this behavior by setting it to one of
-the following values:
-
-*   `latest` (default) - only dump the selected fork's allocs.
-*   `all` - also dump all intermediary fork's allocs. This only works if
-    `STATE_DUMP_PATH` is not set. In this case, all allocs will be written to files
-    `/state-dump-<fork>.json`. Another path cannot currently be specified for this
-    use case.
-*   `none` - won't dump any allocs. Only makes sense for internal test usage.
-
-### Creation
-
-*   `CONTRACT_ADDRESSES_PATH` represents the deployment artifact that was
-    generated during a contract deployment.
-*   `DEPLOY_CONFIG_PATH` represents a path on the filesystem that points to a
-    deployment config. The same deploy config JSON file should be used for L1 contracts
-    deployment as when generating the L2 genesis allocs.
-*   `STATE_DUMP_PATH` represents the filepath at which the allocs will be
-    written to on disk.
-
-```bash
-CONTRACT_ADDRESSES_PATH=<CONTRACT_ADDRESSES_PATH> \
-DEPLOY_CONFIG_PATH=<PATH_TO_MY_DEPLOY_CONFIG> \
-STATE_DUMP_PATH=<PATH_TO_WRITE_L2_ALLOCS> \
-  forge script scripts/L2Genesis.s.sol:L2Genesis \
-  --sig 'runWithStateDump()'
-  ```
-
-## Subcommand (op-node genesis l2)
-
-The genesis file creation is handled by the `genesis l2`
-subcommand, provided by the `op-node`. The following is an example of its usage
-from [v1.7.6](https://github.com/ethereum-optimism/optimism/releases/tag/v1.7.6) --
-note that you need to pass the path to the l2 genesis state dump file output by
-the foundry script above:
-
-```bash
-go run cmd/main.go genesis l2 \
-  --deploy-config=<Path to deploy config file> \
-  --l1-deployments=<Path to L1 deployments JSON file as in superchain-registry> \
-  --l2-allocs=<Path to L2 genesis state dump> \
-  --outfile.l2=<Path to L2 genesis output file: i.e. ./genesis.json> \
-  --outfile.rollup=<Path to rollup output file: i.e. ./rollup.json> \
-  --l1-rpc=<RPC URL for an Ethereum L1 node. Cannot be used with --l1-starting-block>>
-```
-
 ## Next steps
 
 *   Learn how to [initialize](/operators/node-operators/configuration/base-config#initialization-via-genesis-file)

pages/operators/chain-operators/deploy.mdx

@@ -22,46 +22,91 @@ import { Callout, Steps } from 'nextra/components'
 
 # OP Stack smart contract deployment
 
+This guide outlines the process for deploying the OP Stack L1 smart contracts using `op-deployer`.
+
+## Overview
+
+Deploying OP Stack L1 contracts is a critical step in setting up your rollup.
+
 <Callout type="warning">
-This page is out of date and shows the legacy method for smart contract deployment.
-For the latest recommended method, use [op-deployer](/operators/chain-operators/tools/op-deployer).
+  Always deploy from official contract releases. You can find official release versions in the
+  [smart contract overview](/stack/smart-contracts#official-releases). Contract changes are
+  generally not considered backwards compatible.
 </Callout>
 
-The following guide shows you how to deploy the OP Stack L1 smart contracts.
-The primary development branch is `develop`, however **you should only deploy
-official contract releases**. You can visit the [smart contract overview](/stack/smart-contracts#official-releases)
-for the official release versions. Changes to the smart contracts are
-generally not considered backwards compatible.
+## Deployment workflow
+
+<Steps>
+  ### Install op-deployer
+
+  First, install the `op-deployer` tool following the [installation instructions](/operators/chain-operators/tools/op-deployer#installation).
+
+  ### Create an intent file
+
+  Generate an intent file that defines your chain configuration:
+
+  ```bash
+  op-deployer init \
+    --l1-chain-id <chain ID of your L1> \
+    --l2-chain-ids <comma-separated list of chain IDs for your L2s> \
+    --workdir .deployer \
+    --intent-type <standard|custom|standard-overrides>
+  ```
+
+  Customize the generated intent file according to your requirements. See the [op-deployer configuration guide](/operators/chain-operators/tools/op-deployer#understanding-the-intenttoml-fields) for details.
+
+  ### Deploy the contracts
 
-## Deployment configuration
+  Execute the deployment:
 
-Deploying your OP Stack contracts requires creating a deployment configuration
-JSON file. You will create a new deployment configuration file in the following
-monorepo subdirectory: [packages/contracts-bedrock/deploy-config](https://github.com/ethereum-optimism/optimism/tree/develop/packages/contracts-bedrock/deploy-config)
-For the full set of deployment configuration options and their meanings, you
-can see the [rollup deployment configuration page](/operators/chain-operators/configuration/rollup).
+  ```bash
+  op-deployer apply --workdir .deployer --l1-rpc-url <rpc-url> --private-key <private key hex>
+  ```
 
-For a detailed explanation of the configuration options and their meanings, refer to the [rollup deployment configuration page](/operators/chain-operators/configuration/rollup).
+  ### Verify contract source code (Optional)
 
-## Using `op-deployer`
+  Verify your deployed contracts on block explorers:
 
-The recommended way to deploy the L1 smart contracts is with the `op-deployer` tool.
-Follow the steps in this [section](/operators/chain-operators/tutorials/create-l2-rollup#using-op-deployer) to learn how it works.
+  ```bash
+  op-deployer verify \
+    --l1-rpc-url <l1 rpc url> \
+    --etherscan-api-key <your free etherscan api key>
+  ```
+
+  ### Generate chain configuration files
+
+  Generate the necessary configuration files for your L2 node:
+
+  ```bash
+  op-deployer inspect genesis --workdir .deployer <l2-chain-id> > .deployer/genesis.json
+  op-deployer inspect rollup --workdir .deployer <l2-chain-id> > .deployer/rollup.json
+  ```
+</Steps>
+
+## Contract versioning
+
+The OP Stack follows semantic versioning (X.Y.Z) for contract releases:
+
+*   **Major (X):** Breaking changes that require coordination, such as Ecotone or the Fault Proof System
+*   **Minor (Y):** New features or improvements that maintain backwards compatibility
+*   **Patch (Z):** Bug fixes and minor improvements
+
+Contract releases are tagged in the repository as `op-contracts/vX.Y.Z`.
+
+<Callout type="info">
+  For standard chains intended to join the Superchain, always use the latest Optimism Governance approved
+  release. You can find these in the [Superchain Registry](https://github.com/ethereum-optimism/superchain-registry).
+</Callout>
 
+## Version compatibility
 
-## Best practices
+When selecting a contract version, consider:
 
-Production users should deploy their L1 contracts from a contracts release.
-All contracts releases are on git tags with the following format:
-`op-contracts/vX.Y.Z`. If you're deploying a new standard chain, you should
-deploy the latest Optimism Governance approved release of the L1 smart contracts with [op-deployer](/operators/chain-operators/tools/op-deployer). This will only initially deploy with permissioned dispute games
-enabled.
-Starting with permissioned fault proofs gives chain operators time to get comfortable
-running the additional infrastructure requirements: [op-challenger](https://github.com/ethereum-optimism/optimism/tree/develop/op-challenger) and
-[monitoring](https://github.com/ethereum-optimism/monitorism/tree/main). There are also
-additional changes to the economics of operating a permissionless fault proof that chain operators should fully understand.
+*   L2 Client compatibility: Ensure your chosen contract version is compatible with the op-geth and op-node versions you plan to use
+*   Feature requirements: Different versions support different features (e.g., only v2.0.0+ supports permissionless fault proofs)
+*   Security updates: Always prefer the latest patch version within your chosen major.minor version
 
-## Next steps
+## Next Steps
 
-*   Learn how to [create your genesis file](/operators/chain-operators/deploy/genesis)
-*   See all [configuration options](/operators/chain-operators/configuration/rollup) and example configurations
+*   Learn how to [create your genesis file](/operators/chain-operators/deploy/genesis).
+*   See all [configuration options](/operators/chain-operators/configuration/rollup) and example configurations.