diff --git a/packages/docs/pages/networks/starting-network/genesis-flow/participants.mdx b/packages/docs/pages/networks/starting-network/genesis-flow/participants.mdx
index 4ee26c08..34c504bc 100644
--- a/packages/docs/pages/networks/starting-network/genesis-flow/participants.mdx
+++ b/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.
diff --git a/packages/docs/pages/operators/ibc.mdx b/packages/docs/pages/operators/ibc.mdx
index b6d0431e..b60b4a95 100644
--- a/packages/docs/pages/operators/ibc.mdx
+++ b/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.
The same asset transferred through different channels will not be fungible on the destination chain. Therefore, to avoid
diff --git a/packages/docs/pages/operators/validators/validator-actions.mdx b/packages/docs/pages/operators/validators/validator-actions.mdx
index 223df242..0eefabe9 100644
--- a/packages/docs/pages/operators/validators/validator-actions.mdx
+++ b/packages/docs/pages/operators/validators/validator-actions.mdx
@@ -13,7 +13,7 @@ namadac change-commission-rate --validator --commission-rate
-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.
diff --git a/packages/docs/pages/users/delegators.mdx b/packages/docs/pages/users/delegators.mdx
index 66a0c0af..cb4e76f0 100644
--- a/packages/docs/pages/users/delegators.mdx
+++ b/packages/docs/pages/users/delegators.mdx
@@ -27,7 +27,7 @@ namadac find-validator --tendermint-key $VALIDATOR_TENDERMINT_KEY # Similarly yo
```
-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
```
diff --git a/packages/specs/pages/base-ledger/replay-protection.mdx b/packages/specs/pages/base-ledger/replay-protection.mdx
index 6b745c90..5aafd6a4 100644
--- a/packages/specs/pages/base-ledger/replay-protection.mdx
+++ b/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.