ethereum-optimism · sbvegan · Nov 25, 2025 · Nov 25, 2025 · Nov 25, 2025 · Nov 25, 2025
@@ -64,7 +64,6 @@
 
         (1) This should be an address you control (for which you know the private key), which has some ETH on the blockchains in question.
         In the case of Supersim, the default has 10k ETH and you can use it.
-        For the devnets, [see here](/app-developers/guides/building-appst#sending-eth-to-the-interop-devnets) to send ETH.
 
     4.  If you change `owner_address`, you need to also set the private key.
         Edit `packages/contracts/.env` to set `DEPLOYER_PRIVATE_KEY` to the private key of an account that has ETH on both devnet blockchains.
@@ -132,9 +131,9 @@
 import {Ownable} from "@solady/auth/Ownable.sol";

 contract CustomSuperchainToken is SuperchainERC20, Ownable {
    string private _name;
    string private _symbol;
    uint8 private immutable _decimals;

    constructor(address owner_, string memory name_, string memory symbol_, uint8 decimals_) {
        _name = name_;
@@ -274,5 +273,5 @@
 ## Next steps

 *   Use the [SuperchainERC20 Starter Kit](/app-developers/starter-kit) to deploy your token across the Superchain.
 *   If you'd like a guided walkthrough, check out our [tutorial video](https://x.com/i/status/1866095114374045969) instead.
 *   Review the [Superchain Interop Explainer](/interop/explainer) for answers to common questions about interoperability.
@@ -57,7 +57,7 @@

 The `op-batcher` has the capabilities to send multiple blobs per single blob transaction. This is accomplished by the use of multi-frame channels, see the [specs](https://specs.optimism.io/protocol/derivation.html#frame-format?utm_source=op-docs&utm_medium=docs) for more technical details on channels and frames.

 A minimal batcher configuration (with env vars) to enable 6-blob batcher transactions is:

 ```
 ```
@@ -67,7 +67,7 @@
 The resubmission timeout is increased to a few minutes to give more time for inclusion before bumping the fees because current transaction pool implementations require a doubling of fees for blob transaction replacements.
 
 Multi-blob transactions are particularly useful for medium to high-throughput chains, where enough transaction volume exists to fill up 6 blobs in a reasonable amount of time.
-You can use [this calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit?gid=186414307#gid=186414307) for your chain to determine what number of blobs are right for you, and what gas scalar configuration to use. Please also refer to guide on [Using Blobs](/operators/chain-operators/management/blobs) for chain operators.
+You can use [this calculator](https://docs.google.com/spreadsheets/d/1V3CWpeUzXv5Iopw8lBSS8tWoSzyR4PDDwV9cu2kKOrs/edit?gid=186414307#gid=186414307) for your chain to determine what number of blobs are right for you, and what gas scalar configuration to use. Please also refer to guide on [Using Blobs](/chain-operators/guides/features/blobs) for chain operators.
 
 ### Set your `--batch-type=1` to use span batches
 
@@ -110,7 +110,7 @@
 In this case, make sure the miner API namespace is enabled for the correct transport protocol (HTTP or WS), see next paragraph.
 ```

 The new RPC `miner_setMaxDASize` is available in `op-geth` since `v1.101411.1`. It has to be enabled by adding the miner namespace to the correct API flags, like

 ```
 GETH_HTTP_API: web3,debug,eth,txpool,net,miner
@@ -286,7 +286,7 @@

 Indicates if, during startup, the batcher should wait for a recent batcher tx
 on L1 to finalize (via more block confirmations). This should help avoid
 duplicate batcher txs. The default value is `false`.

 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
  <Tabs.Tab>`--wait-node-sync=<value>`</Tabs.Tab>
@@ -541,7 +541,7 @@

 Headers to pass to the remote signer. Format `key=value`.\
 Value can contain any character allowed in an HTTP header.\
 When using env vars, split multiple headers with commas.\
 When using flags, provide one key-value pair per flag.

 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>
@@ -746,7 +746,7 @@

 #### log.format

 Format the log output. Supported formats: 'text', 'terminal', 'logfmt', 'json',
 'json-pretty'. The default value is `text`.

 <Tabs items={['Syntax', 'Example', 'Environment Variable']}>

@@ -133,7 +133,7 @@

  **L1 network access:**

  *   L1 RPC URL: Your L1 node endpoint (Infura, Alchemy, or self-hosted)
  *   L1 Beacon URL: Beacon chain API endpoint for blob access

  **L2 network access:**
@@ -150,7 +150,7 @@
  *   Game factory address from your contract deployment
  *   Network identifier (e.g., op-sepolia, op-mainnet, or custom)

  Copy and paste in your terminal, to create your env file.

  ```bash
  # Create .env file with your actual values
@@ -298,12 +298,12 @@

  <Expandable title="--cannon-prestates-url">

  The pre-state is effectively the version of `op-program` that is deployed on chain. And chain operators must use the right version. `op-challenger` will refuse to interact with games that have a different absolute prestate hash to avoid making invalid claims. If deploying your own contracts, chain operators must specify an absolute prestate hash taken from the `make reproducible-prestate` command during contract deployment, which will also build the required prestate json file.

  All governance approved releases use a tagged version of `op-program`. These can be rebuilt by checking out the version tag and running `make reproducible-prestate`.

  *   There are two ways to specify the prestate to use:
      *   `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file
      *   `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash.
  *   Example final URL for a prestate:
      *   [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json)
@@ -515,12 +515,12 @@

  <Expandable title="--cannon-prestates-url">

  The pre-state is effectively the version of `op-program` that is deployed on chain. And chain operators must use the right version. `op-challenger` will refuse to interact with games that have a different absolute prestate hash to avoid making invalid claims. If deploying your own contracts, chain operators must specify an absolute prestate hash taken from the `make reproducible-prestate` command during contract deployment, which will also build the required prestate json file.

  All governance approved releases use a tagged version of `op-program`. These can be rebuilt by checking out the version tag and running `make reproducible-prestate`.

  *   There are two ways to specify the prestate to use:
      *   `--cannon-prestate`: specifies a path to a single Cannon pre-state Json file
      *   `--cannon-prestates-url`: specifies a URL to load pre-states from. This enables participating in games that use different prestates, for example due to a network upgrade. The prestates are stored in this directory named by their hash.
  *   Example final URL for a prestate:
      *   [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json)
@@ -597,7 +597,6 @@
 
 *   Provides visibility into all game statuses for the last 28 days
 *   Essential for production challenger deployments
-*   Create Grafana dashboards using: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json)
 
 ## Next steps
 

@@ -8,7 +8,7 @@
  These features may experience stability issues, and we encourage feedback from our early users.
 </Info>

 This guide provides a walkthrough for chain operators who want to run an Alt-DA Mode chain. See the [Alt-DA Mode Explainer](/op-stack/features/experimental/alt-da-mode) for a general overview of this OP Stack configuration.
 An Alt-DA Mode OP Stack chain enables a chain operator to post and read data to any alternative data availability layer that has built a functioning OP Stack DA Server.

 <Info>
@@ -81,7 +81,7 @@
   <Step title="Set your fee configuration">
   *   Chain operators are not posting everything to Ethereum, just commitments, so chain operators will need to determine fee scalars values to charge users. The fee scalar values are network throughput dependent, so values will need to be adjusted by chain operators as needed.
     *   Cost structure for Alt-DA Mode: The transaction data is split up into 128kb chunks and then submitted to your DA Layer. Then, 32 byte commitments are submitted (goes to batch inbox address) to L1 for each 128kb chunk. Then, figure out how much that costs relative to the number of transactions your chain is putting through.
-    *   Set scalar values inside the deploy config. The example below shows some possible fee scalar values, calculated assuming negligible DA Layer costs, but will need to be adjusted up or down based on network throughput - as a reminder of how to set your scalar values, see [this section](/operators/chain-operators/management/blobs#update-your-scalar-values-for-blobs) of the docs.
+    *   Set scalar values inside the deploy config. The example below shows some possible fee scalar values, calculated assuming negligible DA Layer costs, but will need to be adjusted up or down based on network throughput - as a reminder of how to set your scalar values, see [this section](/chain-operators/guides/features/blobs#update-your-scalar-values-for-blobs) of the docs.
 
         ```
         // Set in Deploy Config
@@ -104,7 +104,7 @@

 Alt DA teams who want to be featured on this page must meet the following criteria:

 *   Functional [DA Server](https://specs.optimism.io/experimental/alt-da.html#da-server?utm_source=op-docs&utm_medium=docs), maintained in your own repo
 *   Supporting detailed documentation, to be referenced [here](#setup-your-da-server)
 *   Functioning OP Stack devnet using your DA server with linked configuration, contract addresses, and RPC address

@@ -166,7 +166,7 @@

 Update the following CLI parameters for both `op-node` and `op-batcher`:

 | Former CLI param          | Current CLI param        |
 | ------------------------- | ------------------------ |
 | `--plasma.enabled`        | `--altda.enabled`        |
 | `--plasma.da-server`      | `--altda.da-server`      |
@@ -177,7 +177,7 @@

 #### op-node

 | Former env var                  | Current env var                |
 | ------------------------------- | ------------------------------ |
 | `OP_NODE_PLASMA_ENABLED`        | `OP_NODE_ALTDA_ENABLED`        |
 | `OP_NODE_PLASMA_DA_SERVER`      | `OP_NODE_ALTDA_DA_SERVER`      |
@@ -186,7 +186,7 @@

 #### op-batcher

 | Former env var                     | Current env var                   |
 | ---------------------------------- | --------------------------------- |
 | `OP_BATCHER_PLASMA_ENABLED`        | `OP_BATCHER_ALTDA_ENABLED`        |
 | `OP_BATCHER_PLASMA_DA_SERVER`      | `OP_BATCHER_ALTDA_DA_SERVER`      |
@@ -195,7 +195,7 @@

 #### op-alt-da (formerly op-plasma) daserver

 | Former env var                             | Current env var                        |
 | ------------------------------------------ | -------------------------------------- |
 | `OP_PLASMA_DA_SERVER_ADDR`                 | `OP_ALTDA_SERVER_ADDR`                 |
 | `OP_PLASMA_DA_SERVER_PORT`                 | `OP_ALTDA_SERVER_PORT`                 |

@@ -10,7 +10,7 @@ Snap sync works by downloading a snapshot of the state from other nodes on the n
 This means that performing a snap sync is significantly faster than performing a full sync.
 
 *   Snap sync enables node operators on your network to sync faster.
-*   Snap sync removes the need for nodes on your post Ecotone network to run a [blob archiver](/operators/node-operators/management/blobs).
+*   Snap sync removes the need for nodes on your post Ecotone network to run a [blob archiver](/node-operators/guides/management/blobs).
 
 ## Enable snap sync for chains
 

@@ -29,7 +29,7 @@
 *   Global Events Monitor: made for taking YAML rules as configuration and monitoring the events that are emitted on the chain.
 *   Liveness Expiration Monitor: monitors the liveness expiration on Safes.
 *   Balances Monitor: emits a metric reporting the balances for the configured accounts.
 *   Multisig Monitor: The multisig monitor reports the paused status of the OptimismPortal contract. If set, reports the latest nonce of the configured Safe address and the latest presigned nonce stored in One Password.. The latest presigned nonce is identified by looking for items in the configured vault that follow a `ready-<nonce>.json` name. The highest nonce of this item name format is reported.
 *   Drippie Monitor: tracks the execution and executability of drips within a Drippie contract.
 *   Secrets Monitor: takes a Drippie contract as a parameter and monitors for any drips within that contract that use the `CheckSecrets` dripcheck contract. `CheckSecrets` is a dripcheck that allows a drip to begin once a specific secret has been revealed (after a delay period) and cancels the drip if a second secret is revealed. Monitoring these secrets is important, as their revelation may indicate that the secret storage platform has been compromised and someone is attempting to exfiltrate the ETH controlled by the drip.

@@ -66,8 +66,6 @@
 
 You can find more info on `op-dispute-mon` on [the repo](https://github.com/ethereum-optimism/optimism/tree/develop/op-dispute-mon).
 
-Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/public/resources/grafana/dispute-monitor-1718214549035.json).
-
 ## Offchain component monitoring
 
 Offchain monitoring allows chain operators to monitor the operation and behavior of nodes and other offchain components. Some of the more common components that you'll likely want to monitor include `op-node`, `op-geth`, `op-proposer`, `op-batcher`, and `op-challenger`.

@@ -545,7 +545,6 @@ Consider running [`op-dispute-mon`](/operators/chain-operators/tools/chain-monit
 
 *   Provides visibility into all game statuses for the last 28 days
 *   Essential for production challenger deployments
-*   Create Grafana dashboards using: [Download the Dispute Monitor JSON](/public/resources/grafana/dispute-monitor-1718214549035.json)
 
 ## Congratulations
 

@@ -541,10 +541,6 @@
       "source": "/app-developers/testing-apps",
       "destination": "/app-developers/guides/testing-apps"
     },
-    {
-      "source": "/app-developers/tools",
-      "destination": "/app-developers/tools"
-    },
     {
       "source": "/app-developers/tools/build",
       "destination": "/app-developers/build"
@@ -915,7 +911,7 @@
     },
     {
       "source": "/notices/superchain-withdrawal-pause-test",
-      "destination": "/notices/superchain-withdrawal-pause-test"
+      "destination": "/notices/archive/superchain-withdrawal-pause-test"
     },
     {
       "source": "/notices/upgrade-13",
@@ -1744,6 +1740,14 @@
     {
       "source": "/chain-operators/tools/op-challenger",
       "destination": "chain-operators/guides/configuration/op-challenger-config-guide"
+    },
+    {
+      "source": "/app-developers/tools/data-and-dashboards/overview",
+      "destination": "/app-developers/tools/data/data-and-dashboards"
+    },
+    {
+      "source": "app-developers/tools/data-and-dashboards/data-glossary",
+      "destination": "/app-developers/tools/data/data-glossary"
     }
   ],
   "navigation": {