Skip to content

Commit

Permalink
Docs fix spelling issues (#3378)
Browse files Browse the repository at this point in the history
* Update adr-template.md

* Update delegator-faq.md

* Update upgrade-node.md

---------

Co-authored-by: Philip Offtermatt <[email protected]>
  • Loading branch information
nnsW3 and p-offtermatt authored Oct 14, 2024
1 parent 74a3814 commit 76e3448
Show file tree
Hide file tree
Showing 3 changed files with 4 additions and 4 deletions.
2 changes: 1 addition & 1 deletion docs/docs/architecture/templates/adr-template.md
Original file line number Diff line number Diff line change
Expand Up @@ -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}
4 changes: 2 additions & 2 deletions docs/docs/delegators/delegator-faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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

Expand Down
2 changes: 1 addition & 1 deletion docs/docs/hub-tutorials/upgrade-node.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down

0 comments on commit 76e3448

Please sign in to comment.