From 76e34484f10dbb8f4cab16c22e22afe2febade0a Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Mon, 14 Oct 2024 09:57:27 +0300 Subject: [PATCH] Docs fix spelling issues (#3378) * Update adr-template.md * Update delegator-faq.md * Update upgrade-node.md --------- Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> --- docs/docs/architecture/templates/adr-template.md | 2 +- docs/docs/delegators/delegator-faq.md | 4 ++-- docs/docs/hub-tutorials/upgrade-node.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/docs/architecture/templates/adr-template.md b/docs/docs/architecture/templates/adr-template.md index b1c376897e4..d54f3f63a9f 100644 --- a/docs/docs/architecture/templates/adr-template.md +++ b/docs/docs/architecture/templates/adr-template.md @@ -53,6 +53,6 @@ If the proposed change will be large, please also indicate a way to do the chang ## References -> Are there any relevant PR comments, issues that led up to this, or articles referrenced for why we made the given design choice? If so link them here! +> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! * {reference link} diff --git a/docs/docs/delegators/delegator-faq.md b/docs/docs/delegators/delegator-faq.md index 3ecdafef8ee..85b7d5bac9b 100644 --- a/docs/docs/delegators/delegator-faq.md +++ b/docs/docs/delegators/delegator-faq.md @@ -5,7 +5,7 @@ order: 4 ## What is a delegator? -People that cannot or do not want to operate [validator nodes](../validators/overview.md) can still participate in the staking process as delegators. Indeed, validators are not chosen based on their self-delegated stake but based on their total stake, which is the sum of their self-delegated stake and of the stake that is delegated to them. This is an important property, as it makes delegators a safeguard against validators that exhibit bad behavior. If a validator misbehaves, their delegators will move their Atoms away from them, thereby reducing their stake. Eventually, if a validator's stake falls under the top 180 addresses with highest stake, they will exit the validator set. +People who cannot or do not want to operate [validator nodes](../validators/overview.md) can still participate in the staking process as delegators. Indeed, validators are not chosen based on their self-delegated stake but based on their total stake, which is the sum of their self-delegated stake and of the stake that is delegated to them. This is an important property, as it makes delegators a safeguard against validators that exhibit bad behavior. If a validator misbehaves, their delegators will move their Atoms away from them, thereby reducing their stake. Eventually, if a validator's stake falls under the top 180 addresses with highest stake, they will exit the validator set. **Delegators share the revenue of their validators, but they also share the risks.** In terms of revenue, validators and delegators differ in that validators can apply a commission on the revenue that goes to their delegator before it is distributed. This commission is known to delegators beforehand and can only change according to predefined constraints (see [section](#choosing-a-validator) below). In terms of risk, delegators' Atoms can be slashed if their validator misbehaves. For more, see [Risks](#risks) section. @@ -85,7 +85,7 @@ The `DisableTokenizeShares` message is exposed by the staking module and can be gaiad tx staking disable-tokenize-shares --from mykey ``` -When tokenization is disabled, a lock is placed on the account, effectively preventing the tokenization of any delegations. Re-enabling tokenization would initiate the removal of the lock, but the process is not immediate. The lock removal is queued, with the lock itself persisting throughout the unbonding period. Following the completion of the unbonding period, the lock would be completely removed, restoring the account's ablility to tokenize. For liquid staking protocols that enable the lock, this delay better positions the base layer to coordinate a recovery in the event of an exploit. +When tokenization is disabled, a lock is placed on the account, effectively preventing the tokenization of any delegations. Re-enabling tokenization would initiate the removal of the lock, but the process is not immediate. The lock removal is queued, with the lock itself persisting throughout the unbonding period. Following the completion of the unbonding period, the lock would be completely removed, restoring the account's ability to tokenize. For liquid staking protocols that enable the lock, this delay better positions the base layer to coordinate a recovery in the event of an exploit. ## Risks diff --git a/docs/docs/hub-tutorials/upgrade-node.md b/docs/docs/hub-tutorials/upgrade-node.md index 80f39730da5..9167bb8e398 100644 --- a/docs/docs/hub-tutorials/upgrade-node.md +++ b/docs/docs/hub-tutorials/upgrade-node.md @@ -118,7 +118,7 @@ cp -f genesis.json new_genesis.json mv new_genesis.json genesis.json ``` -At this point, you might want to run a script to update the exported genesis into a genesis that is compatible with your new version. For example, the attributes of a the `Account` type changed, a script should query encoded account from the account store, unmarshall them, update their type, re-marshal and re-store them. You can find an example of such script [here](https://github.com/cosmos/cosmos-sdk/blob/02c6c9fafd58da88550ab4d7d494724a477c8a68/contrib/migrate/v0.33.x-to-v0.34.0.py). +At this point, you might want to run a script to update the exported genesis into a genesis that is compatible with your new version. For example, the attributes of the `Account` type changed, a script should query encoded account from the account store, unmarshal them, update their type, re-marshal and re-store them. You can find an example of such script [here](https://github.com/cosmos/cosmos-sdk/blob/02c6c9fafd58da88550ab4d7d494724a477c8a68/contrib/migrate/v0.33.x-to-v0.34.0.py). ## Reset Data