Staking vaults

A staking vault is the Lido v3 contract managing liquid and staked ETH and acts as the single entry point for everything you can do with that stake. Northstake exposes one vault per row on the Vaults page.

Vaults come in two shapes.

Dedicated vaults

A dedicated vault has a single owner. Only the owner (and roles delegated by the owner) can fund the vault, trigger validator operations, or withdraw. This is the default shape for stakers.

You'll see dedicated vaults in both SVM and SVM Pro.

Pool vaults

A pool vault accepts deposits from multiple parties. Depositors receive LP tokens proportional to their share; the vault's underlying validators are operated jointly. Two sub-types exist (stv and stvSteth), and pools can optionally restrict deposits to an allowlist.

⚠️

Pro only: pool vaults are an SVM Pro feature. Creating, configuring, or running a pool vault requires an SVM Pro account.

See Staking pools for more on staking pools.

The contracts behind a vault

The creation of a new stVault results in the deployment of multiple smart contracts. The number and type of smart contracts deployed depend on the type of vault created - dedicated, STV pool, or STV stETH Pool. The table below presents an overview:

🖱️

to see contract addresses in the UI: open the Addresses tab of a vault page to see all deployed contracts.

</> to fetch the contract addresses via the API: see getLidoStakingContracts. The response includes a contracts object with each deployed address.

Choosing a vault type

How stVaults work

Every interaction with a vault (funding, minting, burning) is routed through the Dashboard contract. The Dashboard is often defined as the "UX" contract; it routes contract calls to the Staking Vault, the VaultHub, and (for pools) the Pool and Withdrawal Queue.

Funding: ETH enters the vault through the Dashboard. Once funded, the balance sits in the Staking Vault until it's staked into validators or used as collateral.

🖱️

to deposit ETH in the UI: click Deposit on the Vaults page, choose a vault, enter the amount, review, and sign.

</> to deposit ETH via the API: see fundVault. Pool vaults also accept a sharesRecipient (the address that receives pool shares).

Minting and burning stETH. The staked balance plus any liquid ETH in the vault can be used as collateral to mint stETH against the vault. Mints and burns both go through the Dashboard. Each mint increases the vault's liability shares (its outstanding stETH debt) which has to be burned (or covered at withdrawal) before the underlying ETH can leave.

🖱️

to mint or burn stETH in the UI

From a vault page, use the Mint action button (pick stETH or wstETH) or Burn. To Burn stETH or wstETH you will need to sign two transactions: an approval to set the vault Dashboard as the spender of an allowance, and the burn transaction.

</> to mint or burn stETH via the API

Mint: mintStETH or mintWstETH

Burn (two transactions): approveBurnStETH or approveBurnWstETH, then burnStETH or burnWstETH.

Periodic updates. The vault's accounting is refreshed on a schedule so validator rewards and outstanding liabilities are reflected on-chain. Until an update lands, the on-chain accounting might lag the actual accounting.

🖱️

to update the vault report in the UI: the funding, minting, and burning flows automatically prompt an Update report transaction whenever the on-chain report is stale.

</> to update the vault report via the API: see getLazyOracleReportCallData. Returns calldata for the lazy oracle's updateVaultData call.

ℹ️

Staking: creating and exiting validators is a separate lifecycle from funding and minting. See Validator lifecycle.

Vault health

Minting stETH against a vault turns part of its ETH into collateral. Vault health measures the headroom between what the vault owes (its stETH liability) and what it's worth (its total value). Every vault that has minted stETH has a health factor; a vault that has never minted carries no liability and no health constraint.

The health factor

The health factor (HF) is the headline number: the ratio of the vault's value to its liability, scaled by the protocol's forced-rebalance threshold.

HF = (totalValue / liabilityStETH) × (1 − forcedRebalanceThresholdBP / 10000) × 100%

• HF ≥ 100% — healthy. The liability sits under the collateral the protocol requires.
• HF < 100% — the forced-rebalance threshold is breached and the vault can be rebalanced by anyone (see below).

totalValue is the vault's total assets (staked + liquid ETH + accrued rewards) from the latest oracle report. liabilityStETH is the ETH value of the stETH the vault has minted. forcedRebalanceThresholdBP is a per-tier parameter on the operator grid (e.g. 4950 = 49.5%); a tighter tier means a lower threshold, and so a lower health factor for the same position.

ℹ️

Constant in shares, growing in stETH. A mint records a fixed number of liability shares, not a fixed amount of stETH. Because stETH rebases — it accrues staking rewards over time — the ETH per share grows even though the share count doesn't. A vault's liability, and the ETH locked to back it, therefore creeps up on its own, which is why a position that looked comfortable can drift toward the threshold with no new minting. Burning reduces the share count; rebalancing reduces both shares and ETH at once.

Locked vs. unlocked ETH

stETH can be minted in proportion to the total value of a stVault and up to the vault's reserve ratio (reserveRatioBP). The reserve ratio affects also the vault's withdrawable/locked ETH.

lockedETH = liabilityStETH + liabilityStETH × reserveRatioBP / (10000 − reserveRatioBP)

withdrawableValue = totalValue − lockedETH − unsettledFees

A 30% reserve ratio, for example, locks roughly 1.43 ETH for every 1 stETH minted. Locked ETH can't be withdrawn or used to mint more; only the unlocked remainder — withdrawableValue, after reserves and unsettled fees — is free to leave. This is the constraint behind Staking withdrawals: you can only withdraw unlocked ETH. The reserve ratio also fixes the vault's minting capacity, the cap on how much stETH it can mint against its value (remainingMintingCapacityStETH is what's left).

What happens when a vault is unhealthy

When the health factor falls below 100%, the liability has outgrown its collateral and the vault becomes eligible for forced rebalance: any address can call forceRebalance on the VaultHub, which spends the vault's own liquid ETH to repay stETH liability until health is restored. You don't choose the timing or the amount — the protocol does.

A rebalance repays stETH liability with the vault's ETH, lowering both Total Value and Minted stETH and raising the health factor. The forced version and the one you run yourself are the same on-chain mechanism; the only difference is who triggers it and when. Running it yourself (Rebalance a vault) lets you control the amount and keep a buffer; waiting for the forced version cedes that control.

In the UI this surfaces as the Vault Health badge — Healthy (HF ≥ 125%), Warning (100–125%), At risk (< 100%). See Vault metrics for the full bands and where to read each number.

Avoiding forced rebalance

Forced rebalance is avoidable with a margin of safety:

• Keep a buffer. Don't operate at the edge of 100%. Treat the Warning band (HF < 125%) as the signal to act, and after any rebalance aim for a target like 110–115% rather than barely clearing 100%.
• Don't mint to the limit. Each mint lowers the health factor immediately; leave some minting capacity unused as headroom, and check the post-mint projection before signing.
• Watch the drift. Because liability grows in stETH terms on its own, monitor health even when you're not transacting — and remember that moving to a tighter operator-grid tier (a lower forcedRebalanceThresholdBP) drops the health factor the moment it takes effect.
• Recover early. Burn stETH, add ETH, or rebalance while you still hold a comfortable buffer. The three options are compared in Rebalance a vault.

Related

• Staking pools: sub-types, configuration, allowlist
• Validator lifecycle
• Withdrawals
• Fee model