chore(docs): fix typos & wording in docs (#18667)

docs/architecture/adr-061-liquid-staking.md

@@ -20,7 +20,7 @@ As both Proof of Stake and blockchain use cases have matured, this design has ag
 
 The most important deficiency of the legacy staking design is that it composes poorly with on chain protocols for trading, lending, derivatives that are referred to collectively as DeFi. The legacy staking implementation starves these applications of liquidity by increasing the risk free rate adaptively. It basically makes DeFi and staking security somewhat incompatible. 
 
-The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi appliactions can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK.
+The Osmosis team has adopted the idea of Superfluid and Interfluid staking where assets that are participating in DeFi applications can also be used in proof of stake. This requires tight integration with an enshrined set of DeFi applications and thus is unsuitable for the Cosmos SDK.
 
 It's also important to note that Interchain Accounts are available in the default IBC implementation and can be used to [rehypothecate](https://www.investopedia.com/terms/h/hypothecation.asp#toc-what-is-rehypothecation) delegations. Thus liquid staking is already possible and these changes merely improve the UX of liquid staking. Centralized exchanges also rehypothecate staked assets, posing challenges for decentralization. This ADR takes the position that adoption of in-protocol liquid staking is the preferable outcome and provides new levers to incentivize decentralization of stake. 
 

docs/architecture/adr-063-core-module-api.md

@@ -282,7 +282,7 @@ type HasGenesis interface {
 
 #### Pre Blockers
 
-Modules that have functionality that runs before BeginBlock and should implement the has `HasPreBlocker` interfaces:
+Modules that have functionality that runs before BeginBlock and should implement the `HasPreBlocker` interfaces:
 
 ```go
 type HasPreBlocker interface {
@@ -294,7 +294,7 @@ type HasPreBlocker interface {
 #### Begin and End Blockers
 
 Modules that have functionality that runs before transactions (begin blockers) or after transactions
-(end blockers) should implement the has `HasBeginBlocker` and/or `HasEndBlocker` interfaces:
+(end blockers) should implement the `HasBeginBlocker` and/or `HasEndBlocker` interfaces:
 
 ```go
 type HasBeginBlocker interface {
@@ -452,7 +452,7 @@ func ProvideApp(config *foomodulev2.Module, evtSvc event.EventService, db orm.Mo
 The `core` module will define a static integer var, `cosmossdk.io/core.RuntimeCompatibilityVersion`, which is
 a minor version indicator of the core module that is accessible at runtime. Correct runtime module implementations
 should check this compatibility version and return an error if the current `RuntimeCompatibilityVersion` is higher
-than the version of the core API that this runtime version can support. When new features are adding to the `core`
+than the version of the core API that this runtime version can support. When new features are added to the `core`
 module API that runtime modules are required to support, this version should be incremented.
 
 ### Runtime Modules

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`
 

docs/architecture/adr-067-simulator-v2.md

@@ -137,7 +137,7 @@ func (s *Simulator) SimulateBlock() {
 }
 ```
 
-Note, some application do not define or need their own app-side mempool, so we
+Note, some applications do not define or need their own app-side mempool, so we
 propose that `SelectTxs` mimic CometBFT and just return FIFO-ordered transactions
 from an ad-hoc simulator mempool. In the case where an application does define
 its own mempool, it will simply ignore what is provided in `RequestPrepareProposal`.
@@ -162,7 +162,7 @@ set of validity predicates, i.e. invariant checkers, that will be executed befor
 and after each block. This will allow for the application to assert that certain
 state invariants are held before and after each block. Note, as a consequence of
 this, we propose to remove the existing notion of invariants from module production
-execution paths and deprecate their usage all together.
+execution paths and deprecate their usage altogether.
 
 ```go
 type Manager struct {

docs/architecture/adr-069-gov-improvements.md

@@ -19,7 +19,7 @@ Those two types are, namely: multiple choice proposals and optimistic proposals.
 ## Context
 
 `x/gov` is the center of Cosmos governance, and has already been improved from its first version `v1beta1`, with a second version [`v1`][5].
-This second iteration on gov unlocked many possibilities by letting governance proposals contain any number of proposals.
+This second iteration of gov unlocked many possibilities by letting governance proposals contain any number of proposals.
 The last addition of gov has been expedited proposals (proposals that have a shorter voting period and a higher quorum, approval threshold).
 
 The community requested ([1], [4]) two additional proposals for improving governance choices. Those proposals would be useful when having protocol decisions made on specific choices or simplifying regular proposals that do not require high community involvement.
@@ -66,7 +66,7 @@ Voter can only vote NO on the proposal. If the NO threshold is reached, the opti
 Two governance parameters will be in added [`v1.Params`][5] to support optimistic proposals:
 
 ```protobuf
-// optimistic_authorized_addreses is an optional governance parameter that limits the authorized accounts than can submit optimisitc proposals
+// optimistic_authorized_addreses is an optional governance parameter that limits the authorized accounts that can submit optimistic proposals
 repeated string optimistic_authorized_addreses = 17 [(cosmos_proto.scalar) = "cosmos.AddressString"];
 
 // Optimistic rejected threshold defines at which percentage of NO votes, the optimistic proposal should fail and be converted to a standard proposal.
@@ -77,8 +77,8 @@ string optimistic_rejected_threshold = 18 [(cosmos_proto.scalar) = "cosmos.Dec"]
 
 A multiple choice proposal is a proposal where the voting options can be defined by the proposer.
 
-The number of voting option will be limited to a maximum of 4.
-A new vote option `SPAM` will be added and distinguished of those voting options. `SPAM` will be used to mark a proposal as spam and is explained further below.
+The number of voting options will be limited to a maximum of 4.
+A new vote option `SPAM` will be added and distinguished from those voting options. `SPAM` will be used to mark a proposal as spam and is explained further below.
 
 Multiple choice proposals, contrary to any other proposal type, cannot have messages to execute. They are only text proposals.
 

types/mempool/priority_nonce_spec.md

@@ -143,4 +143,4 @@ graph TD
 
 Mempool order: [10, 15, 30, 8, 20, 6, 4, 2, 90]
 
-This case shows how the mempool handles a more complex graph with more priority edges between senders.  Again we also demonstrate an idiosyncrasy of this nonce/priroity ordering scheme, tx(priority=90) is selected last because it is gated behind tx(priority=2) by nonce ordering. 
+This case shows how the mempool handles a more complex graph with more priority edges between senders.  Again we also demonstrate an idiosyncrasy of this nonce/priority ordering scheme, tx(priority=90) is selected last because it is gated behind tx(priority=2) by nonce ordering.