Skip to main content

How Vaults Work

Every Vault has a Vault operator responsible for its validators. The operator runs the infrastructure directly or delegates it to a third party. Operating a Vault means running the Operator Service ↗ — StakeWise software that automates a Vault's day-to-day operations — alongside Ethereum consensus and execution clients.

Every Vault action — deposits, validator registration, reward distribution, and withdrawals — is executed on-chain by the Vault's smart contracts. The Operator Service runs off-chain and initiates these on-chain calls automatically. The sections below walk through each stage.

Deposits​

When a user deposits ETH, the Vault issues shares representing their proportional ownership of the pool's assets. Share value increases automatically as rewards accumulate — no token swaps or conversions occur during staking. Shares are non-transferable, except in ERC-20 Vaults, where they are issued as a tradable token.

Each Vault has a configurable capacity — deposits of any size are accepted up to that limit. Some Vaults restrict who can deposit: private Vaults accept deposits only from whitelisted addresses, while blocklist Vaults prohibit blocklisted wallets.

Depositors can also mint osETH against their stake — a liquid token usable across DeFi while the underlying stake keeps earning rewards. osETH grows in value over time: each osETH is redeemable for more ETH as staking rewards accrue. How much osETH a user can mint depends on the Vault's LTV ratio.

Validator Registration​

Vaults pool deposits and register validators on the Beacon Chain once they accumulate enough assets — 32 ETH on Ethereum, 1 GNO on Gnosis.

The Operator Service monitors Vault balances and submits validator registration requests to the StakeWise Oracle network. Each registration requires approval from 6 of 11 Oracles before it is submitted on-chain. Deposit data is generated automatically during registration. Once approved, validators enter the Beacon Chain's activation queue ↗ and begin earning rewards when active.

The Pectra ↗ upgrade (EIP-7251 ↗) raised the maximum validator balance from 32 ETH to 2048 ETH, enabling consolidation — merging many 0x01 validators1 (capped at 32 ETH) into fewer high-balance 0x02 ones (up to 2048 ETH) to reduce infrastructure overhead and allow partial withdrawals of rewards above 32 ETH without exiting.

The Operator Service registers new validators as 0x02 by default, and existing 0x01 validators can be migrated via consolidation. When registering, the Operator Service prioritizes funding existing 0x02 validators — selecting those with the highest current balance and topping them up to 2048 ETH before creating new ones.

IconValidator Registration Process

The Operator Service performs the following steps:

  1. Check if the Vault has enough assets to register a validator (32 ETH for Ethereum).
  2. Get the next free validator key from the used keystore.
  3. Obtain the BLS signature for exit messages2 using local keystores or a remote signer.
  4. Share the validator's exit signature with StakeWise Oracles:
    • Split the BLS signature3 using Shamir's Secret Sharing ↗ (number of shares = number of Oracles).
    • Encrypt each signature share with the corresponding Oracle's public key.
    • Send the encrypted shares to all Oracles and receive registration signatures in return.
  5. Submit a transaction to the Vault contract to register the validator.

Reward Distribution​

Once active, validators earn:

  • Consensus-layer rewards — for block proposals, attestations, and sync-committee participation.
  • Execution-layer rewards — MEV ↗ and transaction priority fees.

These rewards are calculated off-chain by the StakeWise Oracle network every 12 hours: Oracles publish per-Vault rewards to an IPFS hash ↗, build a Merkle tree over that data, and submit a signed Merkle root to the Keeper contract ↗, which verifies the signatures and stores the root.

Each Vault then pulls in its own rewards through a harvest.

IconHarvest Mechanics

A harvest does the following:

  1. Verifies the proof. The Keeper contract checks the Vault proof for its claimed rewards against the stored root.
  2. Calculates new rewards. Rewards are tracked as a running total, so subtracting the previous total leaves what the Vault has earned (or lost) since its last harvest.
  3. Moves MEV rewards into the Vault. Execution rewards sit in a MEV escrow; the Vault pulls them in.
  4. Applies the change. The Vault's total assets are computed and per-share value is updated; on gains only, the Vault fee is minted to the fee recipient as new shares.
  5. Processes the exit queue. The Vault marks how much of the exit queue is now covered by available assets and makes them claimable.

The Vault then decides what to do with that ETH:

  • Top-up — add ETH to existing 0x02 validators, growing their effective balance up to the 2048 ETH maximum.
  • Consolidate — merge multiple 0x01 validators into a single 0x02 validator (0x01 + 0x01 → 0x02).
  • Keep ETH as-is — leave the ETH in the Vault for greater liquidity.

Withdrawals​

Every 12 hours, the Operator Service:

  1. Checks available ETH — unbonded ETH already in the Vault (deposits + unallocated rewards) and harvested MEV.
  2. Triggers partial withdrawals from 0x02 compound validators via EIP-7002 ↗ if more ETH is needed.
  3. Triggers full validator exits through a Vault contract call if partial withdrawals are insufficient.
IconOracle Fallback

If the Operator Service fails to trigger exits within 24 hours, StakeWise Oracles execute them automatically using exit signatures pre-committed at registration.

When a user clicks Unstake or Unboost in the StakeWise interface:

  1. enterExitQueue is called on the Vault contract — for boosted positions, the call is routed through the Boost proxy.
  2. The user enters the Vault's exit queue — a first-in, first-out line fulfilled as ETH becomes available.
  3. The user's position is tracked by an exit queue ticket, which is filled in whole or in part from that ETH; if filled partially, an updated ticket is issued for the remainder.
  4. Once a ticket is fully filled, the user calls claimExitedAssets (after a short claim delay) to withdraw the ETH.

Staked assets continue earning rewards until validators complete the exit. Once a validator fully exits, its balance is swept ↗ to the Vault and becomes claimable by users in ticket order. Exit processing time depends on Ethereum network conditions — check the current validator queue ↗ for up-to-date estimates.

1. 0x01 and 0x02 refer to withdrawal credential types that determine validator capabilities. 0x01 validators (Type 1) use the 32 ETH limit with automatic sweeps of excess balance. 0x02 validators (Type 2) support effective balances up to 2048 ETH with compounding rewards and partial withdrawals. Converting from 0x01 to 0x02 is irreversible. ↩

2. Validators in Ethereum use two sets of BLS keys: validator keys (hot) and withdrawal keys (cold). Validator keys sign attestations, blocks, and exits (e.g., SignedVoluntaryExit), while withdrawal keys secure the eventual withdrawal of stake and rewards. ↩

3. BLS (Boneh–Lynn–Shacham) is a digital signature scheme introduced in 2001. It relies on the hardness of the Computational Diffie–Hellman (CDH) problem to prevent forgery. A user selects a secret key and derives the corresponding public key on an elliptic curve. To sign, the message is hashed to a curve point and multiplied by the secret key, producing the signature. Verification uses a bilinear pairing to confirm validity. Learn more about BLS signatures here. ↩

Last updated on