chore: fix all typos (#20196)

docs/architecture/PROCESS.md

@@ -49,7 +49,7 @@ DRAFT -> PROPOSED -> LAST CALL yyyy-mm-dd -> ACCEPTED | REJECTED -> SUPERSEDED b
 * `LAST CALL <date for the last call>`: [optional] clear notify that we are close to accept 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.
 * `REJECTED`: ADR can go from PROPOSED or ACCEPTED to rejected if the consensus among project stakeholders will decide so.
-* `SUPERSEEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
+* `SUPERSEDED by ADR-xxx`: ADR which has been superseded by a new ADR.
 * `ABANDONED`: the ADR is no longer pursued by the original authors.
 
 ## Language used in ADR

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 accouns 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 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.
 * Will require that PubKeys for an account are included in the genesis exports.
 
 ## References

docs/architecture/adr-043-nft-module.md

@@ -156,7 +156,7 @@ message MsgSend {
   string class_id = 1;
   string id       = 2;
   string sender   = 3;
-  string reveiver = 4;
+  string receiver = 4;
 }
 message MsgSendResponse {}
 ```

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

@@ -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))>

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

@@ -199,7 +199,7 @@ func NewKeeper(logger log.Logger) Keeper {
 
 Modules will provide their core services to the runtime module via extension interfaces built on top of the
 `cosmossdk.io/core/appmodule.AppModule` tag interface. This tag interface requires only two empty methods which
-allow `depinject` to identify implementors as `depinject.OnePerModule` types and as app module implementations:
+allow `depinject` to identify implementers as `depinject.OnePerModule` types and as app module implementations:
 
 ```go
 type AppModule interface {

docs/learn/advanced/05-encoding.md

@@ -59,7 +59,7 @@ Modules are encouraged to utilize Protobuf encoding for their respective types.
 
 In addition to [following official Protocol Buffer guidelines](https://developers.google.com/protocol-buffers/docs/proto3#simple), we recommend using these annotations in .proto files when dealing with interfaces:
 
-* use `cosmos_proto.accepts_interface` to annote `Any` fields that accept interfaces
+* use `cosmos_proto.accepts_interface` to annotate `Any` fields that accept interfaces
     * pass the same fully qualified name as `protoName` to `InterfaceRegistry.RegisterInterface`
     * example: `(cosmos_proto.accepts_interface) = "cosmos.gov.v1beta1.Content"` (and not just `Content`)
 * annotate interface implementations with `cosmos_proto.implements_interface`

docs/spec/fee_distribution/f1_fee_distr.tex

@@ -237,7 +237,7 @@ Thus this scheme has efficiency improvements, simplicity improvements, and expre
 	\item Mention storage optimization for how to prune slashing entries in the uniform inflation and iteration over slashing case
 	\item Add equation numbers
 	\item perhaps re-organize so that the no iteration
- 	\item Section on decimal precision considerations (would unums help?), and mitigating errors in calculation with floats and decimals. -- This probably belongs in a corrollary markdown file in the implementation
+ 	\item Section on decimal precision considerations (would unums help?), and mitigating errors in calculation with floats and decimals. -- This probably belongs in a corollary markdown file in the implementation
  	\item Consider indicating that the withdraw action need not be a tx type and could instead happen 'transparently' when more coins are needed, if a chain desired this for UX / p2p efficiency.
 \end{itemize}