docs: fix typos (#18125)

docs/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/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-028-public-key-addresses.md

@@ -179,7 +179,7 @@ We must be able to cryptographically derive one address from another one. The de
 
 ```go
 func Derive(address, derivationKey []byte) []byte {
-	return Hash(addres, derivationKey)
+	return Hash(address, derivationKey)
 }
 ```
 

docs/architecture/adr-031-msg-service.md

@@ -118,7 +118,7 @@ We propose to add a `msg_service_router` in BaseApp. This router is a key/value
 
 When a transaction is processed by BaseApp (in CheckTx or in DeliverTx), its `TxBody.messages` are decoded as `Msg`s. Each `Msg`'s `type_url` is matched against an entry in the `msg_service_router`, and the respective `Msg` service method handler is called.
 
-For backward compatability, the old handlers are not removed yet. If BaseApp receives a legacy `Msg` with no correspoding entry in the `msg_service_router`, it will be routed via its legacy `Route()` method into the legacy handler.
+For backward compatibility, the old handlers are not removed yet. If BaseApp receives a legacy `Msg` with no correspoding entry in the `msg_service_router`, it will be routed via its legacy `Route()` method into the legacy handler.
 
 ### Module Configuration
 

docs/architecture/adr-039-epoched-staking.md

@@ -39,14 +39,14 @@ Furthermore, it has become clearer over time that immediate execution of staking
 
 ### Slashing
 
-There is a design consideration for whether to apply a slash immediately or at the end of an epoch. A slash event should apply to only members who are actually staked during the time of the infraction, namely during the epoch the slash event occured.
+There is a design consideration for whether to apply a slash immediately or at the end of an epoch. A slash event should apply to only members who are actually staked during the time of the infraction, namely during the epoch the slash event occurred.
 
 Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned usecases. The benefits of immediate slashing for consensus layer security can be all be obtained by executing the validator jailing immediately (thus removing it from the validator set), and delaying the actual slash change to the validator's weight until the epoch boundary. For the use cases mentioned above, workarounds can be integrated to avoid problems, as follows:
 
 * For threshold based cryptography, this setting will have the threshold cryptography use the original epoch weights, while consensus has an update that lets it more rapidly benefit from additional security. If the threshold based cryptography blocks liveness of the chain, then we have effectively raised the liveness threshold of the remaining validators for the rest of the epoch. (Alternatively, jailed nodes could still contribute shares) This plan will fail in the extreme case that more than 1/3rd of the validators have been jailed within a single epoch. For such an extreme scenario, the chain already have its own custom incident response plan, and defining how to handle the threshold cryptography should be a part of that.
 * For light client efficiency, there can be a bit included in the header indicating an intra-epoch slash (ala https://github.com/tendermint/spec/issues/199).
 * For fairness of deterministic leader election, applying a slash or jailing within an epoch would break the guarantee we were seeking to provide. This then re-introduces a new (but significantly simpler) problem for trying to provide fairness guarantees. Namely, that validators can adversarially elect to remove themself from the set of proposers. From a security perspective, this could potentially be handled by two different mechanisms (or prove to still be too difficult to achieve). One is making a security statement acknowledging the ability for an adversary to force an ahead-of-time fixed threshold of users to drop out of the proposer set within an epoch. The second method would be to  parameterize such that the cost of a slash within the epoch far outweights benefits due to being a proposer. However, this latter criterion is quite dubious, since being a proposer can have many advantageous side-effects in chains with complex state machines. (Namely, DeFi games such as Fomo3D)
-* For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occured is fully queryable given the validator address.
+* For staking derivative design, there is no issue introduced. This does not increase the state size of staking records, since whether a slash has occurred is fully queryable given the validator address.
 
 ### Token lockup
 
@@ -100,7 +100,7 @@ Then we add methods to the end blockers, to ensure that at the epoch boundary th
 
 When querying the staking activity of a given address, the status should return not only the amount of tokens staked, but also if there are any queued stake events for that address. This will require more work to be done in the querying logic, to trace the queued upcoming staking events.
 
-As an initial implementation, this can be implemented as a linear search over all queued staking events. However, for chains that need long epochs, they should eventually build additional support for nodes that support querying to be able to produce results in constant time. (This is do-able by maintaining an auxilliary hashmap for indexing upcoming staking events by address)
+As an initial implementation, this can be implemented as a linear search over all queued staking events. However, for chains that need long epochs, they should eventually build additional support for nodes that support querying to be able to produce results in constant time. (This is do-able by maintaining an auxiliary hashmap for indexing upcoming staking events by address)
 
 **Step-3**: Adjust gas
 

docs/architecture/adr-044-protobuf-updates-guidelines.md

@@ -49,7 +49,7 @@ The SDK requires the Protobuf comment of the new addition to contain one line wi
 // Since: cosmos-sdk <version>{, <version>...}
 ```
 
-Where each `version` denotes a minor ("0.45") or patch ("0.44.5") version from which the field is available. This will greatly help client libraries, who can optionally use reflection or custom code generation to show/hide these fields depending on the targetted node version.
+Where each `version` denotes a minor ("0.45") or patch ("0.44.5") version from which the field is available. This will greatly help client libraries, who can optionally use reflection or custom code generation to show/hide these fields depending on the targeted node version.
 
 As examples, the following comments are valid:
 

docs/architecture/adr-046-module-params.md

@@ -143,7 +143,7 @@ are read on a consistent basis.
 
 However, this methodology will require developers to implement more types and
 Msg service metohds which can become burdensome if many parameters exist. In addition,
-developers are required to implement persistance logics of module parameters.
+developers are required to implement persistence logics of module parameters.
 However, this should be trivial.
 
 ### Backwards Compatibility

docs/architecture/adr-049-state-sync-hooks.md

@@ -37,7 +37,7 @@ implement `ExtensionSnapshotter` as extension snapshotters. When setting up the
 
 ```protobuf
 // SnapshotItem is an item contained in a rootmulti.Store snapshot.
-// On top of the exsiting SnapshotStoreItem and SnapshotIAVLItem, we add two new options for the item.
+// On top of the existing SnapshotStoreItem and SnapshotIAVLItem, we add two new options for the item.
 message SnapshotItem {
   // item is the specific type of snapshot item.
   oneof item {

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
 

docs/architecture/adr-059-test-scopes.md

@@ -148,7 +148,7 @@ to a production environment as is practical. Presently these tests are located a
 [tests/e2e](https://github.com/cosmos/cosmos-sdk/tree/main/tests/e2e) and rely on [testutil/network](https://github.com/cosmos/cosmos-sdk/tree/main/testutil/network) to start up an in-process Tendermint node.
 
 An application should be built as minimally as possible to exercise the desired functionality.
-The SDK uses an application will only the required modules for the tests. The application developer is adviced to use its own application for e2e tests.
+The SDK uses an application will only the required modules for the tests. The application developer is advised to use its own application for e2e tests.
 
 #### Limitations
 

docs/build/building-modules/16-testing.md

@@ -7,7 +7,7 @@ sidebar_position: 1
 The Cosmos SDK contains different types of [tests](https://martinfowler.com/articles/practical-test-pyramid.html).
 These tests have different goals and are used at different stages of the development cycle.
 We advice, as a general rule, to use tests at all stages of the development cycle.
-It is adviced, as a chain developer, to test your application and modules in a similar way than the SDK.
+It is advised, as a chain developer, to test your application and modules in a similar way than the SDK.
 
 The rationale behind testing can be found in [ADR-59](https://docs.cosmos.network/main/architecture/adr-059-test-scopes.html).
 
@@ -59,7 +59,7 @@ In the SDK, we locate our integration tests under [`/tests/integrations`](https:
 
 The goal of these integration tests is to test how a component interacts with other dependencies. Compared to unit tests, integration tests do not mock dependencies. Instead, they use the direct dependencies of the component. This differs as well from end-to-end tests, which test the component with a full application.
 
-Integration tests interact with the tested module via the defined `Msg` and `Query` services. The result of the test can be verified by checking the state of the application, by checking the emitted events or the response. It is adviced to combine two of these methods to verify the result of the test.
+Integration tests interact with the tested module via the defined `Msg` and `Query` services. The result of the test can be verified by checking the state of the application, by checking the emitted events or the response. It is advised to combine two of these methods to verify the result of the test.
 
 The SDK provides small helpers for quickly setting up an integration tests. These helpers can be found at <https://github.com/cosmos/cosmos-sdk/blob/main/testutil/integration>.