docs: fix grammar and spelling errors (#25129)

Co-authored-by: Alex | Interchain Labs <alex@interchainlabs.io>

docs/architecture/PROCESS.md

@@ -8,7 +8,7 @@
 
 ## What is an ADR? 
 
-An ADR is a document to document an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchronous communication in a distributed environment, an ADR is meant to document an already made decision. An ADR won't come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchronous discussion, then a short excerpt should be added to the ADR to explain the goals. 
+An ADR is a document that documents an implementation and design that may or may not have been discussed in an RFC. While an RFC is meant to replace synchronous communication in a distributed environment, an ADR is meant to document an already made decision. An ADR won't come with much of a communication overhead because the discussion was recorded in an RFC or a synchronous discussion. If the consensus came from a synchronous discussion, then a short excerpt should be added to the ADR to explain the goals. 
 
 ## ADR life cycle
 
@@ -44,15 +44,15 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
                      ABANDONED
 ```
 
-* `DRAFT`: [optional] an ADR which is a work in progress, not being ready for a general review. This is to present an early work and get early feedback in a Draft Pull Request form.
+* `DRAFT`: [optional] an ADR which is a work in progress, not ready for a general review. This is to present an early work and get early feedback in a Draft Pull Request form.
 * `PROPOSED`: an ADR covering a full solution architecture and still in the review - project stakeholders haven't reached an agreement yet.
 * `LAST CALL <date for the last call>`: [optional] Notify that we are close to accepting updates. Changing a status to `LAST CALL` means that social consensus (of Cosmos SDK maintainers) has been reached, and we still want to give it a time to let the community react or analyze.
-* `ACCEPTED`: ADR which will represent a currently implemented or to be implemented architecture design.
+* `ACCEPTED`: an ADR that represents a currently implemented or to be implemented architecture design.
 * `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
-* `SUPERSEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
+* `SUPERSEDED by ADR-xxx`: an ADR that has been superseded by a new ADR.
 * `ABANDONED`: the ADR is no longer pursued by the original authors.
 
 ## Language used in ADR
 
 * The context/background should be written in the present tense.
-* Avoid using a first, personal form.
+* Avoid using the first person.

docs/architecture/README.md

@@ -8,7 +8,7 @@ This is a location to record all high-level architecture decisions in the Cosmos
 
 An Architectural Decision (**AD**) is a software design choice that addresses a functional or non-functional requirement that is architecturally significant.
 An Architecturally Significant Requirement (**ASR**) is a requirement that has a measurable effect on a software system’s architecture and quality.
-An Architectural Decision Record (**ADR**) captures a single AD, such as often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM).
+An Architectural Decision Record (**ADR**) captures a single AD, such as is often done when writing personal notes or meeting minutes; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM).
 
 You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t).
 
@@ -25,7 +25,7 @@ An ADR should provide:
 
 Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and
 justification for a change in architecture, or for the architecture of something
-new. The spec is much more compressed and streamlined summary of everything as
+new. The spec is a much more compressed and streamlined summary of everything as
 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.

docs/architecture/adr-064-abci-2.0.md

@@ -25,7 +25,7 @@ includes `ExtendVote`, `VerifyVoteExtension` and `FinalizeBlock`.
 ABCI 2.0 continues the promised updates from ABCI++, specifically three additional
 ABCI methods that the application can implement in order to gain further control,
 insight and customization of the consensus process, unlocking many novel use-cases
-that previously not possible. We describe these three new methods below:
+that were previously not possible. We describe these three new methods below:
 
 ### `ExtendVote`
 
@@ -396,7 +396,7 @@ and rely on existing events, especially since applications will still define
 In order to facilitate existing event functionality, we propose that all `BeginBlock`
 and `EndBlock` events have a dedicated `EventAttribute` with `key=block` and
 `value=begin_block|end_block`. The `EventAttribute` will be appended to each event
-in both `BeginBlock` and `EndBlock` events`. 
+in both `BeginBlock` and `EndBlock` events. 
 
 
 ### Upgrading

docs/architecture/adr-065-store-v2.md

@@ -21,7 +21,7 @@ shortcomings and flaws have been exposed in the state and storage primitives of
 the Cosmos SDK.
 
 In order to keep up with the evolving demands and needs of both clients and developers,
-a major overhaul to these primitives are necessary.
+a major overhaul to these primitives is necessary.
 
 ## Context
 
@@ -35,7 +35,7 @@ application state. This data structure is the base layer `KVStore`.
 In addition, the SDK provides abstractions on top of this Merkle data structure.
 Namely, a root multi-store (RMS) is a collection of each module's `KVStore`.
 Through the RMS, the application can serve queries and provide proofs to clients
-in addition to provide a module access to its own unique `KVStore` through the use
+in addition to providing a module access to its own unique `KVStore` through the use
 of `StoreKey`, which is an OCAP primitive.
 
 There are further layers of abstraction that sit between the RMS and the underlying
@@ -65,11 +65,11 @@ See the [Storage Discussion](https://github.com/cosmos/cosmos-sdk/discussions/13
 ## Alternatives
 
 There was a previous attempt to refactor the storage layer described in [ADR-040](./adr-040-storage-and-smt-state-commitments.md).
-However, this approach mainly stems on the shortcomings of IAVL and various performance
+However, this approach mainly stems from the shortcomings of IAVL and various performance
 issues around it. While there was a (partial) implementation of [ADR-040](./adr-040-storage-and-smt-state-commitments.md),
 it was never adopted for a variety of reasons, such as the reliance on using an
 SMT, which was more in a research phase, and some design choices that couldn't
-be fully agreed upon, such as the snap-shotting mechanism that would result in
+be fully agreed upon, such as the snapshotting mechanism that would result in
 massive state bloat.
 
 ## Decision
@@ -192,7 +192,7 @@ Since the SS layer is naturally a storage layer only, without any commitments
 to (key, value) pairs, it cannot provide Merkle proofs to clients during queries.
 
 Since the pruning strategy against the SC layer is configured by the operator,
-we can therefore have the RMS route the query SC layer if the version exists and
+we can therefore have the RMS route the query to the SC layer if the version exists and
 `prove: true`. Otherwise, the query will fall back to the SS layer without a proof.
 
 We could explore the idea of using state snapshots to rebuild an in-memory IAVL

docs/architecture/adr-068-preblock.md

@@ -10,12 +10,12 @@ DRAFT
 
 ## Abstract
 
-Introduce `PreBlock`, which runs before begin blocker other modules, and allows to modify consensus parameters, and the changes are visible to the following state machine logics.
+Introduce `PreBlock`, which runs before the begin blocker of other modules, and allows modifying consensus parameters, and the changes are visible to the following state machine logics.
 
 ## Context
 
 When upgrading to sdk 0.47, the storage format for consensus parameters changed, but in the migration block, `ctx.ConsensusParams()` is always `nil`, because it fails to load the old format using new code, it's supposed to be migrated by the `x/upgrade` module first, but unfortunately, the migration happens in `BeginBlocker` handler, which runs after the `ctx` is initialized.
-When we try to solve this, we find the `x/upgrade` module can't modify the context to make the consensus parameters visible for the other modules, the context is passed by value, and sdk team want to keep it that way, that's good for isolations between modules.
+When we try to solve this, we find the `x/upgrade` module can't modify the context to make the consensus parameters visible for the other modules, the context is passed by value, and sdk team want to keep it that way, that's good for isolation between modules.
 
 ## Alternatives
 
@@ -32,7 +32,7 @@ There are two semantics around the new lifecycle method:
 * It runs before the `BeginBlocker` of all modules
 * It can modify consensus parameters in storage, and signal the caller through the return value.
 
-When it returns `ConsensusParamsChanged=true`, the caller must refresh the consensus parameter in the finalize context:
+When it returns `ConsensusParamsChanged=true`, the caller must refresh the consensus parameters in the finalize context:
 
 ```
 app.finalizeBlockState.ctx = app.finalizeBlockState.ctx.WithConsensusParams(app.GetConsensusParams())

docs/architecture/adr-070-unordered-account.md

@@ -19,7 +19,7 @@ the use of a time-based, ephemeral sequence.
 
 ## Context
 
-Account sequence values serve to prevent replay attacks and ensure transactions from the same sender are included into blocks and executed
+Account sequence values serve to prevent replay attacks and ensure transactions from the same sender are included in blocks and executed
 in sequential order. Unfortunately, this makes it difficult to reliably send many concurrent transactions from the
 same sender. Victims of such limitations include IBC relayers and crypto exchanges.
 
@@ -40,7 +40,7 @@ will be recorded to state.
 New transactions will be checked against the state to prevent duplicate submissions. To prevent the state from growing indefinitely, we propose the following:
 
 * Define an upper bound for the value of `timeout_timestamp` (i.e. 10 minutes).
-* Add PreBlocker method x/auth that removes state entries with a `timeout_timestamp` earlier than the current block time.
+* Add PreBlocker method to x/auth that removes state entries with a `timeout_timestamp` earlier than the current block time.
 
 ### Transaction Format
 
@@ -49,7 +49,7 @@ message TxBody {
   ...
           
   bool unordered = 4;
-  google.protobuf.Timestamp timeout_timestamp = 5
+  google.protobuf.Timestamp timeout_timestamp = 5;
 }
 ```
 
@@ -300,7 +300,7 @@ The storage of unordered sequences will be facilitated using the Cosmos SDK's KV
 
 The previous iteration of unordered transactions worked by using an ad-hoc state-management system that posed severe 
 risks and a vector for duplicated tx processing. It relied on graceful app closure which would flush the current state
-of the unordered sequence mapping. If the 2/3's of the network crashed, and the graceful closure did not trigger, 
+of the unordered sequence mapping. If 2/3 of the network crashed, and the graceful closure did not trigger, 
 the system would lose track of all sequences in the mapping, allowing those transactions to be replayed. The 
 implementation proposed in the updated version of this ADR solves this by writing directly to the Cosmos KV Store.
 While this is less performant, for the initial implementation, we opted to choose a safer path and postpone performance optimizations until we have more data on real-world impacts and a more battle-tested approach to optimization.

docs/architecture/adr-076-tx-malleability.md

@@ -55,7 +55,7 @@ Cosmos SDK transactions are encoded using protobuf binary encoding when they are
 * default field values can be included or omitted, and this doesn't change meaning unless `optional` is used
 * `repeated` fields of scalars may use packed or "regular" encoding
 * `varint`s can include extra ignored bits
-* extra fields may be added and are usually simply ignored by decoders. [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) specifies that in general such extra fields should cause messages and transactions to be rejected)
+* extra fields may be added and are usually simply ignored by decoders. [ADR 020](https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-020-protobuf-transaction-encoding.md#unknown-field-filtering) specifies that in general such extra fields should cause messages and transactions to be rejected
 
 When using `SIGN_MODE_DIRECT` none of the above malleabilities will be tolerated because:
 
@@ -88,8 +88,8 @@ representation.
 
 #### Fields not covered by Amino JSON
 
-Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc`(see [`aminojson.proto`](../../x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](../../proto/cosmos/tx/v1beta1/tx.proto)).
-If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representing in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a
+Another area that needs to be addressed carefully is the discrepancy between `AminoSignDoc` (see [`aminojson.proto`](../../x/tx/signing/aminojson/internal/aminojsonpb/aminojson.proto)) used for `SIGN_MODE_LEGACY_AMINO_JSON` and the actual contents of `TxBody` and `AuthInfo` (see [`tx.proto`](../../proto/cosmos/tx/v1beta1/tx.proto)).
+If fields get added to `TxBody` or `AuthInfo`, they must either have a corresponding representation in `AminoSignDoc` or Amino JSON signatures must be rejected when those new fields are set. Making sure that this is done is a
 highly manual process, and developers could easily make the mistake of updating `TxBody` or `AuthInfo`
 without paying any attention to the implementation of `GetSignBytes` for Amino JSON. This is a critical
 vulnerability in which unsigned content can now get into the transaction and signature verification will
@@ -129,7 +129,7 @@ sign mode is still commonly used.
 It is recommended that the following improvements be made to Amino JSON signing:
 
 * hashes of `TxBody` and `AuthInfo` should be added to `AminoSignDoc` so that encoding-level malleability is addressed
-* when constructing `AminoSignDoc`, [protoreflect](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect) API should be used to ensure that there no fields in `TxBody` or `AuthInfo` which do not have a mapping in `AminoSignDoc` have been set
+* when constructing `AminoSignDoc`, [protoreflect](https://pkg.go.dev/google.golang.org/protobuf/reflect/protoreflect) API should be used to ensure that there are no fields in `TxBody` or `AuthInfo` which do not have a mapping in `AminoSignDoc` have been set
 * fields present in `TxBody` or `AuthInfo` that are not present in `AminoSignDoc` (such as extension options) should
 be added to `AminoSignDoc` if possible
 

docs/architecture/adr-template.md

@@ -15,7 +15,7 @@
 
 > "If you can't explain it simply, you don't understand it well enough." Provide
 > a simplified and layman-accessible explanation of the ADR.
-> A short (~200 word) description of the issue being addressed.
+> A short (~200 words) description of the issue being addressed.
 
 ## Context