You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[A web interface](https://stvaults.{{landing}}/) for managing vaults without direct contract interaction. Vault owners can create and configure vaults, deposit and withdraw ETH, mint and repay stETH, and monitor vault health and performance.
9
+
10
+
11
+
### CLI
12
+
13
+
14
+
[A command-line toolkit](https://github.com/lidofinance/lido-staking-vault-cli) for operators and technical users. It supports the full range of vault operations: deployment, configuration, validator management, reward distribution, and withdrawal queue handling, with scripting and automation.
15
+
16
+
17
+
### VaultFactory
18
+
19
+
20
+
[Handles vault deployment in a single transaction](https://{{ethereum_docs}}/contracts/staking-vault-factory). It creates a StakingVault and its management Dashboard, initializes parameters, and sets permissions. Two paths are available: owner-initiated (connecting to VaultHub immediately after funding the 1 ETH deposit) or operator-initiated (creating the vault for later connection by the owner).
21
+
22
+
23
+
VaultHub accepts only factory-deployed vaults. Any other deployment is rejected, ensuring verified code and untampered storage.
Via the Lido protocol, stETH holders receive rewards (or penalties) from staking based on the performance of Lido-participating validators in Ethereum’s proof-of-stake network. As stETH is a rebasing token, rewards are continuously (on a daily basis) reflected in your stETH balance, providing a seamless staking experience. For users who prefer a value-accruing token approach, stETH can also be wrapped into wstETH.
@@ -10,41 +10,43 @@ content: >
10
10
11
11
:::
12
12
13
+
13
14
### How Rewards and Penalties Are Calculated
14
15
16
+
15
17
The Lido oracle mechanisms are responsible for maintaining the connection between the Execution Layer and Consensus Layer portions of the Lido protocol. As a part of this set of activities, oracles synchronize data between the Execution and Consensus Layers, reflecting validator rewards and penalties for stETH holders via the daily rebase mechanism.
16
18
17
19
18
20
Validators earn rewards by proposing and attesting to new blocks, activities critical to Ethereum’s security. Rewards and penalties are determined algorithmically by the Ethereum consensus mechanism and depend on factors like validator uptime, correctness, and timeliness of duty performance, and general network conditions. Validator rewards come in two forms:
19
21
20
-
- **Consensus Layer rewards**: Determined by network rules, these include block proposal and attestation rewards, distributed predictably based on validator performance.
21
-
22
-
- **Execution Layer rewards**: These dynamic rewards include transaction tips (priority fees) and possible Maximal Extractable Value (MEV) rewards, which depend on demand for blockspace, network congestion, and block building effectiveness.
22
+
23
+
* **Consensus Layer rewards**: Determined by network rules, these include block proposal and attestation rewards, distributed predictably based on validator performance.
24
+
25
+
* **Execution Layer rewards**: These dynamic rewards include transaction tips (priority fees) and possible Maximal Extractable Value (MEV) rewards, which depend on demand for blockspace, network congestion, and block building effectiveness.
23
26
24
27
25
28
> ##### MEV and Lido Validators
26
29
27
-
> MEV (Maximal Extractable Value) refers to additional rewards earned by validators through optimized transaction ordering in block proposals. Using tools such as MEV-Boost, validators can outsource block building activities to block builders and MEV searchers to capture extra value. For blocks proposed by Lido validators, MEV rewards are sent by builders to the Lido Execution Rewards Vault, meaning that this income benefits both node operators as well as stETH holders.
28
-
Validators follow block proposal requirements set by the Lido DAO, which guides which guides how stakers are rewarded while maintaining network fairness.
30
+
>
31
+
32
+
> MEV (Maximal Extractable Value) refers to additional rewards earned by validators through optimized transaction ordering in block proposals. Using tools such as MEV-Boost, validators can outsource block building activities to block builders and MEV searchers to capture extra value. For blocks proposed by Lido validators, MEV rewards are sent by builders to the Lido Execution Rewards Vault, meaning that this income benefits both node operators as well as stETH holders. Validators follow block proposal requirements set by the Lido DAO, which guides which guides how stakers are rewarded while maintaining network fairness.
29
33
30
34
31
35
#### stETH token rebase
32
36
37
+
33
38
The stETH balance updates automatically to reflect the portion of rewards earned or penalties incurred by the wider Lido validator set, ensuring that the staker's balance updates automatically without any required user action. This process, known as a token rebase, occurs daily around 12:30 UTC based on data provided by the Lido AccountingOracle, though the exact timing may vary.
34
39
35
40
36
41
The oracle report supplies the protocol with validator states, facilitates stETH withdrawal requests, and adjusts the total stETH supply (reflecting the rewards or penalties accrued by the validators underlying the protocol). The rebasing process algorithmically updates balances to account for:
37
42
38
43
39
-
- Staking rewards (or penalties, including possible slashings) from the Consensus Layer,
40
-
41
-
- Execution Layer rewards collected,
42
-
43
-
- Changes due to fulfilled withdrawal requests.
44
-
45
-
In Lido, stETH rebases using a shares-based system. Instead of tracking individual balances directly, the protocol records the share of the total pool owned by each account. Your balance is calculated as:
44
+
* Staking rewards (or penalties, including possible slashings) from the Consensus Layer,
46
45
46
+
* Execution Layer rewards collected,
47
47
48
+
* Changes due to fulfilled withdrawal requests.
49
+
In Lido, stETH rebases using a shares-based system. Instead of tracking individual balances directly, the protocol records the share of the total pool owned by each account. Your balance is calculated as:
48
50
49
51
> ```
50
52
@@ -55,17 +57,19 @@ content: >
55
57
56
58
#### Oracles
57
59
60
+
58
61
The Lido protocol utilizes oracles to bridge the communication gap between Ethereum’s Execution Layer, where the Lido smart contracts reside, and the Consensus Layer, where validators function. This mechanism is required due to the limited native channels between the two layers. Oracles supply the protocol with real-time validator states, balances, and additional off-chain data necessary for protocol functionality.
59
62
60
63
61
64
Oracles work by gathering data using deterministic algorithms, with a quorum of 5 out of 9 participants required to validate and deliver reports to the protocol. Built-in safety mechanisms verify Oracle data to prevent disruptions caused by anomalies or malicious inputs.
62
65
63
-
64
66
Key oracles in the protocol include:
65
67
66
-
- **AccountingOracle**: Handles updates to the protocol’s accounting balances, including rewards, penalties, withdrawal finalization, and historical data. Reports are generated daily around 12:30 UTC.
68
+
* **AccountingOracle**: Handles updates to the protocol’s accounting balances, including rewards, penalties, withdrawal finalization, and historical data. Reports are generated daily around 12:30 UTC.
69
+
70
+
* **ValidatorsExitBusOracle**: Alerts node operators to initiate validator exits, enabling users to withdraw ETH. Reports are provided three times daily, approximately at 12:30, 20:30, and 4:30 UTC.
67
71
68
-
- **ValidatorsExitBusOracle**: Alerts node operators to initiate validator exits, enabling users to withdraw ETH. Reports are provided three times daily, approximately at 12:30, 20:30, and 4:30 UTC.
72
+
* **CSM Performance Oracle**: Dedicated to *the* Community Staking Module (CSM), it tracks detailed node operator performance metrics to fairly distribute rewards based on participation.
69
73
70
-
- **CSM Performance Oracle**: Dedicated to *the* Community Staking Module (CSM), it tracks detailed node operator performance metrics to fairly distribute rewards based on participation.
74
+
* **stVaults LazyOracle**: Handles accounting report for stVaults. It uses an on-demand approach that allows the protocol to support an unlimited amount of stVaults. AccountingOracle supplies the Merkle root of all vaults’ state, while individual stVault updates happen on-demand permissionlessly.
Staking through stVaults involves several risk categories. Each has
6
+
corresponding mitigations built into the protocol design:
7
+
8
+
:::big-space
9
+
10
+
:::
11
+
12
+
### Slashing and Operational Risk
13
+
14
+
15
+
Validators can be penalized if they violate network rules, for example by signing conflicting messages, or if they stay offline for extended periods. If several validators run by the same operator fail at the same time, the losses can snowball because Ethereum increases penalties for correlated failures. Even without slashing, long downtime reduces rewards, which degrades the vault’s performance over time.
16
+
17
+
18
+
The Reserve Ratio is a key safeguard intended to reduce slashing-related risk. It sets how much of a vault’s ETH must stay as a buffer when minting stETH. For example, with 100 ETH and a 10% reserve ratio, the vault can mint up to 90 stETH and keep 10 ETH in reserve. That reserve is meant to absorb losses first if slashing happens, though it cannot guarantee protection in every scenario. The ratio is set based on the operator’s risk profile, total stake, external exposures, and Ethereum’s correlated-penalty mechanics.
19
+
20
+
21
+
Two additional requirements apply: the connect deposit (1 ETH) prevents spam vaults, and the slashing reserve locks extra ETH when validators are undergoing active slashing.
22
+
23
+
:::big-space
24
+
25
+
:::
26
+
27
+
### Concentration Risk
28
+
29
+
30
+
Large operators create a bigger systemic risk. If one operator holds a lot of stake and several of its validators get slashed at the same time, the resulting losses can be large enough to matter beyond a single vault.
31
+
32
+
33
+
OperatorGrid is the mechanism designed to reduce that concentration risk. It groups vaults into tiers with different reserve ratios, share limits, and fee rates. New vaults start in the default tier with a high reserve ratio (currently 50%). Operators with an established track record can register custom groups where higher tiers require more reserve as the operator’s total stake grows.
34
+
35
+
36
+
The intent is to add economic friction against centralization. As an operator’s exposure increases, collateral requirements increase too, which can make smaller operators more attractive. Early stakers keep the terms they entered with, so a Tier 1 vault keeps Tier 1 conditions even if the operator later grows into Tier 3.
37
+
38
+
:::big-space
39
+
40
+
:::
41
+
42
+
### Undercollateralization
43
+
44
+
45
+
A vault can become undercollateralized if losses or weak performance reduce its ETH value. Slashing, penalties, and extended downtime can all push collateral below required levels of backing for minted stETH.
46
+
47
+
48
+
The Health Factor measures whether collateral is sufficient:
49
+
50
+
51
+
> Health Factor = Total Value × (1 − Forced Rebalance Threshold)/stETH Liability
52
+
53
+
54
+
At or above 100%, the vault is adequately collateralized. Below 100%, the vault is past its target buffer and needs to be restored.
55
+
56
+
57
+
VaultHub tracks obligations in priority order: health obligations (liability shares that can trigger force-rebalancing), redemption obligations (the vault’s contribution to system-wide stETH redemptions), and fee obligations (outstanding protocol fees). These obligations limit withdrawals and reduce how much new stETH can be minted.
58
+
59
+
60
+
Corrective measures: the vault owner can add more ETH, repay stETH liability, or rebalance by sending ETH to the Core Pool in exchange for reducing liability. If the reserve falls below the Forced Rebalance Threshold, permissionless rebalancing becomes available. The threshold is set slightly below the reserve ratio (for example, 49.75% vs 50%) to avoid triggering on small fluctuations. If the ETH is still on the consensus layer, EIP-7002 can enable forced validator withdrawals.
61
+
62
+
63
+
Bad debt escalation: if losses get so large that the vault’s ETH value drops below its stETH liability, the system follows an escalation path. First, the vault owner is expected to top up. If that does not happen, losses can be spread across the operator’s other vaults, then covered by any available insurance or coverage. As a last resort, remaining losses can be absorbed at the protocol level by reducing stETH rebase. Governance can also jail a vault to halt new minting while the issue is addressed.
64
+
65
+
:::big-space
66
+
67
+
:::
68
+
69
+
### Oracle Risk
70
+
71
+
72
+
stVaults depend on oracle accounting. If reports are wrong or delayed, vault health can be misread. That can lead to unnecessary rebalancing, or in the other direction, allow minting when collateral is weaker than it appears.
73
+
74
+
75
+
LazyOracle is the control layer designed to reduce that risk. It publishes accounting reports with total value, validator states, and accumulated rewards or penalties. Suspicious value increases are quarantined for three days before being credited, which helps limit manipulation. If reports go stale, minting and withdrawals are restricted until fresh data is posted.
76
+
77
+
:::big-space
78
+
79
+
:::
80
+
81
+
### Governance Risk
82
+
83
+
84
+
The DAO can upgrade vault code and change protocol parameters. If governance is ever compromised, those powers could be used in ways that hurt vault owners, such as raising collateral requirements or changing fees.
85
+
86
+
87
+
If a vault has no outstanding stETH, the owner can disconnect from VaultHub and permanently freeze the vault's code by pinning the current implementation address. The vault then operates fully under owner control, rejecting any future DAO upgrades at the cost of losing the ability to reconnect to the Lido protocol.
88
+
89
+
:::big-space
90
+
91
+
:::
92
+
93
+
### Deposit Frontrunning Risk
94
+
95
+
96
+
During validator deposits, a malicious operator could try to front-run the transaction and submit a deposit with different withdrawal credentials, effectively redirecting the withdrawals.
97
+
98
+
99
+
PredepositGuarantee’s bond requirement is intended to discourage this attack. Validator activation starts with a 1 ETH deposit, and the operator must post a matching 1 ETH bond for each validator. Once the validator is live, the operator proves the withdrawal credentials point to the vault. If the proof is correct, the bond is released back to the operator. If not, the bond is confiscated and paid to the vault.
100
+
101
+
:::big-space
102
+
103
+
:::
104
+
105
+
### Liquidity Risk
106
+
107
+
108
+
During market stress, many holders may try to redeem stETH at once, which can strain liquidity and slow withdrawals.
109
+
110
+
111
+
The Core Pool is the main shared buffer used to process redemptions. Liquidity fees and limits on how large stVaults can grow relative to the Core Pool are designed to keep that buffer healthy. In more extreme conditions, vaults can be required to contribute ETH to support system-wide redemptions.
112
+
113
+
:::big-space
114
+
115
+
:::
116
+
117
+
### Smart Contract Risk
118
+
119
+
120
+
Undiscovered bugs are still possible, especially given the number of moving parts and integrations across vaults, VaultHub, oracles, and external protocols.
121
+
122
+
123
+
Comprehensive auditing, formal verification where applicable, and upgradeability mechanisms reduce the risk surface for stVaults. The sovereignty mechanisms also limit the blast radius of any potential problems: vault owners can isolate themselves from protocol-level issues.
124
+
125
+
:::big-space
126
+
127
+
:::
128
+
129
+
### Risk Distribution
130
+
131
+
132
+
**Vault owners** bear primary risk: their collateral absorbs losses first, and they are responsible for maintaining adequate vault health.
133
+
134
+
135
+
**Node operators** bear reputational and economic risk: poor performance leads to higher reserve requirements in subsequent tiers, and bad debt can be socialized across all their vaults.
136
+
137
+
138
+
**stETH holders** benefit from overcollateralization. Only after all escalation steps are exhausted can vault-specific losses affect stETH supply through bad debt internalization.
0 commit comments