From dcfe4113263eab7cb0bd26f3a8001f6c0e861e8c Mon Sep 17 00:00:00 2001 From: tinyfoolish Date: Thu, 13 Nov 2025 11:48:17 +0800 Subject: [PATCH] docs: fix a large number of spelling issues Signed-off-by: tinyfoolish --- .../networks/starting-network/genesis-flow/participants.mdx | 2 +- packages/docs/pages/operators/ibc.mdx | 2 +- packages/docs/pages/operators/validators/validator-actions.mdx | 2 +- packages/docs/pages/users/delegators.mdx | 2 +- packages/specs/pages/base-ledger/replay-protection.mdx | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) 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.