docs: fix a large number of spelling issues

packages/docs/pages/networks/starting-network/genesis-flow/participants.mdx

@@ -205,7 +205,7 @@ The `--net-address` specifies the network address of the validator node given by
 
 The `--alias` flag is the moniker name of the validator account in your wallet.
 
-The `--commission-rate` and `--max-commision-rate` flags are the commission rate and the maximum permitted commission rate change of the validator account per epoch. See the [validator docs](../../../operators/validators/validator-setup.mdx#initialize-a-new-validator-account) for more info.
+The `--commission-rate` and `--max-commission-rate` flags are the commission rate and the maximum permitted commission rate change of the validator account per epoch. See the [validator docs](../../../operators/validators/validator-setup.mdx#initialize-a-new-validator-account) for more info.
 
 The `--email` flag is the email address of the validator account. This is used for the validator account to receive notifications from the network coordinator and other participants.
 

packages/docs/pages/operators/ibc.mdx

@@ -271,7 +271,7 @@ All IBC transfers between two chains take place along a given IBC channel associ
 Channels must be maintained after creation by regularly submitting headers to keep the client state up to date with 
 the counterparty chain. A client that is allowed to fall out of date may expire, and further IBC transfers along the 
 channel will not be possible until the client is revived through governance. Operators should not create new channels 
-on public networks unneccessarily; instead, they should relay on existing channels if possible. 
+on public networks unnecessarily; instead, they should relay on existing channels if possible. 
 
 <Callout type='warning'>
 The same asset transferred through different channels will not be fungible on the destination chain. Therefore, to avoid 

packages/docs/pages/operators/validators/validator-actions.mdx

@@ -13,7 +13,7 @@ namadac change-commission-rate --validator <validator> --commission-rate <commis
 ```
 
 <Callout>
-The maximum allowed change in commision rate per epoch is specified by the validator's `max-commission-rate-change` parameter.  
+The maximum allowed change in commission rate per epoch is specified by the validator's `max-commission-rate-change` parameter.  
 
 The `max-commission-rate-change` can only be set on validator initialization; it cannot be changed later.
 </Callout>

packages/docs/pages/users/delegators.mdx

@@ -27,7 +27,7 @@ namadac find-validator --tendermint-key $VALIDATOR_TENDERMINT_KEY # Similarly yo
 ```
 
 <Callout>
-Before bonding to a validator, it is important to know their commision rate. This is the percentage of the block rewards that the validator will take as a fee for their services. You can find this information by running the following command:
+Before bonding to a validator, it is important to know their commission rate. This is the percentage of the block rewards that the validator will take as a fee for their services. You can find this information by running the following command:
 ```bash copy
 namadac commission-rate --validator $VALIDATOR_ADDRESS
 ```

packages/specs/pages/base-ledger/replay-protection.mdx

@@ -143,7 +143,7 @@ The consistency of the storage subspace is critically important for the correct
 
 In both `mempool_validation` and `process_proposal`, a check is performed
 (in conjunction with other checks, as described in the [relative section](#wrapper-checks)) on the digests against the storage to ensure that the transaction has not been executed yet. If this condition is not met, the tx is not included in the mempool or block, respectively. In `process_proposal` a
-temporary cache is used to prevent the replay of a wrapper transaction in the same block; it is instead allowed to include more than one transaction with the same raw header hash, since we cannot know, before execution, if the transaction(s) is valid, and we'll end up commiting its hash. If both headers
+temporary cache is used to prevent the replay of a wrapper transaction in the same block; it is instead allowed to include more than one transaction with the same raw header hash, since we cannot know, before execution, if the transaction(s) is valid, and we'll end up committing its hash. If both headers
 checks pass, the transaction is included in the block. The wrapper hash is then
 committed to storage in `finalize_block`. When we later execute the transactions' batches we check that the raw header hash is not present in storage (i.e. applied previously in this block) and we execute it. Depending on the outcome, we commit its hash to storage (we avoid committing the hash only when the transaction runs out of gas or the commitments to the sections are invalid). If the raw header hash end up being committed we remove the corresponding wrapper header hash since it's redundant at this point.