Corrected grammar, punctuation, and formatting inconsistencies.

README.md

@@ -32,7 +32,7 @@ This command generates static content into the `build` directory and can be serv
 
 ### Deployment
 
-This repo is configured with Github Actions to deploy the built site to github pages. Committing or merging to master will update the production documentation site.
+This repo is configured with GitHub Actions to deploy the built site to GitHub pages. Committing or merging to master will update the production documentation site.
 
 ### Versioning
 

docusaurus.config.js

@@ -359,8 +359,7 @@ const config = {
         },
         items: [
           {
-            type: "doc",
-            docId: "learn/intro/obol-collective",
+            type: "docsVersionDropdown",
             position: "left",
             label: "Docs",
           },

versioned_docs/version-v0.18.0/cg/docs.md

@@ -1,6 +1,6 @@
 # Documentation standards
 
-This section outlines the formatting standards presented within this documentation. In order to maintain continuity and quality, all pull requests must best conform to the specifics below.
+This section outlines the formatting standards presented within this documentation. In order to maintain continuity and quality, all pull requests must conform to the specifics below.
 
 ## Content types
 
@@ -26,7 +26,7 @@ If a walkthrough is converted into a video, that video should be no longer than
 
 #### Walkthrough structure
 
-Walkthroughs are split into three major sections:
+Walkthroughs are split into four major sections:
 
 1. Context to the topics covered.
 2. What we're about to do.
@@ -82,7 +82,7 @@ Follow each list of three or more items with a comma `,`:
 
 ### Acronyms
 
-If you have to use an acronym, spell the full phrase first and include the acronym in parentheses `()` the first time it is used in each document. Exception: This generally isn't necessary for commonly-encountered acronyms like _EVM_, unless writing for a stand-alone article that may not be presented alongside project documentation.
+If you have to use an acronym, spell the full phrase first and include the acronym in parentheses `()` the first time it is used in each document. Exception: This is generally unnecessary for common acronyms like _EVM_, unless writing for a stand-alone article that may not be presented alongside project documentation.
 
 > Virtual Machine (VM), Decentralized Web (DWeb).
 

versioned_docs/version-v0.18.0/charon/cluster-configuration.md

@@ -83,7 +83,7 @@ The `cluster-lock.json` has the following schema:
 
 ```json
 {
-  "cluster_definition": {...},                              // Cluster definiition json, identical schema to above,
+  "cluster_definition": {...},                              // Cluster definition json, identical schema to above,
   "distributed_validators": [                               // Length equal to cluster_definition.num_validators.
     {
       "distributed_public_key":  "0x123..abfc",             // DV root pubkey
@@ -98,7 +98,7 @@ The `cluster-lock.json` has the following schema:
 
 ## Cluster Size and Resilience
 
-The cluster size (the number of nodes/operators in the cluster) determines the resilience of the cluster; its ability remain operational under diverse failure scenarios.
+The cluster size (the number of nodes/operators in the cluster) determines the resilience of the cluster; it's to ability remain operational under diverse failure scenarios.
 Larger clusters can tolerate more faulty nodes.
 However, increased cluster size implies higher operational costs and potential network latency, which may negatively affect performance
 

versioned_docs/version-v0.18.0/dvl/intro.md

@@ -9,10 +9,10 @@ sidebar_position: 1
 
 In order to activate an Ethereum validator, 32 ETH must be deposited into the official deposit contract. 
 
-The vast majority of users that created validators to date have used the **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, a public good open source website built by the Ethereum Foundation alongside participants that later went on to found Obol. This tool has been wildly successful in the safe and educational creation of a significant number of validators on the Ethereum mainnet.
+The vast majority of users who created validators to date have used the **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, a public good open source website built by the Ethereum Foundation alongside participants that later went on to found Obol. This tool has been wildly successful in the safe and educational creation of a significant number of validators on the Ethereum mainnet.
 
 To facilitate the generation of distributed validator keys amongst remote users with high trust, the Obol Network developed and maintains a website that enables a group of users to come together and create these threshold keys: [**The DV Launchpad**](https://goerli.launchpad.obol.tech/).
 
 ## Getting started
 
-For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). 
+For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). 

versioned_docs/version-v0.18.0/fr/eth.md

@@ -1,10 +1,10 @@
 # Ethereum and its Relationship with DVT
 
-Our goal for this page is to equip you with the foundational knowledge needed to actively contribute to the advancement of Obol while also directing you to valuable Ethereum and DVT related resources. Additionally, we will shed light on the intersection of DVT and Ethereum, offering curated articles and blog posts to enhance your understanding.
+Our goal on this page is to provide you with foundational knowledge to actively contribute to Obol’s advancement while also directing you to valuable Ethereum and DVT-related resources. Additionally, we explore the intersection of DVT and Ethereum, offering curated articles and blog posts to deepen your understanding.
 
 ## **Understanding Ethereum**
 
-To grasp the current landscape of Ethereum's PoS development, we encourage you to delve into the wealth of information available on the [Official Ethereum Website.](https://ethereum.org/en/learn/)
+To understand Ethereum’s current PoS landscape, we encourage you to explore the wealth of information available on the [Official Ethereum Website.](https://ethereum.org/en/learn/)
 The Ethereum website serves as a hub for all things Ethereum, catering to individuals at various levels of expertise, whether you're just starting your journey or are an Ethereum veteran. Here, you'll find a trove of resources that cater to diverse learning needs and preferences, ensuring that there's something valuable for everyone in the Ethereum community to discover.
 
 ## **DVT & Ethereum**
@@ -22,12 +22,12 @@ If you haven’t yet heard, Distributed Validator Technology, or DVT, is the nex
 ***Vitalik's Ethereum Roadmap***
 
 ### Deep Dive Into DVT and Charon’s Architecture
-Minimizing correlation is vital when designing DVT as Ethereum Proof of Stake is designed to heavily punish correlated behavior. In designing Obol, we’ve made careful choices to create a trust-minimized and non-correlated architecture. 
+Minimizing correlation is crucial in DVT design, as Ethereum’s Proof of Stake heavily penalizes correlated behavior. In designing Obol, we’ve made careful choices to create a trust-minimized and non-correlated architecture. 
 
 [**Read more about Designing Non-Correlation Here**](https://blog.obol.tech/deep-dive-into-dvt-and-charons-architecture/)
 
 ### Performance Testing Distributed Validators
-In our mission to help make Ethereum consensus more resilient and decentralised with distributed validators (DVs), it’s critical that we do not compromise on the performance and effectiveness of validators. Earlier this year, we worked with MigaLabs, the blockchain ecosystem observatory located in Barcelona, to perform an independent test to validate the performance of Obol DVs under different configurations and conditions. After taking a few weeks to fully analyse the results together with MigaLabs, we’re happy to share the results of these performance tests. 
+In our mission to help make Ethereum consensus more resilient and decentralised with distributed validators (DVs), it’s critical that we do not compromise on the performance and effectiveness of validators. Earlier this year, we collaborated with MigaLabs, a blockchain ecosystem observatory in Barcelona, to conduct an independent performance test on Obol DVs under various configurations and conditions. After taking a few weeks to fully analyse the results together with MigaLabs, we’re happy to share the results of these performance tests. 
 
 [**Read More About The Performance Test Results Here**](https://blog.obol.tech/performance-testing-distributed-validators/)
 
@@ -41,4 +41,4 @@ In our mission to help make Ethereum consensus more resilient and decentralised
 
 
 #### References
-- ethereum.org. (2023). Distributed Validator Technology. [online] Available at: https://ethereum.org/en/staking/dvt/ [Accessed 25 Sep. 2023].
+- ethereum.org. (2023). Distributed Validator Technology. [online] Available at: https://ethereum.org/en/staking/dvt/ [Accessed 25 Sep. 2023].

versioned_docs/version-v0.18.0/int/Overview.md

@@ -5,11 +5,11 @@ description: An overview of the Obol network
 
 ## The Network
 
-The network can be best visualized as a work layer that sits directly on top of base layer consensus. This work layer is designed to provide the base layer with more resiliency and promote decentralization as it scales. As Ethereum matures over the coming years, the community will move onto the next great scaling challenge, which is stake centralization. To effectively mitigate these risks, community building and credible neutrality must be used as primary design principles. 
+The network can be best visualized as a work layer that sits directly on top of base layer consensus. This work layer is designed to provide the base layer with more resiliency and promote decentralization as it scales. As Ethereum matures over the coming years, the community will move onto the next great scaling challenge, which is the centralization of stake. To effectively mitigate these risks, community building and credible neutrality must be used as primary design principles. 
 
-Obol is focused on scaling consensus by providing permissionless access to Distributed Validators (DV's). We believe that distributed validators will and should make up a large portion of mainnet validator configurations. In preparation for the first wave of adoption, the network currently utilizes a middleware implementation of Distributed Validator Technology (DVT), to enable the operation of distributed validator clusters that can preserve validators current client and remote signing infrastructure.
+Obol is focused on scaling consensus by providing permissionless access to Distributed Validators (DV's). We believe that distributed validators will and should make up a large portion of mainnet validator configurations. In preparation for the first wave of adoption, the network currently utilizes a middleware implementation of Distributed Validator Technology (DVT), to enable the operation of distributed validator clusters that can preserve validators' current client and remote signing infrastructure.
 
-Similar to how roll-up technology laid the foundation for L2 scaling implementations, we believe DVT will do the same for scaling consensus while preserving decentralization. Staking infrastructure is entering its protocol phase of evolution, which must include trust-minimized staking networks that can be plugged into at scale. Layers like Obol are critical to the long term viability and resiliency of public networks, especially networks like Ethereum. We believe DVT will evolve into a widely used primitive and will ensure the security, resiliency, and decentralization of the public blockchain networks that adopt it.
+Similar to how roll-up technology laid the foundation for L2 scaling implementations, we believe DVT will do the same for scaling consensus while preserving decentralization. Staking infrastructure is entering the protocol phase of its evolution, which must include trust-minimized staking networks that can be plugged into at scale. Layers like Obol are critical to the long term viability and resiliency of public networks, especially networks like Ethereum. We believe DVT will evolve into a widely used primitive and will ensure the security, resiliency, and decentralization of the public blockchain networks that adopt it.
 
 The Obol Network consists of four core public goods:
 
@@ -34,7 +34,7 @@ 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 counterparty operators if there is an issue with your shared cluster. 
 
-A DV without in-band dispute resolution/incentivization 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 or incentivization 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.
 
 Obol V1 will utilize retroactive public goods principles to lay the foundation of its economic ecosystem. The Obol Community will responsibly allocate the collected ETH as grants to projects in the staking ecosystem for the entirety of V1.
 
@@ -44,4 +44,4 @@ V1 of charon serves a small by count, large by stake-weight group of individuals
 
 Version 2 of charon will layer in an incentivization scheme to ensure any operator not online and taking part in validation is not earning any rewards. Further incentivization alignment can be achieved with operator bonding requirements that can be slashed for unacceptable performance. 
 
-To add an un-gameable incentivization 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. 
+Adding an un-gameable incentivization layer to threshold validation requires complex interactive cryptographic schemes, secure off-chain dispute resolution, and EVM support for consensus layer state proofs. As a result, this will be a longer and more complex undertaking than V1, hence the distinction between the two.

versioned_docs/version-v0.18.0/int/key-concepts.md

@@ -19,7 +19,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 relay service 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.
 
@@ -39,7 +39,7 @@ Examples of execution clients include:
 
 ![A Geth Client](/img/POSClient.png)
 
-A consensus client's duty is to run the proof of stake consensus layer of Ethereum, often referred to as the beacon chain.
+A consensus client is responsible for running Ethereum’s proof-of-stake consensus layer, also known as the beacon chain.
 
 Examples of Consensus clients include:
 
@@ -64,7 +64,7 @@ The only example of a distributed validator client built with a non-custodial mi
 
 ![A Lighthouse Client](/img/ValidatorBrick.png)
 
-A validator client is a piece of code that operates one or more Ethereum validators.
+A validator client is software that operates one or more Ethereum validators.
 
 Examples of validator clients include:
 
@@ -105,6 +105,6 @@ The number of nodes in a cluster that needs to be online and honest for their di
 
 ### Distributed Validator Key Generation Ceremony
 
-To achieve fault tolerance in a distributed validator, the individual private key shares need to be generated together. Rather than have a trusted dealer produce a private key, split it and distribute it, the preferred approach is to never construct the full private key at any point, by having each operator in the distributed validator cluster participate in what is known as a Distributed Key Generation ceremony. 
+To achieve fault tolerance in a distributed validator, the individual private key shares need to be generated together. Rather than have a trusted dealer produce a private key, split it and distribute it, the preferred approach is to avoid constructing the full private key at any point by having each operator in the distributed validator cluster participate in a Distributed Key Generation (DKG) ceremony.
 
 A distributed validator key generation ceremony is a type of DKG ceremony. A ceremony produces signed validator deposit and exit data, along with all of the validator key shares and their associated metadata. Read more about these ceremonies [here](../charon/dkg). 

versioned_docs/version-v0.18.0/intro.md

@@ -7,13 +7,13 @@ description: Welcome to the Multi-Operator Validator Network
 
 ## What is Obol?
 
-Obol Labs is a research and software development team focused on proof-of-stake infrastructure for public blockchain networks. Specific topics of focus are Internet Bonds, Distributed Validator Technology and Multi-Operator Validation. The team currently includes 20 members that are spread across the world.
+Obol Labs is a research and software development team focused on proof-of-stake infrastructure for public blockchain networks. Specific areas of focus include Internet Bonds, Distributed Validator Technology, and Multi-Operator Validation. The team currently consists of 20 members distributed across the world.
 
 The core team is building the Obol Network, a protocol to foster trust minimized staking through multi-operator validation. This will enable low-trust access to Ethereum staking yield, which can be used as a core building block in a variety of Web3 products.
 
 ## About this documentation
 
-This manual is aimed at developers and stakers looking to utilize the Obol Network for multi-party staking. To contribute to this documentation, head over to our [Github repository](https://github.com/ObolNetwork/obol-docs) and file a pull request.
+This manual is aimed at developers and stakers looking to utilize the Obol Network for multi-party staking. To contribute to this documentation, head over to our [Github repository](https://github.com/ObolNetwork/obol-docs) and submit a pull request.
 
 ## Need assistance?