docs: fix typos across multiple modules and documentation (#25078)

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

docs/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/architecture/adr-008-dCERT-group.md

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

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

@@ -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/architecture/adr-019-protobuf-state-encoding.md

@@ -136,7 +136,7 @@ to be reimplemented for each chain
 The main counter-argument to using `Any` centers around its additional space
 and possibly performance overhead. The space overhead could be dealt with using
 compression at the persistence layer in the future and the performance impact
-is likely to be small. Thus, not using `Any` is seem as a pre-mature optimization,
+is likely to be small. Thus, not using `Any` is seen as a pre-mature optimization,
 with user experience as the higher order concern.
 
 Note, that given the Cosmos SDK's decision to adopt the `Codec` interfaces described

docs/architecture/adr-023-protobuf-naming.md

@@ -117,7 +117,7 @@ Instead of breaking things, we should make every effort to evolve schemas rather
 to prevent such breakage.
 
 With that in mind, different stable versions (i.e. `v1` or `v2`) of a package should more or less be considered
-different packages and this should be last resort approach for upgrading protobuf schemas. Scenarios where creating
+different packages and this should be a last resort approach for upgrading protobuf schemas. Scenarios where creating
 a `v2` may make sense are:
 
 * we want to create a new module with similar functionality to an existing module and adding `v2` is the most natural
@@ -200,7 +200,7 @@ go package names, i.e. the `cosmos.bank` protobuf package will still live in
 
 ### Message Naming
 
-Message type names should be as concise possible without losing clarity. `sdk.Msg`
+Message type names should be as as concise possible without losing clarity. `sdk.Msg`
 types which are used in transactions will retain the `Msg` prefix as that provides
 helpful context.
 

docs/architecture/adr-028-public-key-addresses.md

@@ -207,7 +207,7 @@ For backward compatibility with the existing `authtypes.NewModuleAddress`, we ad
 ```go
 func Module(moduleName string, derivationKeys ...[]byte) []byte{
 	if len(derivationKeys) == 0 {
-		return authtypes.NewModuleAddress(modulenName)  // legacy case
+		return authtypes.NewModuleAddress(moduleName)  // legacy case
 	}
 	submoduleAddress := Hash("module", []byte(moduleName) + 0 + key)
 	return fold((a, k) => Derive(a, k), subsubKeys, submoduleAddress)

docs/architecture/adr-030-authz-module.md

@@ -165,7 +165,7 @@ message MsgExecResponse {
 message MsgExec {
   string   grantee                  = 1;
   // Authorization Msg requests to execute. Each msg must implement Authorization interface
-  repeated google.protobuf.Any msgs = 2 [(cosmos_proto.accepts_interface) = "cosmos.base.v1beta1.Msg"];;
+  repeated google.protobuf.Any msgs = 2 [(cosmos_proto.accepts_interface) = "cosmos.base.v1beta1.Msg"];
 }
 ```
 

docs/architecture/adr-032-typed-events.md

@@ -294,7 +294,7 @@ func PublishChainTxEvents(ctx context.Context, client cmtclient.EventsClient, bu
                     for _, abciEv := range events {
                         typedEvent, err := sdk.ParseTypedEvent(abciEv)
                         if err != nil {
-                            return er
+                            return err
                         }
                         if err := bus.Publish(typedEvent); err != nil {
                             bus.Close()

docs/architecture/adr-034-account-rekeying.md

@@ -68,7 +68,7 @@ Breaks the current assumed relationship between address and pubkeys as H(pubkey)
 
 ### Neutral
 
-* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner.  For example, this could be use used to sell a staked position without unbonding or an account that has vesting tokens.  However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accounts with Vesting tokens to use this feature.
+* While the purpose of this is intended to allow the owner of an account to update to a new pubkey they own, this could technically also be used to transfer ownership of an account to a new owner.  For example, this could be used to sell a staked position without unbonding or an account that has vesting tokens.  However, the friction of this is very high as this would essentially have to be done as a very specific OTC trade. Furthermore, additional constraints could be added to prevent accounts with Vesting tokens to use this feature.
 * Will require that PubKeys for an account are included in the genesis exports.
 
 ## References

docs/architecture/adr-036-arbitrary-signature.md

@@ -121,7 +121,7 @@ Backwards compatibility is maintained as this is a new message spec definition.
 
 ## Further discussion
 
-* Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content laying in `Data` non-replayable when, and if, needed.
+* Regarding security in `MsgSignData`, the developer using `MsgSignData` is in charge of making the content lying in `Data` non-replayable when, and if, needed.
 * the offchain package will be further extended with extra messages that target specific use cases such as, but not limited to, authentication in applications, payment channels, L2 solutions in general.
 
 ## References

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

@@ -41,7 +41,7 @@ Furthermore, it has become clearer over time that immediate execution of staking
 
 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:
+Applying it immediately can be viewed as offering greater consensus layer security, at potential costs to the aforementioned use cases. 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).