docs: fix typos in documentation files (#24973)

Co-authored-by: Alex | Interchain Labs <[email protected]>

Author: prestoalvarez

docs/architecture/adr-020-protobuf-transaction-encoding.md

@@ -69,7 +69,7 @@ message Tx {
     repeated bytes signatures = 3;
 }
 
-// A variant of Tx that pins the signer's exact binary represenation of body and
+// A variant of Tx that pins the signer's exact binary representation of body and
 // auth_info. This is used for signing, broadcasting and verification. The binary
 // `serialize(tx: TxRaw)` is stored in Tendermint and the hash `sha256(serialize(tx: TxRaw))`
 // becomes the "txhash", commonly used as the transaction ID.

docs/architecture/adr-050-sign-mode-textual-annex2.md

@@ -25,7 +25,7 @@ Unicode text within the transaction.
 
 `SIGN_MODE_TEXTUAL` renders to an abstract representation, leaving it
 up to device-specific software how to present this representation given the
-capabilities, limitations, and conventions of the deivce.
+capabilities, limitations, and conventions of the device.
 
 We offer the following normative guidance:
 

docs/architecture/adr-050-sign-mode-textual.md

@@ -24,7 +24,7 @@ Spec version: 0.
 
 ## Abstract
 
-This ADR specifies SIGN_MODE_TEXTUAL, a new string-based sign mode that is targetted at signing with hardware devices.
+This ADR specifies SIGN_MODE_TEXTUAL, a new string-based sign mode that is targeted at signing with hardware devices.
 
 ## Context
 
@@ -72,7 +72,7 @@ or needs to be present only for signature integrity (see below).
 We require that the rendering of the transaction be invertible:
 there must be a parsing function such that for every transaction,
 when rendered to the textual representation,
-parsing that representation yeilds a proto message equivalent
+parsing that representation yields a proto message equivalent
 to the original under proto equality.
 
 Note that this inverse function does not need to perform correct
@@ -145,7 +145,7 @@ type SignDocTextual struct {
 ```
 
 We do not plan to use protobuf serialization to form the sequence of bytes
-that will be tranmitted and signed, in order to keep the decoder simple.
+that will be transmitted and signed, in order to keep the decoder simple.
 We will use [CBOR](https://cbor.io) ([RFC 8949](https://www.rfc-editor.org/rfc/rfc8949.html)) instead.
 The encoding is defined by the following CDDL ([RFC 8610](https://www.rfc-editor.org/rfc/rfc8610)):
 
@@ -285,7 +285,7 @@ Moreover, the renderer must provide 2 functions: one for formatting from Protobu
 
 ### Require signing over the `TxBody` and `AuthInfo` raw bytes
 
-Recall that the transaction bytes merklelized on chain are the Protobuf binary serialization of [TxRaw](hhttps://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.tx.v1beta1#cosmos.tx.v1beta1.TxRaw), which contains the `body_bytes` and `auth_info_bytes`. Moreover, the transaction hash is defined as the SHA256 hash of the `TxRaw` bytes. We require that the user signs over these bytes in SIGN_MODE_TEXTUAL, more specifically over the following string:
+Recall that the transaction bytes merklelized on chain are the Protobuf binary serialization of [TxRaw](https://buf.build/cosmos/cosmos-sdk/docs/main:cosmos.tx.v1beta1#cosmos.tx.v1beta1.TxRaw), which contains the `body_bytes` and `auth_info_bytes`. Moreover, the transaction hash is defined as the SHA256 hash of the `TxRaw` bytes. We require that the user signs over these bytes in SIGN_MODE_TEXTUAL, more specifically over the following string:
 
 ```
 *Hash of raw bytes: <HEX(sha256(len(body_bytes) ++ body_bytes ++ len(auth_info_bytes) ++ auth_info_bytes))>
@@ -310,7 +310,7 @@ The current specification is not set in stone, and future iterations are to be e
 1. Updates that require changes of the hardware device embedded application.
 2. Updates that only modify the envelope and the value renderers.
 
-Updates in the 1st category include changes of the `Screen` struct or its corresponding CBOR encoding. This type of updates require a modification of the hardware signer application, to be able to decode and parse the new types. Backwards-compatibility must also be guaranteed, so that the new hardware application works with existing versions of the SDK. These updates require the coordination of multiple parties: SDK developers, hardware application developers (currently: Zondax), and client-side developers (e.g. CosmJS). Furthermore, a new submission of the hardware device application may be necessary, which, dependending on the vendor, can take some time. As such, we recommend to avoid this type of updates as much as possible.
+Updates in the 1st category include changes of the `Screen` struct or its corresponding CBOR encoding. This type of updates require a modification of the hardware signer application, to be able to decode and parse the new types. Backwards-compatibility must also be guaranteed, so that the new hardware application works with existing versions of the SDK. These updates require the coordination of multiple parties: SDK developers, hardware application developers (currently: Zondax), and client-side developers (e.g. CosmJS). Furthermore, a new submission of the hardware device application may be necessary, which, depending on the vendor, can take some time. As such, we recommend to avoid this type of updates as much as possible.
 
 Updates in the 2nd category include changes to any of the value renderers or to the transaction envelope. For example, the ordering of fields in the envelope can be swapped, or the timestamp formatting can be modified. Since SIGN_MODE_TEXTUAL sends `Screen`s to the hardware device, this type of change do not need a hardware wallet application update. They are however state-machine-breaking, and must be documented as such. They require the coordination of SDK developers with client-side developers (e.g. CosmJS), so that the updates are released on both sides close to each other in time.
 

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. 
 

x/auth/vesting/README.md

@@ -543,7 +543,7 @@ V' = 0
     V' = 25
     ```
 
-3. During vesting period 2, 5 coins are transfered and 5 coins are delegated
+3. During vesting period 2, 5 coins are transferred and 5 coins are delegated
 
     ```text
     DV = 5
@@ -605,7 +605,7 @@ simd tx vesting create-periodic-vesting-account cosmos1.. periods.json
 
 #### create-vesting-account
 
-The `create-vesting-account` command creates a new vesting account funded with an allocation of tokens. The account can either be a delayed or continuous vesting account, which is determined by the '--delayed' flag. All vesting accouts created will have their start time set by the committed block's time. The end_time must be provided as a UNIX epoch timestamp.
+The `create-vesting-account` command creates a new vesting account funded with an allocation of tokens. The account can either be a delayed or continuous vesting account, which is determined by the '--delayed' flag. All vesting accounts created will have their start time set by the committed block's time. The end_time must be provided as a UNIX epoch timestamp.
 
 ```bash
 simd tx vesting create-vesting-account [to_address] [amount] [end_time] [flags]

x/group/README.md

@@ -87,7 +87,7 @@ A decision policy is the mechanism by which members of a group can vote on
 proposals, as well as the rules that dictate whether a proposal should pass
 or not based on its tally outcome.
 
-All decision policies generally would have a mininum execution period and a
+All decision policies generally would have a minimum execution period and a
 maximum voting window. The minimum execution period is the minimum amount of time
 that must pass after submission in order for a proposal to potentially be executed, and it may
 be set to 0. The maximum voting window is the maximum time after submission that a proposal may
@@ -212,7 +212,7 @@ Proposals and votes are automatically pruned to avoid state bloat.
 Votes are pruned:
 
 * either after a successful tally, i.e. a tally whose result passes the decision
-  policy's rules, which can be trigged by a `Msg/Exec` or a
+  policy's rules, which can be triggered by a `Msg/Exec` or a
   `Msg/{SubmitProposal,Vote}` with the `Exec` field set,
 * or on `EndBlock` right after the proposal's voting period end. This applies to proposals with status `aborted` or `withdrawn` too.
 

x/protocolpool/README.md

@@ -10,7 +10,7 @@ sidebar_position: 1
 
 This module is `supplemental`; it is not required to run a Cosmos SDK chain. `x/protocolpool` enhances the community pool functionality provided by `x/distribution` and enables custom modules to further extend the community pool.
 
-Note: _as long as an external commmunity pool keeper (here, `x/protocolpool`) is wired in DI configs, `x/distribution` will automatically use it for its external pool._
+Note: _as long as an external community pool keeper (here, `x/protocolpool`) is wired in DI configs, `x/distribution` will automatically use it for its external pool._
 
 ## Usage Limitations