Fix typos and improve grammar in documentation

docs/adv/security/bug-bounty.md

@@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int
 Impacts:
 
 - Attacker that is a member of a cluster can exfiltrate K1 key material from another member.
-- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s)
+- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s)
 - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities.
 - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad.
 - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours
@@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob
 - Any testing with pricing oracles or third-party smart contracts
 - Attempting phishing or other social engineering attacks against our employees and/or customers
 - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
-- Any denial of service attacks that are executed against project assets
+- Any denial-of-service attacks that are executed against project assets
 - Automated testing of services that generate significant amounts of traffic
 - Public disclosure of an unpatched vulnerability in an embargoed bounty
 

docs/adv/security/ev-assessment.md

@@ -102,7 +102,7 @@ These final steps are potentially the most difficult, and may require significan
 
 From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad.
 
-What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
+What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
 
 If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are:
 
@@ -199,7 +199,7 @@ This is not likely to be particularly motivating to potential attackers - and pa
 
 During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed).
 
-Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
+Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
 
 - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts.
 - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example:

docs/learn/intro/obol-splits.mdx

@@ -51,7 +51,7 @@ This contract **assumes that any ether that has appeared in its address since it
 
 Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you fully understand and accept this risk**.
 
-The alternative is to use an splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards.
+The alternative is to use a splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards.
 
 :::
 

docs/learn/intro/staking-stack.md

@@ -24,10 +24,10 @@ The road to decentralizing stake is a long one. At Obol we have divided our visi
 
 The first version of distributed validators will have dispute resolution out of band. Meaning you need to know and communicate with your other operators if there is an issue with your shared cluster.
 
-A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service providers can deploy DVs on their own to make their validators fault tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group.
+A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service providers can deploy DVs on their own to make their validators fault-tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group.
 
 ### V2 - Trustless Distributed Validators
 
 As described in our [roadmap blog article](https://blog.obol.org/roadmap-the-distributed-validator-protocol/) published in February 2024, Version 2 of Charon will layer in a (dis)incentivisation scheme to solve the “lazy operator” problem, whereby an offline operator within a DV cluster does not earn any rewards. Further incentivisation alignment can be achieved with operator bonding requirements that can be slashed for unacceptable performance.
 
-To add an un-gameable incentivisation layer to threshold validation requires complex interactive cryptography schemes, secure off-chain dispute resolution, and EVM support for proofs of the consensus layer state, as a result, this will be a longer and more complex undertaking than V1, hence the delineation between the two. Some of the published R&D material is available in the [further reading](https://docs.obol.org/next/fr/resources#research-and-development) section of the docs.
+To add an un-gameable incentivisation layer to threshold validation requires complex interactive cryptography schemes, secure off-chain dispute resolution, and EVM support for proofs of the consensus layer state, as a result, this will be a longer and more complex undertaking than V1, hence the delineation between the two. Some of the published R&D material is available in the [further reading](https://docs.obol.org/next/fr/resources#research-and-development) section of the docs.

versioned_docs/version-v0.17.1/sec/ev-assessment.md

@@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan
 
 From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad.
 
-What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
+What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
 
 If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are:
 
@@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa
 
 During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed).
 
-Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
+Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
 
 - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts.
 - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example:

versioned_docs/version-v0.18.0/sec/ev-assessment.md

@@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan
 
 From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad.
 
-What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
+What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
 
 If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are:
 
@@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa
 
 During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed).
 
-Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
+Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
 
 - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts.
 - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example:

versioned_docs/version-v0.19.0/sec/ev-assessment.md

@@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan
 
 From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad.
 
-What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
+What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
 
 If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are:
 
@@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa
 
 During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed).
 
-Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
+Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
 
 - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts.
 - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example:

versioned_docs/version-v0.19.1/sec/ev-assessment.md

@@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan
 
 From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad.
 
-What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
+What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on.
 
 If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are:
 
@@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa
 
 During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed).
 
-Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
+Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both:
 
 - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts.
 - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example:

versioned_docs/version-v0.19.2/sec/bug-bounty.md

@@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int
 Impacts:
 
 - Attacker that is a member of a cluster can exfiltrate K1 key material from another member.
-- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s)
+- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s)
 - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities.
 - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad.
 - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours
@@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob
 - Any testing with pricing oracles or third-party smart contracts
 - Attempting phishing or other social engineering attacks against our employees and/or customers
 - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
-- Any denial of service attacks that are executed against project assets
+- Any denial-of-service attacks that are executed against project assets
 - Automated testing of services that generates significant amounts of traffic
 - Public disclosure of an unpatched vulnerability in an embargoed bounty