Skip to main content

How Vaults Work

Validator registration​

Vaults collect user deposits and manage the validator lifecycle through smart contracts. When a Vault accumulates enough assets — 32 ETH on Ethereum or 1 GNO on Gnosis — the system initiates validator registration.

The Vault operator
runs specialized software (the operator ↗ service) alongside their Ethereum consensus → and execution → clients that monitor deposit levels and handle the technical validator setup process.

When sufficient funds are available, this service submits validator registration requests to the StakeWise Oracle network →. The Operator Service must receive 8 out of 11 approvals from Oracles to register a validator for the Vault. The service automatically generates deposit data during registration, eliminating the need for pre-uploaded deposit data files. Once approved, validators enter the Beacon Chain's activation queue. Network ↗ conditions determine how quickly they begin earning staking rewards.

Vaults support two types of validators: 0x01 or 0x021. The default type is 0x02. When registering validators, the Operator Service prioritizes funding existing 0x02 validators by selecting those with the highest current balance and topping them up to 2048 ETH before creating new validators.

The technical process for registering validators involves coordination between the Operator Service → and the Oracle network →:

IconValidator Registration Process

The Operator Service performs the following steps:

  1. Check if the Vault has enough assets to register a validator (e.g., 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.

Vaults can have several node operators running validators and support

Distributed Validator Technology
(DVT) to increase redundancy.

IconDeep Dive

For more details on how Oracles handle the validator registration approval process, see Validator Registration Approval →.

Reward Distribution​

Once validators are registered and active, they earn:

  • Consensus layer rewards: Block proposals, attestations, and sync committee participation
  • Execution layer rewards:
    MEV
    , transaction fees, and block tips

Validators receive rewards only between their activation and exit epochs.

The Vault initially holds rewards as liquid ETH until there is enough to register additional validators.

After the

Pectra ↗
upgrade,
EIP-7251 ↗
allows Vaults to merge multiple 32 ETH validators into fewer 0x02 compound validators with higher effective balances, thus improving efficiency and reducing infrastructure overhead, while allowing partial withdrawals of rewards above 32 ETH. Each Vault decides whether to:

  • Reinvest accumulated rewards into additional staking via consolidation, or

  • Keep rewards as

    unbounded ETH
    within the Vault for greater liquidity.

Rewards are calculated off-chain by the StakeWise Oracle Network.

IconDeep Dive

For detailed information about the reward distribution process, see Oracles: Reward Distribution →.

Withdrawals​

💰 Withdrawal Process
🔍 Check Queued Assets → 🎯 Withdraw Excess → 💡 Partial Withdrawals
│
→ 🚪 Full Validator Exits
│
→ ⏰ Oracle Fallback (24h)

Users can mint osTokens for instant liquidity or withdraw. When users choose to unstake, they enter the Vault's exit queue and receive a position ticket that tracks their place in line. As ETH becomes available to the Vault, users can claim what is available. If only part of the requested amount is available, they can claim that portion immediately and receive an updated ticket for the remainder.

Partial withdrawals for 0x02 compound validators are now supported and can now be triggered from the execution layer via EIP-70024. The withdrawal fulfillment process is automated by the Operator Service →, which manages validator exits and partial withdrawals among other responsibilities to ensure timely processing of the exit queue.

IconProcessing Time

On mainnet, partial withdrawals typically complete faster (≈27–28 hours), while full exits can take up to one month to finalize.

Validator Exits​

The Operator Service automatically triggers validator exits when required. By default, the Operator Service checks every 12 hours (configurable via WITHDRAWALS_INTERVAL) to process queued withdrawal requests. If partial withdrawals are not possible, the Operator Service initiates full exits. If the Operator Service fails to exit validators within 24 hours, Oracles will step in and perform the exits instead.

The process is as follows:

  1. Regular check. Every 12 hours, the Vault checks for pending positions in the exit queue and first attempts to satisfy them with ETH that is already available to the Vault — i.e., unbonded ETH (deposits + unallocated rewards) and harvested MEV.
  2. Initiate exits if needed. If available ETH is insufficient, the Operator Service initiates validator exits to free up the remaining amount. If there are 0x02 validators in the vault, the operator service will trigger partial withdrawals from these validators. If the required amount is larger than what is available from partial withdrawals, the operator service will trigger validator exits through a vault contract call.
  3. Oracle enforcement of exits. If the Operator Service does not initiate partial or full withdrawals, the Oracle network will automatically execute a full withdrawal after 24 hours using the exit signatures they have received during validator registration.

The exit queue advances whenever the Vault syncs state — both on user actions (entering the queue, deposits/withdrawals) and on the Operator Service-driven syncs5. Throughout the process, user assets are safe in the Vault's smart contracts and are never controlled by any third party.

Exit processing time depends on the Ethereum network conditions. 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 according to their ticket number.

osToken​

osTokens (osETH or osGNO) are ERC-20 tokens that users can mint from any Vault using their shares as backing (aka collateral), providing liquidity without unstaking. osToken can be traded or used in DeFi while the underlying stake continues earning rewards.

The system keeps more staked assets backing each osToken than the token is worth. This safety buffer protects users and keeps the system stable. The Vault's Loan-to-Value ratio determines how much users can mint — this ranges from standard ratios around 90% up to 99.99% for DAO-approved Vaults6.

IconDeep Dive

For more details on how osToken works, see osToken →.

1. 0x01 and 0x02 refer to withdrawal credential types that determine validator capabilities: 0x01 validators (Type 1) use the current 32 ETH limit with automatic sweeps of excess balance, while 0x02 validators (Type 2) support higher effective balances up to 2048 ETH with compounding rewards and partial withdrawals. Converting from 0x01 to 0x02 is irreversible. By default, the 0x02 validators are registered. To register 0x01 validators, add the flag --validators-type=0x01. ↩

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. ↩

4. You can disable partial withdrawals if you prefer to rely solely on full exits. Use the --disable-withdrawals flag when starting the Operator Service:
./operator start --vault=0x3320a68 --disable-withdrawals
In this case, funds will be withdrawn via full exits using Oracles. ↩

5. Vault state can also be updated by the Vault operator by passing the --harvest-vault flag to the Operator Service start command. Harvest occurs every 12 hours and the gas fees are paid by the hot wallet linked to the Operator Service. ↩

6. To qualify for the higher LTV, Vaults must meet strict DAO-defined criteria, including: Minimum stake: ≥ 10k ETH (for osETH) or ≥ 5k GNO (for osGNO); Vault fee ≤ 5% for ETH, ≤ 15% for GNO; Consistently above-median performance; Running the latest Vault version; Vault Operator's locked SWISE bond: 5M for ETH, 1M for GNO. ↩

Last updated on