Update docs: fix typos

versioned_docs/version-v1.1.2/advanced/lido-csm.md

@@ -60,7 +60,7 @@ Select `Split` for the contract type.
 
 ![Selecting Split Contract](/img/CSM_walkthrough6.png)
 
-Add the reward addresses of all cluster members. Choose whether the contract is immutable (reccommended option), whether to sponsor the maintainers of [splits.org](https://splits.org), and optionally whether to set a distribution bounty such that third parties could pay the gas costs of distributing the accrued rewards in exchange for a small fee.
+Add the reward addresses of all cluster members. Choose whether the contract is immutable (recommended option), whether to sponsor the maintainers of [splits.org](https://splits.org), and optionally whether to set a distribution bounty such that third parties could pay the gas costs of distributing the accrued rewards in exchange for a small fee.
 
 :::tip
 If your cluster would like to contribute a portion of its rewards to Obol’s '[1% for Decentralisation](https://blog.obol.org/1-percent-for-decentralisation/)' Retroactive Fund, thereby earning [Obol Contributions](https://obol.org/contributions) as part of Lido's [integration of CSM](https://research.lido.fi/t/integrate-csm-into-the-decentralized-validator-vault/8621) into the  DV Vault, you must add [retroactivefunding.obol.eth](https://etherscan.io/address/0xDe5aE4De36c966747Ea7DF13BD9589642e2B1D0d) as a recipient of 0.1% of the splitter contract. This will contribute 0.1% of rewards **and your CSM bond** to Obol's RAF. Future versions of CSM integrations will enable contributing exactly 1% of accruing CSM rewards.

versioned_docs/version-v1.1.2/advanced/monitoring.md

@@ -24,7 +24,7 @@ The local Grafana server will have a few pre-built dashboards:
 
 | Alert Name | Description | Troubleshoot |
 | --- | --- | --- |
-| ClusterBeaconNodeDown | This alert is activated when the beacon node in a the cluster is offline. The beacon node is crucial for validating transactions and producing new blocks. Its unavailability could disrupt the overall functionality of the cluster. | Most likely data is corrupted. Wipe data from the point you know data was corrupted and restart beacon node so it can be synced again. |
+| ClusterBeaconNodeDown | This alert is activated when the beacon node in the cluster is offline. The beacon node is crucial for validating transactions and producing new blocks. Its unavailability could disrupt the overall functionality of the cluster. | Most likely data is corrupted. Wipe data from the point you know data was corrupted and restart beacon node so it can be synced again. |
 | ClusterMissedAttestations | This alert indicates that there have been missed attestations in the cluster. Missed attestations may suggest that validators are not operating correctly, compromising the security and efficiency of the cluster. | This alert is triggered when 3 attestations are missed in 2 minutes. Check if the minimum threshold of peers are online. If correct, check for beacon node API errors and downstream validator errors using Loki. Lastly, debug from Docker using `docker compose debug`. |
 | ClusterInUnknownStatus | This alert is designed to activate when a node within the cluster is detected to be in an unknown state. The condition is evaluated by checking whether the maximum of the `app_monitoring_readyz` metric is 0. | This is most likely a bug in Charon. Report to us via [Discord](https://discord.com/channels/849256203614945310/970759460693901362). |
 | ClusterInsufficientPeers | This alert is set to activate when the number of peers for a node in the cluster is insufficient. The condition is evaluated by checking whether the maximum of the `app_monitoring_readyz` equals 4. | If you are running group cluster, check with other peers to troubleshoot the issue. If you are running solo cluster, look into other machines running the DVs to find the problem. |

versioned_docs/version-v1.1.2/charon/charon-cli-reference.md

@@ -235,7 +235,7 @@ Flags:
 
 ## The `exit` command
 
-A running Charon client will [aggregate and broadcast](../start/quickstart-exit.mdx) signed exit messages it receives from its valdiator client immediately. These `exit` commands are instead used to *pre-sign* exit messages for an active distributed validator, to save to disk, or to broadcast; once enough of the operators of the cluster have submitted their partial exit signatures. Fully signed exit messages give a user or protocol a guarantee that they can exit an active validator at any point in future without the further assistance of the cluster's operators. In future, [execution-layer initiated exits](https://eips.ethereum.org/EIPS/eip-7002) will provide an even stronger guarantee that a validator can be exited by the withdrawal address it belongs to.
+A running Charon client will [aggregate and broadcast](../start/quickstart-exit.mdx) signed exit messages it receives from its validator client immediately. These `exit` commands are instead used to *pre-sign* exit messages for an active distributed validator, to save to disk, or to broadcast; once enough of the operators of the cluster have submitted their partial exit signatures. Fully signed exit messages give a user or protocol a guarantee that they can exit an active validator at any point in future without the further assistance of the cluster's operators. In future, [execution-layer initiated exits](https://eips.ethereum.org/EIPS/eip-7002) will provide an even stronger guarantee that a validator can be exited by the withdrawal address it belongs to.
 
 ```markdown
 charon exit --help

versioned_docs/version-v1.1.2/faq/errors.mdx

@@ -154,7 +154,7 @@ docker compose logs
       </h4>
     </summary>
     <p>
-      This could be linked to a internet connection being too slow or relying on
+      This could be linked to an internet connection being too slow or relying on
       a slow third-party service such as Infura.
     </p>
   </details>
@@ -263,7 +263,7 @@ docker compose logs
       </h4>
     </summary>
     <code>Error opening relay circuit NO_RESERVATION (204)</code> indicates the peer
-    isn't connected to the relay, so the the Charon client cannot connect to the
+    isn't connected to the relay, so the Charon client cannot connect to the
     peer via the relay. That might be because the peer is offline or the peer is
     configured to connect to a different relay.
     <br />
@@ -482,7 +482,7 @@ docker compose logs
       </li>
       <li>
         Bob's private key share(s) are imported to a VC that is connected to
-        Alice's Charon node. This is a invalid setup/deployment. Alice's Charon
+        Alice's Charon node. This is an invalid setup/deployment. Alice's Charon
         node should only be connected to Alice's VC.
       </li>
       <li>

versioned_docs/version-v1.1.2/faq/peer_score.md

@@ -7,7 +7,7 @@ description: Measuring Individual Performance in Distributed Validators
 
 ## Introduction
 
-Validator effectiveness is a critical metric for assessing the health of a rated network. It determines how well validators perform their attestation and block proposal duties. Existing solutions, like RAVER (Rated Validator Effectiveness Rating), provide a effectiveness score of a validator. In a monolithic validator that is run by a single operator, validator effectiveness can be considered as a proxy for the effectiveness or “score” of that operator. However, this approach falls short when dealing with distributed validators (DVs) maintained by multiple operators.
+Validator effectiveness is a critical metric for assessing the health of a rated network. It determines how well validators perform their attestation and block proposal duties. Existing solutions, like RAVER (Rated Validator Effectiveness Rating), provide an effectiveness score of a validator. In a monolithic validator that is run by a single operator, validator effectiveness can be considered as a proxy for the effectiveness or “score” of that operator. However, this approach falls short when dealing with distributed validators (DVs) maintained by multiple operators.
 
 Peer Score v0 addresses this limitation by introducing a method to evaluate the performance of individual operators within a DV. This enables a more granular assessment of contribution within a distributed setting.
 
@@ -42,6 +42,6 @@ Peer Score v0 lays the foundation for a more comprehensive evaluation system. Pl
 
 Peer Score offers valuable insights for various stakeholders:
 
-- **Staking/Restaking Protocols:** Peer Score is crucial component of Obol’s Techne Credential Program. LSPs and LRPs can utilize Techne Credentials ,and hence Peer Score, to identify efficient operators for expanding their operator sets.
+- **Staking/Restaking Protocols:** Peer Score is a crucial component of Obol’s Techne Credential Program. LSPs and LRPs can utilize Techne Credentials, and hence Peer Score, to identify efficient operators for expanding their operator sets.
 - **DV Operators:** Forming operator collectives based on peer effectiveness and potentially removing underperforming peers from DVs (with Charon v2 cluster mutability).
 - **DV Software Developers:** Establishing a standardized metric for evaluating operator performance across various DV software, enabling the development of new tools and services.

versioned_docs/version-v1.1.2/int/key-concepts.md

@@ -20,7 +20,7 @@ Distributed validator technology removes some of the single points of failure in
 
 ![A Distributed Validator Node](/img/DVNode.png)
 
-A distributed validator node is the set of clients an operator needs to configure and run to fulfil the duties of a Distributed Validator Operator. An operator may also run redundant execution and consensus clients, an execution payload relayer like [mev-boost](https://github.com/flashbots/mev-boost), or other monitoring or telemetry services on the same hardware to ensure optimal performance.
+A distributed validator node is the set of clients an operator needs to configure and run to fulfill the duties of a Distributed Validator Operator. An operator may also run redundant execution and consensus clients, an execution payload relayer like [mev-boost](https://github.com/flashbots/mev-boost), or other monitoring or telemetry services on the same hardware to ensure optimal performance.
 
 In the above example, the stack includes Geth, Lighthouse, Charon and Teku.
 

versioned_docs/version-v1.1.2/sdk/classes/Client.md

@@ -79,7 +79,7 @@ Deploys OWR and Splitter Proxy.
 
 `Promise`\<[`ClusterValidator`](../type-aliases/ClusterValidator.md)\>
 
-owr address as withdrawal address and splitter as fee recipient
+our address as withdrawal address and splitter as fee recipient
 
 An example of how to use createObolRewardsSplit:
 [createObolRewardsSplit](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts#L141)
@@ -105,7 +105,7 @@ Deploys Splitter Proxy.
 
 | Parameter | Type | Description |
 | ------ | ------ | ------ |
-| `totalSplitPayload` | [`TotalSplitPayload`](../type-aliases/TotalSplitPayload.md) | Data needed to deploy splitter if it doesnt exist. |
+| `totalSplitPayload` | [`TotalSplitPayload`](../type-aliases/TotalSplitPayload.md) | Data needed to deploy splitter if it doesn't exist. |
 
 #### Returns
 

versioned_docs/version-v1.1.2/sdk/type-aliases/DepositData.md

@@ -9,7 +9,7 @@ Required deposit data for validator activation
 | `pubkey` | `string` | The public key of the distributed validator. | types.ts:195 |
 | `withdrawal_credentials` | `string` | The 0x01 withdrawal address of the DV. | types.ts:198 |
 | `amount` | `string` | 32 ethers. | types.ts:201 |
-| `deposit_data_root` | `string` | A checksum for DepositData fields . | types.ts:204 |
+| `deposit_data_root` | `string` | A checksum for DepositData fields. | types.ts:204 |
 | `signature` | `string` | BLS signature of the deposit message. | types.ts:207 |
 
 ## Defined in

versioned_docs/version-v1.1.2/sec/ev-assessment.md

@@ -5,7 +5,7 @@ description: Software Development Security Assessment
 
 # Software Development at Obol
 
-When hardening a projects technical security, team member's operational security, and the security of the software development practices in use by the team are some of the most criticial areas to secure. Many hacks and compromises in the space to date have been a result of these attack vectors rather than exploits of the software itself.
+When hardening a projects technical security, team member's operational security, and the security of the software development practices in use by the team are some of the most critical areas to secure. Many hacks and compromises in the space to date have been a result of these attack vectors rather than exploits of the software itself.
 
 With this in mind, in January 2023 the Obol team retained the expertise of Ethereal Venture's security researcher Alex Wade; to interview key stakeholders and produce a report into the teams Software Development Lifecycle.
 

versioned_docs/version-v1.1.2/sec/smart_contract_audit.mdx

@@ -70,7 +70,7 @@ It is assumed that all rewards will flow through the splitter, because (a) all d
 
 This creates a fairly strong guarantee that reward funds will flow to the `rewardRecipient`. Even if a user were to set their `amountOfPrincipalStake` high enough that the `principalRecipient` could receive unlimited funds, the Obol team could call `distributeFunds()` when the balance got near 16 ETH to ensure fees were paid.
 
-However, if the user selects a non-ETH token, all ETH will be withdrawable only thorugh the `recoverFunds()` function. If they set up a split with their node operators as their `recoveryAddress`, all funds will be withdrawable via `recoverFunds()` without ever touching the `rewardRecipient` or paying a fee.
+However, if the user selects a non-ETH token, all ETH will be withdrawable only through the `recoverFunds()` function. If they set up a split with their node operators as their `recoveryAddress`, all funds will be withdrawable via `recoverFunds()` without ever touching the `rewardRecipient` or paying a fee.
 
 #### Recommendation
 
@@ -466,7 +466,7 @@ Here are a select few examples of attacks that a malicious set of node operators
 
 1) Since there is currently no mechanism for withdrawals besides the consensus of the node operators, a minority of them sufficient to withhold consensus could blackmail the principal for a payment of up to 16 ether in order to allow them to withdraw. Otherwise, they could turn off their node operators and force the principal to bleed down to a final withdrawn balance of just over 16 ether.
 
-2) Node operators are all able to propose blocks within the P2P network, which are then propogated out to the rest of the network. Node software is accustomed to signing for blocks built by block builders based on the metadata including quantity of fees and the address they'll be sent to. This is enforced by social consensus, with block builders not wanting to harm validators in order to have their blocks accepted in the future. However, node operators in a DVT are not concerned with the social consensus of the network, and could therefore build blocks that include large MEV payments to their personal address (instead of the DVT's 0xSplit), add fictious metadata to the block header, have their fellow node operators accept the block, and take the MEV for themselves.
+2) Node operators are all able to propose blocks within the P2P network, which are then propagated out to the rest of the network. Node software is accustomed to signing for blocks built by block builders based on the metadata including quantity of fees and the address they'll be sent to. This is enforced by social consensus, with block builders not wanting to harm validators in order to have their blocks accepted in the future. However, node operators in a DVT are not concerned with the social consensus of the network, and could therefore build blocks that include large MEV payments to their personal address (instead of the DVT's 0xSplit), add fictitious metadata to the block header, have their fellow node operators accept the block, and take the MEV for themselves.
 
 3) While the withdrawal address is immutably set on the beacon chain to the OWR, the fee address is added by the nodes to each block. Any majority of node operators sufficient to reach consensus could create a new 0xSplit with only themselves on it, and use that for all execution layer fees. The principal (and other node operators) would not be able to stop them or withdraw their principal, and would be stuck with staked funds paying fees to the malicious node operators.
 

versioned_docs/version-v1.1.2/start/quickstart_alone.mdx

@@ -25,7 +25,7 @@ The private key shares can be created centrally and distributed securely to each
 
 <Tabs groupId="Launchpad-other">
   <TabItem value="Launchpad" label="Launchpad" default>
-    Go to the the <a href="/docs/dvl/intro#dv-launchpad-links">DV Launchpad</a> and select <code>Create a distributed validator alone</code>. Follow the steps to configure your DV cluster. The Launchpad will give you a docker command to create your cluster. <br/>Before you run the command, clone the <a href="https://github.com/ObolNetwork/charon-distributed-validator-cluster.git">CDVC repo</a> and <code>cd</code> into the directory.
+    Go to the <a href="/docs/dvl/intro#dv-launchpad-links">DV Launchpad</a> and select <code>Create a distributed validator alone</code>. Follow the steps to configure your DV cluster. The Launchpad will give you a docker command to create your cluster. <br/>Before you run the command, clone the <a href="https://github.com/ObolNetwork/charon-distributed-validator-cluster.git">CDVC repo</a> and <code>cd</code> into the directory.
 
   ```shell
   # Clone the repo

versioned_docs/version-v1.1.2/start/update.mdx

@@ -44,7 +44,7 @@ docker compose up -d --build
 ```
 
 :::danger
-If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimse liveness and safety risks.
+If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimise liveness and safety risks.
 :::
 
 ### Conflicts