docs: fix typos

docs/architecture.md

@@ -197,7 +197,7 @@ Multiple `DutyDefinition`s are combined into a single `DutyDefinitionSet` that i
 type DutyDefinitionSet map[PubKey]DutyDefinition
 ```
 
-Note the `DutyRandao`, `DutyExit` & `DutyBuilderRegistration` isn’t scheduled by the scheduler, since they are initiated directly by VC.
+Note the `DutyRandao`, `DutyExit` & `DutyBuilderRegistration` aren’t scheduled by the scheduler, since they are initiated directly by VC.
 
 > ℹ️ The core workflow follows the immutable architecture approach, with immutable self-contained values flowing between components.
 > Values can be thought of as events or messages and components can be thought of as actors consuming and generating events.
@@ -249,7 +249,7 @@ type UnsignedDataSet map[PubKey]UnsignedData
 ```
 `DutyProposer` is however unique per slot, so its `UnsignedDataSet` will only ever contain a single entry.
 
-The unsigned duty data returned by a beacon node for a given slot is however not deterministic. It changes over and time and
+The unsigned duty data returned by a beacon node for a given slot is however not deterministic. It changes over time and
 from beacon node to beacon node. This means that different charon nodes will fetch different input data.
 This is a problem since signing different data for the same duty results in slashing.
 
@@ -279,7 +279,7 @@ This is achieved by playing a consensus game between all nodes in the cluster. T
 
 Consensus is similar to how some blockchains decide on what blocks define the chain. Popular protocols for consensus are raft, qbft, tendermint. Charon uses qbft for consensus.
 
-The consensus requirements in DVT differs from blockchains in a few key aspects:
+The consensus requirements in DVT differ from blockchains in a few key aspects:
 - Blockchains play consecutive consensus games that depend-on and follow-on the previous consensus game. Thereby creating a block “chain”.
 - DVT plays single isolated consensus games.
 - Blockchains play consensus games on blocks containing transactions.
@@ -428,7 +428,7 @@ an aggregated randao reveal signature. Partial randao reveal signatures are subm
 unsigned beacon block is requested. `getDutyFunc` returns the duty data corresponding to the duty provided and can be obtained directly from the `Scheduler`.
 
 Note that the VC is configured with one or more private key shares (output of the DKG).
-The VC infers its public keys from those private shares, but those public keys does not exist on the beacon chain.
+The VC infers its public keys from those private shares, but those public keys do not exist on the beacon chain.
 The validatorapi therefore needs to intercept and map all endpoints containing the validator public key and map
 the public share (what the VC thinks as its public key) to and from the DV root public key.
 

docs/configuration.md

@@ -82,7 +82,7 @@ The `cluster-lock.json` has the following schema:
 ```
 
 `charon run` just requires a `cluster-lock.json` file to configure the cluster. See the [cluster.DepositData](../cluster/deposit.go) and [cluster.BuilderRegistration](../cluster/registration.go) Go structs for more details
-on how the an individual `distributed_validator` looks like.
+on how an individual `distributed_validator` looks like.
 
 ### Cluster Config Change Log
 
@@ -93,7 +93,7 @@ The following is the historical change log of the cluster config:
   - `distributed_validator` structure replaced `deposit_data` with `partial_deposit_data` respectively.
 - `v1.7.0`:
   - Added the `builder_registration` structure to `distributed_validators` list in cluster lock.
-  - This enables distributed validators to submit pre-generated validator registrations that enables MEV-blocks.
+  - This enables distributed validators to submit pre-generated validator registrations that enable MEV-blocks.
   - Added the `node_signatures` list to cluster lock which contains signatures of the lock hash signed by each individual node.
 - `v1.6.0`:
   - Add `deposit_data` structure to `distributed_validators` list in cluster lock.

docs/dkg.md

@@ -44,7 +44,7 @@ This cluster-definition file is created with the help of the [Distributed Valida
   - If the participant connects a wallet that is not in the participant list, the button disables, as there is nothing to do
   - If the participant connects a wallet that is in the participant list, they get prompted to input the ENR of their charon node.
   - If the ENR field is populated and validated the participant can now see a "Confirm Cluster Configuration" button. This button triggers one/two signatures.
-    - The participant signs the `config_hash`, to prove they are consensting to this exact configuration.
+    - The participant signs the `config_hash`, to prove they are consenting to this exact configuration.
     - The participant signs their charon node's ENR, to authenticate and authorise that specific charon node to participate on their behalf in the distributed validator cluster.
   - These/this signature is sent to the data availability layer, where it verifies the signatures are correct for the given participants ethereum address. If the signatures pass validation, the signature of the config_hash and the ENR + signature get saved to the cluster definition object.
 - All participants in the list must sign the config_hash and submit a signed ENR before a DKG ceremony can begin. The outstanding signatures can be easily displayed on the status page.
@@ -87,7 +87,7 @@ For many use cases of distributed validators, the funder/depositor of the valida
 There are a number of aspects to this trust surface that can be mitigated with a "Don't trust, verify" model. Verification for the time being is easier off chain, until things like a [BLS precompile](https://eips.ethereum.org/EIPS/eip-2537) are brought into the EVM, along with cheap ZKP verification on chain. Some of the questions that can be asked of Distributed Validator Key Generation Ceremonies include:
 
 - Do the public key shares combine together to form the group public key?
-  - This can be checked on chain as it doe not require a pairing operation
+  - This can be checked on chain as it does not require a pairing operation
   - This can give confidence that a BLS pubkey represents a Distributed Validator, but does not say anything about the custody of the keys. (e.g. Was the ceremony sybil attacked, did they collude to reconstitute the group private key etc.)
 - Do the created BLS public keys attest to their `cluster_definition_hash`?
   - This is to create a backwards link between newly created BLS public keys and the operator's eth1 addresses that took part in their creation.

docs/goguidelines.md

@@ -93,18 +93,18 @@ Reasoning: Function local variables cannot be leaked and misuse is much harder t
 
 ## Style
 We follow [go fumpt](https://pkg.go.dev/mvdan.cc/gofumpt) , `go vet` and [golangci-lint](https://golangci-lint.run/) for automated formatting and vetting and linting,
-but there are still some style related aspects that are not enforced be these tools.
+but there are still some style related aspects that are not enforced by these tools.
 Please try to inform your decisions by the following style for improved consistency.
 
 > Note that style isn’t an exact science #CodeAsCraft
 
 ### New lines:
-  - Please use new lines to structure and group code for improved readability. Think about how prose and poetry uses paragraphs and layout to convey information. #CleanCodeReadsAsProse
+  - Please use new lines to structure and group code for improved readability. Think about how prose and poetry use paragraphs and layout to convey information. #CleanCodeReadsAsProse
   - Prefer new lines between blocks of related code. Functions often have multiple steps, so maybe put a new line and a comment before each step.
   - Think about new lines after indented blocks.
 
 ### Comments/godocs:
-  - The “Practical Go” articles above has great info on how to comment.
+  - The “Practical Go” articles above have great info on how to comment.
   - Avoid inline comments that are pretty much identical to the actual code. Uncle Bob imagines comments as old-school flashing web1 html instead of soothing background grey. Keep them to a minimum aiming for very high signal to noise.
   - Write long comments as proper sentences: Start with a capital, end with a full stop, grammatically correct.
 
@@ -127,7 +127,7 @@ Please try to inform your decisions by the following style for improved consiste
   - The name of the game when it comes to logging is maximize **Signal to Noise** ratio.
     - Many projects have the problem of too much logging.
     - If logs are too much and one can only search for specific logs, then identifying unexpected behaviour becomes very hard.
-    - Our aim is that humans should be able follow ALL logs (up to debug level) of a node with 1 validator.
+    - Our aim is that humans should be able to follow ALL logs (up to debug level) of a node with 1 validator.
   - Keep logging as simple and concise as possible (ask ChatGPT to help you with this).
   - Focus on glanceability and readability, users should be able to scan logs and quickly identify unexpected behaviour.
   - Stick to similar patterns for similar scenarios and packages.