Fix typos and grammatical errors in chain-operators/reference documentation

chain-operators/reference/architecture.mdx

@@ -125,7 +125,7 @@ GETH_DB_ENGINE: "pebble"
 GETH_STATE_SCHEME: "hash"
 ```
 
-*   You can also use these nodes taking disk snapshots for disaster recovery.
+*   You can also use these nodes for taking disk snapshots for disaster recovery.
 
 ### Full Snapsync Nodes
 

chain-operators/reference/features/alt-da-mode.mdx

@@ -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](/stack/beta-features/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>
@@ -59,7 +59,7 @@
 
   <Step title="Configure your batcher">
   *   Set `--altda.enabled=true` and `--altda.da-service=true`.
-    *   Provide the URL for `--atlda.da-server=$DA_SERVER_HTTP_URL`.
+    *   Provide the URL for `--altda.da-server=$DA_SERVER_HTTP_URL`.
 
     ```
         --altda.da-server value                                               ($OP_BATCHER_ALTDA_DA_SERVER)
@@ -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`                 |

chain-operators/reference/features/preinstalls.mdx

@@ -3,7 +3,7 @@ title: OP Stack preinstalls
 description: Learn how to use preinstalls on your chain.
 ---
 
-This guide explains OP Stack preinstalls and what it brings to developers.
+This guide explains OP Stack preinstalls and what they bring to developers.
 To go to production on a new chain, developers need their core contracts: Gnosis Safes, the 4337 entrypoint, create2deployer, etc. On a blank EVM, these contracts can take weeks to be deployed. Now, core contracts come *preinstalled* on the OP Stack -- no third party deployment necessary.
 Whether hacking alone or starting the next big rollup, developers can start using their favorite contracts as soon as they spin up their chain.
 

chain-operators/reference/opcm.mdx

@@ -1,6 +1,6 @@
 ---
 title: OP Contracts Manager
-description: Learn how OP Contracts Manager deploys of the OP Stack with one transaction.
+description: Learn how OP Contracts Manager deploys the OP Stack with one transaction.
 ---
 
 The OP Contracts Manager is a contract that deploys the L1 contracts for an OP Stack chain in a single transaction. It provides a minimal set of user-configurable parameters to ensure that the resulting chain meets the standard configuration requirements. Additionally, as of [Upgrade 13](https://gov.optimism.io/t/upgrade-proposal-13-opcm-and-incident-response-improvements/9739), instances of OPCM can upgrade existing OP Stack chains.

chain-operators/reference/superchain-registry.mdx

@@ -30,4 +30,4 @@ All Superchain Ecosystem members are welcome to join the Superchain Registry, re
 After being included into the Superchain Registry, subsequent releases of the `op-node` and `op-geth` will contain the chain's genesis and rollup configurations baked in. You can use then use the `--network` (`op-node`) and `--op-network` (`op-geth`) flags to start up your node with this information. Using these flags means that the node will automatically inherit the hard fork activation times from the Superchain Registry, so you don't need to manually set them in your node configuration. 
 
 Additionally, chains can opt into the hard fork activation inheritance behavior by specifying the `superchain_time` in the chain's TOML file to start inheriting Superchain wide activation timestamps. 
-Networks who have utilize this mechanism will activate network hard forks specified in the `superchain.toml` files: [Sepolia superchain.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/sepolia/superchain.toml) and [Mainnet superchain.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml).
+Networks that utilize this mechanism will activate network hard forks specified in the `superchain.toml` files: [Sepolia superchain.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/sepolia/superchain.toml) and [Mainnet superchain.toml](https://github.com/ethereum-optimism/superchain-registry/blob/main/superchain/configs/mainnet/superchain.toml).

chain-operators/reference/superchain-upgrades.mdx

@@ -22,7 +22,7 @@ This contract is instrumental in managing and tracking the progression of protoc
 
 **[Superchain version signaling](https://specs.optimism.io/protocol/superchain-upgrades.html?utm_source=op-docs&utm_medium=docs#superchain-version-signaling)** is a mechanism that allows nodes and clients to be aware of and prepare for upcoming protocol changes.
 This signaling is achieved through the **ProtocolVersion smart contract**, allowing chains to indicate their readiness for upcoming upgrades and ensuring that all participating chains are synchronized. 
-If the node see's a versioning signal onchain before the node software has been updated for a hardfork, the node will [halt](/superchain/superchain-upgrades#rolluphalt-flags-on-node-binaries) to prevent chain divergence
+If the node sees a versioning signal onchain before the node software has been updated for a hardfork, the node will [halt](/superchain/superchain-upgrades#rolluphalt-flags-on-node-binaries) to prevent chain divergence
 Through this signaling:
 *   Nodes can anticipate and implement necessary adjustments ahead of time.
 *   Clients are informed about the protocol version they should be compatible with, ensuring seamless interactions across the Superchain.