Merge pull request #1055 from 666devs/errors-correction

Corrected rude grammar errors in docs

pages/builders/chain-operators/management/key-management.mdx

@@ -21,7 +21,7 @@ are compromised, the system can be exploited.
 
 It is up to the chain operator to make the decision on how they want to manage
 these keys. One suggestion is to use a Hardware Security Module (HSM) to provide
-a safer environment for key management. Cloud providers often times provide 
+a safer environment for key management. Cloud providers oftentimes provide 
 Key Management Systems (KMS) that can work with your developer operations 
 configurations. This can be used in conjunction with the `eth_signTransaction`
 RPC method.

pages/builders/chain-operators/management/troubleshooting.mdx

@@ -33,7 +33,7 @@ export IMPL_SALT=$(openssl rand -hex 32)
 
 ## Failed to find the L2 Heads to start from
 
-`op-node` fails to execute the derviation process with the following error:
+`op-node` fails to execute the derivation process with the following error:
 
 ```text
 WARN [02-16|21:22:02.868] Derivation process temporary error       attempts=14 err="stage 0 failed resetting: temp: failed to find the L2 Heads to start from: failed to fetch L2 block by hash 0x0000000000000000000000000000000000000000000000000000000000000000: failed to determine block-hash of hash 0x0000000000000000000000000000000000000000000000000000000000000000, could not get payload: not found"

pages/builders/chain-operators/tools/chain-monitoring.mdx

@@ -19,12 +19,12 @@ Onchain monitoring services provide insights into the overall system, helping ch
 
 Monitorism is a tooling suite that supports monitoring and active remediation actions for the OP Stack chain. Monitorism uses monitors as passive security providing automated monitoring for the OP Stack. They are used to monitor the OP stack and alert on specific events that could be a sign of a security incident.
 
-Currently. the list of monitors includes:
+Currently, the list of monitors includes:
 
 Security integrity monitors: These are monitors necessary for making sure Bridges between L2 and L1 are safe and work as expected. These monitors are divided in two subgroups:
 
 *   Pre-Faultproof Chain Monitors:
-    *   Fault Monitor: checks for changes in output roots posted to the L2OutputOracle contract. When a change is detected, it reconstructs the output root from a trusted L2 source and looks for a match..
+    *   Fault Monitor: checks for changes in output roots posted to the L2OutputOracle contract. When a change is detected, it reconstructs the output root from a trusted L2 source and looks for a match.
     *   Withdrawals Monitor: checks for new withdrawals that have been proven to the OptimismPortal contract. Each withdrawal is checked against the `L2ToL1MessagePasser` contract.
 *   Faultproof chain monitors:
     *   Faultproof Withdrawal: The Faultproof Withdrawal component monitors `ProvenWithdrawals` events on the `OptimismPortal` contract and performs checks to detect any violations of invariant conditions on the chain. If a violation is detected, the issue is logged, and a Prometheus metric is set for the event. This component is designed to work exclusively with chains that are already utilizing the Fault Proofs system. This is a new version of the deprecated `chain-mon`,  `faultproof-wd-mon`. For detailed information on how the component works and the algorithms used, please refer to the component README.
@@ -34,7 +34,7 @@ Security monitors: Those tools monitor other aspects of several contracts used i
 *   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.
+*   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.
 
@@ -76,9 +76,9 @@ Chain operators can easily create their grafana dashboard for Dispute Monitor us
 ## 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`.
-The general steps for enabling offchain monitoring is pretty consistent for all the OP components:
+The general steps for enabling offchain monitoring are pretty consistent for all the OP components:
 
-1.  Expose the monitoring port by enabling the `-—metrics.enabled` flag
+1.  Expose the monitoring port by enabling the `--metrics.enabled` flag
 2.  Customize the metrics port and address via the `--metrics.port` and `--metrics.addr` flags, respectively
 3.  Use [Prometheus](https://prometheus.io/) to scrape data from the metrics port
 4.  Save the data in `influxdb`

pages/builders/chain-operators/tools/op-challenger.mdx

@@ -81,12 +81,12 @@ This guide provides a walkthrough of setting up the configuration and monitoring
 
   #### `--rollup-rpc`
 
-  *   This needs to be an`op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details:
+  *   This needs to be an `op-node` archive node because challenger needs access to output roots from back when the games start. See below for important configuration details:
 
   1.  Safe Head Database (SafeDB) Configuration for op-node:
 
       *   The `op-node` behind the `op-conductor` must have the SafeDB enabled to ensure it is not stateless.
-      *   To Enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data.
+      *   To enable SafeDB, set the `--safedb.path` value in your configuration. This specifies the file path used to persist safe head update data.
       *   Example Configuration:
 
           ```
@@ -138,7 +138,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring
       # if you use the wrong one, you will lose the game
       # if you deploy your own contracts, you specify the hash, the root of the json file
       # op mainnet are tagged versions of op-program
-      # make reproducable prestate
+      # make reproducible prestate
       # challenger verifies that onchain
        --cannon-prestate ./op-program/bin/prestate.json \
       # load the game factory address from system config or superchain registry
@@ -164,7 +164,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring
   *   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:
+  *   Example final URL for a prestate:
       *   [https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json](https://example.com/prestates/0x031e3b504740d0b1264e8cf72b6dde0d497184cfb3f98e451c6be8b33bd3f808.json)
       *   This file contains the cannon memory state.
 
@@ -212,7 +212,7 @@ This guide provides a walkthrough of setting up the configuration and monitoring
   | `resolve`       | Resolves the specified dispute game if possible          |
   | `resolve-claim` | Resolves the specified claim if possible                 |
 
-  Additionally, chain operators should consider running `op-dispute-mon`. It's an incredibly useful securities monitoring service to keep an eye on games, basically giving chain operators visibility into all the status of the games for the last 28 days.
+  Additionally, chain operators should consider running `op-dispute-mon`. It's an incredibly useful security monitoring service to keep an eye on games, basically giving chain operators visibility into all the status of the games for the last 28 days.
   Chain operators can easily create their grafana dashboard for Dispute Monitor using the following json file: [Download the Dispute Monitor JSON](/resources/grafana/dispute-monitor-1718214549035.json).
 </Steps>