chore: Sync docs from cosmos-sdk/docs

Author: tac0turtle

docs/build/abci/03-vote-extensions.md

@@ -11,7 +11,7 @@ ABCI 2.0 (colloquially called ABCI++) allows an application to extend a pre-comm
 validator process. The Cosmos SDK defines [`baseapp.ExtendVoteHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.53.0/types/abci.go#L32):
 
 ```go
-type ExtendVoteHandler func(Context, *abci.RequestExtendVote) (*abci.ResponseExtendVote, error)
+type ExtendVoteHandler func(Context, *abci.ExtendVoteRequest) (*abci.ExtendVoteResponse, error)
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetExtendVoteHandler`
@@ -38,7 +38,7 @@ other validators when validating their pre-commits. For a given vote extension,
 this process MUST be deterministic. The Cosmos SDK defines [`sdk.VerifyVoteExtensionHandler`](https://github.com/cosmos/cosmos-sdk/blob/v0.50.1/types/abci.go#L29-L31):
 
 ```go
-type VerifyVoteExtensionHandler func(Context, *abci.RequestVerifyVoteExtension) (*abci.ResponseVerifyVoteExtension, error)
+type VerifyVoteExtensionHandler func(Context, *abci.VerifyVoteExtensionRequest) (*abci.VerifyVoteExtensionResponse, error)
 ```
 
 An application can set this handler in `app.go` via the `baseapp.SetVerifyVoteExtensionHandler`
@@ -78,7 +78,7 @@ will be available to the application during the subsequent `FinalizeBlock` call.
 An example of how a pre-FinalizeBlock hook could look like is shown below:
 
 ```go
-app.SetPreBlocker(func(ctx sdk.Context, req *abci.RequestFinalizeBlock) error {
+app.SetPreBlocker(func(ctx sdk.Context, req *abci.FinalizeBlockRequest) error {
     allVEs := []VE{} // store all parsed vote extensions here
     for _, tx := range req.Txs {
         // define a custom function that tries to parse the tx as a vote extension

docs/build/architecture/PROCESS.md

@@ -20,7 +20,7 @@ ADR creation is an **iterative** process. Instead of having a high amount of com
 
 3. If a _proposed_ ADR is merged, then it should clearly document outstanding issues either in ADR document notes or in a GitHub Issue.
 
-4. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to  merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it.
+4. The PR SHOULD always be merged. In the case of a faulty ADR, we still prefer to merge it with a _rejected_ status. The only time the ADR SHOULD NOT be merged is if the author abandons it.
 
 5. Merged ADRs SHOULD NOT be pruned.
 

docs/build/architecture/README.md

@@ -30,7 +30,7 @@ it stands today.
 
 If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
 
-## Creating new ADR
+## Creating a new ADR
 
 Read about the [PROCESS](./PROCESS.md).
 

docs/build/architecture/adr-004-split-denomination-keys.md

@@ -74,7 +74,7 @@ This will result in the balances being indexed by the byte representation of
 
 `DelegateCoins()` and `UndelegateCoins()` will be altered to only load each individual
 account balance by denomination found in the (un)delegation amount. As a result,
-any mutations to the account balance by will made by denomination.
+any mutations to the account balance will be made by denomination.
 
 `SubtractCoins()` and `AddCoins()` will be altered to read & write the balances
 directly instead of calling `GetCoins()` / `SetCoins()` (which no longer exist).

docs/build/architecture/adr-006-secret-store-replacement.md

@@ -21,7 +21,7 @@ We are seeking solution that provides a common abstraction layer to the many dif
 
 We recommend replacing the current Keybase backend based on LevelDB with [Keyring](https://github.com/99designs/keyring) by 99 designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by AWS Vault application by 99-designs application.
 
-This appears to fulfill the requirement of protecting both key material and metadata from rouge software on a user’s machine.
+This appears to fulfill the requirement of protecting both key material and metadata from rogue software on a user’s machine.
 
 ## Status
 

docs/build/architecture/adr-007-specialization-groups.md

@@ -51,7 +51,7 @@ the members already in a specialization group to internally elect new members,
 or maybe the community may assign a permission to a particular specialization
 group to appoint members to other 3rd party groups. The sky is really the limit
 as to how membership admittance can be structured. We attempt to capture
-some of these possiblities in a common interface dubbed the `Electionator`. For
+some of these possibilities in a common interface dubbed the `Electionator`. For
 its initial implementation as a part of this ADR we recommend that the general
 election abstraction (`Electionator`) is provided as well as a basic
 implementation of that abstraction which allows for a continuous election of

docs/build/architecture/adr-008-dCERT-group.md

@@ -151,7 +151,7 @@ they should all be severely slashed.
 
 ## Status
 
-> Proposed
+Proposed
 
 ## Consequences
 

docs/build/architecture/adr-010-modular-antehandler.md

@@ -142,7 +142,7 @@ type ModuleManager struct {
 }
 
 func (mm ModuleManager) GetAnteHandler() AnteHandler {
-    retun Chainer(mm.AnteHandlerOrder)
+    return Chainer(mm.AnteHandlerOrder)
 }
 ```
 

docs/build/architecture/adr-012-state-accessors.md

@@ -67,7 +67,7 @@ func (Value) Set(ctx Context, o interface{}) {}
 // Check if a raw value exists
 func (Value) Exists(ctx Context) bool {}
 
-// Delete a raw value value
+// Delete a raw value 
 func (Value) Delete(ctx Context) {}
 ```
 
@@ -92,7 +92,7 @@ func (Mapping) Set(ctx Context, key []byte, o interface{}) {}
 // Check if a raw value exists
 func (Mapping) Has(ctx Context, key []byte) bool {}
 
-// Delete a raw value value
+// Delete a raw value
 func (Mapping) Delete(ctx Context, key []byte) {}
 ```
 

docs/build/architecture/adr-014-proportional-slashing.md

@@ -49,7 +49,7 @@ Griefing, the act of intentionally getting oneself slashed in order to make anot
 
 ### Implementation
 
-In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred withing the last `jail period`.
+In the slashing module, we will add two queues that will track all of the recent slash events.  For double sign faults, we will define "recent slashes" as ones that have occurred within the last `unbonding period`.  For liveness faults, we will define "recent slashes" as ones that have occurred within the last `jail period`.
 
 ```go
 type SlashEvent struct {