From a3044f5a228022dac23f2191cf4381e1ef7b7b05 Mon Sep 17 00:00:00 2001 From: Huberto <161350311+HubertIGL@users.noreply.github.com> Date: Tue, 24 Dec 2024 14:40:43 +0100 Subject: [PATCH 1/3] Update unbonded-validators.md --- docs/staking-modules/csm/guides/unbonded-validators.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/staking-modules/csm/guides/unbonded-validators.md b/docs/staking-modules/csm/guides/unbonded-validators.md index 4a5b28cdb..0818ee615 100644 --- a/docs/staking-modules/csm/guides/unbonded-validators.md +++ b/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? From 7c7e66863885402749be0c1dff03e1e26e189455 Mon Sep 17 00:00:00 2001 From: Huberto <161350311+HubertIGL@users.noreply.github.com> Date: Tue, 24 Dec 2024 14:42:35 +0100 Subject: [PATCH 2/3] Update join-csm.md --- docs/staking-modules/csm/join-csm.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/staking-modules/csm/join-csm.md b/docs/staking-modules/csm/join-csm.md index 057b2d5cf..ef2ee08c9 100644 --- a/docs/staking-modules/csm/join-csm.md +++ b/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 From 3d855d2cfadfcca821ff284994609074aa22c167 Mon Sep 17 00:00:00 2001 From: Huberto <161350311+HubertIGL@users.noreply.github.com> Date: Tue, 24 Dec 2024 14:46:21 +0100 Subject: [PATCH 3/3] Update steth-superuser-functions.md --- docs/token-guides/steth-superuser-functions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/token-guides/steth-superuser-functions.md b/docs/token-guides/steth-superuser-functions.md index e7795a892..dfc6ce079 100644 --- a/docs/token-guides/steth-superuser-functions.md +++ b/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