Merge pull request #63 from osrm/dev

chore: fix typos and refine texts

contracts/docs/CnStakingV2.md

@@ -18,7 +18,7 @@ CnStakingV2 has built-in multisig facility that requires certain number of appro
 - `requirement`: the required number of approvals.
 - `isAdmin`: true for admins.
 
-## Contract intialization
+## Contract Initialization
 
 Initializing a CnStakingV2 takes multiple steps involving many entities.
 1. `constructor()`, usually by the `contractValidator`, or CV.
@@ -119,7 +119,7 @@ struct WithdrawalRequest {
 ```
 
 A withdrawal request can be in following `WithdrawalStakingState`
-- Unknown: before transfer or cancellation. Unlike `RequestState.Unknown`, `WithdrawalStakingState.Unknwon` is a meaningful enum.
+- Unknown: before transfer or cancellation. Unlike `RequestState.Unknown`, `WithdrawalStakingState.Unknown` is a meaningful enum.
 - Transferred: successfully executed.
 - Canceled: canceled due to timeout or an explicit cancellation.
 
@@ -139,7 +139,7 @@ Related functions:
 A Klaytn GC member uses several accounts for different purposes. Some of them are appointed via CnStakingV2 contract.
 
 Related functions:
-- `multisig UpdateRewardAddress(addr)`: Update the `rewardAddress` and also update to the AddressBook contract.
+- `multisig UpdateRewardAddress(addr)`: Update the `rewardAddress` and also update the AddressBook contract.
 - `multisig UpdateStakingTracker(addr)`: Update the `stakingTracker` address. CnStakingV2 contract notifies staking balance change and voter address change to the StakingTracker.
 - `multisig UpdateVoterAddress(addr)`: Update the `voterAddress` and also update to the StakingTracker contract.
 

contracts/docs/PublicDelegation.md

@@ -2,7 +2,7 @@
 
 The public delegation (PD) is a non-transferable ERC-4626 based contract that allows general users to delegate and re-delegate their KAIA to a Kaia Governance Council (GC) who uses CnStakingV3MultiSig (CnSV3) and enable PD.
 
-It mints the tokenized shares to the delegator, which is called `pdKAIA`. The `pdKAIA` is a non-transferable interest-bearing token that represents the delegator's share of the total KAIA delegated to the GC. As rewards are compunded, the exchange rate of `pdKAIA` to KAIA increases. The delegator can burn the `pdKAIA` to get the KAIA back. All the math comes from the ERC-4626 standard.
+It mints the tokenized shares to the delegator, which is called `pdKAIA`. The `pdKAIA` is a non-transferable interest-bearing token that represents the delegator's share of the total KAIA delegated to the GC. As rewards are compounded, the exchange rate of `pdKAIA` to KAIA increases. The delegator can burn the `pdKAIA` to get the KAIA back. All the math comes from the ERC-4626 standard.
 
 Unlike usual ERC-4626 vault contracts, the reward is directly distributed to PD contract by state modification at the consensus-level. The reward will be automatically compounded to the CnSV3 contract.
 

contracts/docs/voting.md

@@ -2,7 +2,7 @@
 
 ## Klaytn governance structure
 
-Klatyn as it is today is run by a permissioned validators called the Governance Council (GC). Each GC member run one Consensus Node (CN) to produce and validate blocks. The GC members also have authority to change Klaytn's network parameters such as gas price and block reward. Our governance contracts are trying to facilitate a transparent and stake-based voting by the GC members.
+Klaytn as it is today is run by a permissioned validators called the Governance Council (GC). Each GC member run one Consensus Node (CN) to produce and validate blocks. The GC members also have authority to change Klaytn's network parameters such as gas price and block reward. Our governance contracts are trying to facilitate a transparent and stake-based voting by the GC members.
 
 ### Voting power
 
@@ -38,7 +38,7 @@ The [KIP-81 as of 2022-11-09](https://github.com/klaytn/kips/blob/a1d99a58a60d0e
 
 ## Access Control
 
-Voting contract has two category of users, secretary and voters.
+Voting contract has two categories of users, secretary and voters.
 
 - The secretary is a single account stored in the `secretary` variable. This account is intended to be controlled by the Klaytn Foundation. It will serve the GC by assisting administrative works such as submitting and executing proposals.
 - Voters are identified by their `NodeID`. The list of voters differs per proposal, depending on the list of GC members registered in AddressBook and their staking amounts at the time of proposal submission.
@@ -62,7 +62,7 @@ Each function has different access control rule.
 
 In Klaytn there exists a on-chain governance system leveraging block headers ([docs](https://docs.klaytn.foundation/content/dapp/json-rpc/api-references/governance), [explainer in Korean](https://www.youtube.com/watch?v=UPyf7B0YvI0)). Major complaint about the existing system was that it takes 1 to 2 weeks for a parameter change to take effect ([example](https://medium.com/klaytn/klaytn-gas-price-reduction-schedule-2ba158e3630d))
 
-Therefore the Voting contract will allow each proposal to have custom timing. The `propose()` function accepts two timing paramters `votingDelay` and `votingPeriod`, given that they fall within the `timingRule` ranges.
+Therefore the Voting contract will allow each proposal to have custom timing. The `propose()` function accepts two timing parameters `votingDelay` and `votingPeriod`, given that they fall within the `timingRule` ranges.
 
 In the default setting, both `votingDelay` and `votingPeriod` are bound between 1 and 28 days. This makes the quickest proposal execution down to 4 days (1 day Pending, 1 day Active, 2 days Queued).