Merge pull request #496 from HubertIGL/main

Fix typos and improve clarity in documentation

docs/staking-modules/csm/guides/unbonded-validators.md

@@ -15,7 +15,7 @@ There are two types of the unbonded validator keys:
 - **Not yet deposited but unbonded keys.** In this case, unbonded validator keys are marked as non-depositable until the Node Operator tops up the [bond](../join-csm#bond) to make it sufficient to cover them.
 - **Unbonded and deposited validator keys.**  In this case, all unbonded and deposited keys will be requested to exit in the upcoming VEBO reports.
 
-Given the picture above, one may see that in case of an insufficient bond [bond](../join-csm#bond), the very last uploaded keys are considered unbonded. Non-deposited keys will be regarded as unbonded first to avoid unnecessary exit requests. At the same time, if there are no non-deposited keys or the unbonded keys count exceeds the number of non-deposited keys, it is up to VEBO to decide on the particular keys to be requested for exit. CSM can only report the number of the deposited keys to be exited to VEBO but not the actual keys.
+Given the picture above, one may see that in case of an insufficient [bond](../join-csm#bond), the very last uploaded keys are considered unbonded. Non-deposited keys will be regarded as unbonded first to avoid unnecessary exit requests. At the same time, if there are no non-deposited keys or the unbonded keys count exceeds the number of non-deposited keys, it is up to VEBO to decide on the particular keys to be requested for exit. CSM can only report the number of the deposited keys to be exited to VEBO but not the actual keys.
 
 
 ## How to avoid the emergence of unbonded keys and further exit requests?

docs/staking-modules/csm/join-csm.md

@@ -9,7 +9,7 @@ CSM accepts deposit data in the same [format](/contracts/node-operators-registry
 
 [`deposit signature`](https://github.com/ethereum/consensus-specs/blob/v1.4.0/specs/phase0/beacon-chain.md#signingdata) **must** sign the root of the `(deposit_message, domain)`. Where a `domain` is used to identify the chain, and `deposit_message` has the form of the following tuple:
 - `validator pubkey`;
-- `withdrawal_credentials` with actual [`Lido Withdrawal Vault contract`](/contracts/withdrawal-vault) address. Should be retrieved from [Staring Router](/contracts/staking-router.md#getwithdrawalcredentials);
+- `withdrawal_credentials` with actual [`Lido Withdrawal Vault contract`](/contracts/withdrawal-vault) address. Should be retrieved from [Staking Router](/contracts/staking-router.md#getwithdrawalcredentials);
 - `32 ETH amount`;
 
 ## Bond

docs/token-guides/steth-superuser-functions.md

@@ -28,7 +28,7 @@ Note that there are other roles for DAO management, but they don't affect the to
 
 ## Oracle rebasing reports
 
-StETH is a rebasable token. It receives reports from the Oracle contract (`handleOracleReport` method) with the state of the protocol's Consensus Layer validators balances, and updates all the balances of stETH holders distributing the protocol's total staking rewards and penalties. The protocol employs distributed Oracle reporting: there are five Oracle daemons running by the Lido Node operators, and the Oracle smart contract formats beacon report on the consensus of three of five daemon reports. On top of the consensus mechanics, there are sanity checks for reports with sudden drops in total Consensus Layer balance or rewards with higher-than-possible APY. Current Oracle contract is [https://etherscan.io/address/0x442af784A788A5bd6F42A01Ebe9F287a871243fb](https://etherscan.io/address/0x442af784A788A5bd6F42A01Ebe9F287a871243fb). Note that: 1) DAO can set another address for the Oracle contact via vote; 2) Oracle implementation can change via vote.
+StETH is a rebasable token. It receives reports from the Oracle contract (`handleOracleReport` method) with the state of the protocol's Consensus Layer validators balances, and updates all the balances of stETH holders distributing the protocol's total staking rewards and penalties. The protocol employs distributed Oracle reporting: there are five Oracle daemons running by the Lido Node operators, and the Oracle smart contract formats beacon report on the consensus of three of five daemon reports. On top of the consensus mechanics, there are sanity checks for reports with sudden drops in total Consensus Layer balance or rewards with higher-than-possible APY. Current Oracle contract is [https://etherscan.io/address/0x442af784A788A5bd6F42A01Ebe9F287a871243fb](https://etherscan.io/address/0x442af784A788A5bd6F42A01Ebe9F287a871243fb). Note that: 1) DAO can set another address for the Oracle contract via vote; 2) Oracle implementation can change via vote.
 
 ## Superuser privileges decentralization