docs: fix docs from small prs

core/validatorapi/router.go

@@ -595,6 +595,7 @@ func proposeBlock(p eth2client.ProposalProvider) handlerFunc {
 			RandaoReveal: randao,
 			Graffiti:     graff,
 		}
+
 		eth2Resp, err := p.Proposal(ctx, opts)
 		if err != nil {
 			return nil, nil, err

docs/contributing.md

@@ -23,7 +23,7 @@ instead of opening a public issue or PR on GitHub.
     - Open a GitHub issue if everything else checks out 🤓
 - Are you thinking of a small change that just makes sense? Feel free to submit a PR.
 - If you're envisioning a larger feature or are just looking for a discussion,
-  let's chat in the [Obol Discord](https://discord.gg/n6ebKsX46w/) under `#dev-community`.
+  let's chat in the [Obol Discord](https://discord.com/invite/n6ebKsX46w)under `#dev-community`.
     - A quick sync before coding avoids conflicting work and makes large PRs much more likely to be accepted.
     - 👀 The Discord channel is currently _invite-only_ to prevent spam. Please ping a team member to get access.
 

docs/dkg.md

@@ -12,7 +12,7 @@
 
 ## Overview
 
-To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together. (4 randomly chosen points on a graph don't all neccessarily sit on the same order three curve.) To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a distributed key generation ceremony.
+To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together. (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve.) To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a distributed key generation ceremony.
 
 The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster configuration](https://docs.obol.tech/docs/dv/distributed-validator-cluster-manifest).
 
@@ -28,8 +28,8 @@ A distributed key generation ceremony involves `Operators` and their `Charon cli
 
 This cluster-definition file is created with the help of the [Distributed Validator Launchpad](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad). The creation process involves a number of steps.
 
-- A `leader` Operator, that wishes to co-ordinate the creation of a new Distributed Validator Cluster navigates to the launch pad and selects "Create new Cluster"
-- The `leader` uses the user interface to configure all of the important details about the cluster including:
+- A `leader` Operator, that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launch pad and selects "Create new Cluster"
+- The `leader` uses the user interface to configure all the important details about the cluster including:
   - The `withdrawal address` for the created validators
   - The `feeRecipient` for block proposals if it differs from the withdrawal address
   - The number of distributed validators to create

docs/goguidelines.md

@@ -51,7 +51,7 @@ checker := newReadyChecker(foo, bar)
 // Use the checker instance
 for checker.IsReady() { ... }
 ```
-Reasoning: The startReadyChecker contains all state and logic in one function and the resulting isReady function cannot be misused. The checker instance introduces a new type with fields that are accesible and can therefore be misused, it is also at risk of being extended with more logic and coupling.
+Reasoning: The startReadyChecker contains all state and logic in one function and the resulting isReady function cannot be misused. The checker instance introduces a new type with fields that are accessible and can therefore be misused, it is also at risk of being extended with more logic and coupling.
 
 ### Prefer functions returning functions over new types with methods #2
 ```go