LaconicNetwork/cosmos-sdk
7
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

chore(x/staking): fix some README typos (#17997)

Browse Source
This commit is contained in:
Emmanuel T Odeke
2023-10-07 04:59:09 +00:00
committed by GitHub
parent c325cbf004
commit 9053582132
1 changed files with 25 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
x/staking/README.md
+8 -8
View File
@@ -82,7 +82,7 @@ The values are overwritten in every block.
### UnbondingID
UnbondingID stores the ID of the latest unbonding operation. It enables to create unique IDs for unbonding operation, i.e., UnbondingID is incremented every time a new unbonding operation (validator unbonding, unbonding delegation, redelegation) is initiated.
UnbondingID stores the ID of the latest unbonding operation. It enables creating unique IDs for unbonding operations, i.e., UnbondingID is incremented every time a new unbonding operation (validator unbonding, unbonding delegation, redelegation) is initiated.
* UnbondingID: `0x37 -> uint64`
@@ -115,7 +115,7 @@ Validators can have one of three statuses
before their tokens are moved to their accounts from the `BondedPool`.
:::warning
Tombstoning is permanent, once tombstoned a validators consensus key can not be reused within the chain where the tombstoning happened.
Tombstoning is permanent, once tombstoned a validator's consensus key can not be reused within the chain where the tombstoning happened.
:::
Validators objects should be primarily stored and accessed by the
@@ -182,7 +182,7 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/staking/v1bet
#### Delegator Shares
When one Delegates tokens to a Validator they are issued a number of delegator shares based on a
When one delegates tokens to a Validator, they are issued a number of delegator shares based on a
dynamic exchange rate, calculated as follows from the total number of tokens delegated to the
validator and the number of shares issued so far:
@@ -196,7 +196,7 @@ hold and the inverse exchange rate:
These `Shares` are simply an accounting mechanism. They are not a fungible asset. The reason for
this mechanism is to simplify the accounting around slashing. Rather than iteratively slashing the
tokens of every delegation entry, instead the Validators total bonded tokens can be slashed,
tokens of every delegation entry, instead the Validator's total bonded tokens can be slashed,
effectively reducing the value of each issued delegator share.
### UnbondingDelegation
@@ -272,13 +272,13 @@ https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/proto/cosmos/staking/v1bet
### Queues
All queues objects are sorted by timestamp. The time used within any queue is
first rounded to the nearest nanosecond then sorted. The sortable time format
All queue objects are sorted by timestamp. The time used within any queue is
firstly converted to UTC, rounded to the nearest nanosecond then sorted. The sortable time format
used is a slight modification of the RFC3339Nano and uses the format string
`"2006-01-02T15:04:05.000000000"`. Notably this format:
* right pads all zeros
* drops the time zone info (uses UTC)
* drops the time zone info (we already use UTC)
In all cases, the stored timestamp represents the maturation time of the queue
element.
@@ -312,7 +312,7 @@ queue is kept.
* ValidatorQueueTime: `0x43 | format(time) -> []sdk.ValAddress`
The stored object as each key is an array of validator operator addresses from
The stored object by each key is an array of validator operator addresses from
which the validator object can be accessed. Typically it is expected that only
a single validator record will be associated with a given timestamp however it is possible
that multiple validators exist in the queue at the same location.