Vaults

Introduction

Vaults are isolated staking pools that process ETH and GNO deposits for staking, distribute rewards, and handle withdrawals in a trustless and non-custodial manner.

ETH and GNO deposits into any Vault can only be used to launch validators for that specific Vault. Any rewards (or penalties) accumulated by these validators will belong to the Vault. This isolates each Vault, allowing depositors to customize their staking experience to their needs.

Individuals, professional node operators, DAOs, communities, and institutions can deploy a Vault to enable ETH and GNO staking on specific terms, like a bespoke staking fee, unique mix of operators, custom MEV strategy, capacity, branding, and optional ERC-20 Vault Token issuance.

All deposits, reward distribution, and withdrawals are handled by smart contracts, making staking in Vaults fully non-custodial.

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 0x02¹. 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 →:

Validator 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 messages² using local keystores or a remote signer →
4. Share the validator's exit signature with StakeWise Oracles:
   • Split the BLS signature³ 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.

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

Deep 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. They are significantly faster and more efficient than full validator exits, which can now also be processed via execution request call⁴. 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.

Processing 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 syncs⁵. 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 Vaults⁶.

Deep Dive

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

Customization

Each Vault is highly customizable. Core parameters such as Vault type, capacity, and MEV strategy are immutable and set once upon deployment, while management roles, branding, and fees can be changed later.

Vault Type

All Vault types support osToken minting. The Vault types differ in their specific characteristics and restrictions.

Standard Vaults — Most Common

Receive staking deposits from any wallet and issue non-transferable Vault shares that earn rewards.

ERC-20 Vaults — For Custom Utility & Liquidity Ecosystem

Allow Vault operators to build their own DeFi ecosystem using the Vault's token. The operator sets the token's name and symbol (e.g., mntETH), which will be visible in most portfolio tracking applications. Users can mint osToken and transfer their stake in the Vault as long as they don't have osToken minted.

Note

Standard Vaults (tokenless) help avoid potential tax events that could be triggered by exchanging ETH for a Vault token.

Private Vaults — Restricted Access

Receive staking deposits from wallets that have been whitelisted by the Vault Admin.

Blocklist Vaults — Open with Exceptions

Receive staking deposits from any wallets except those on a blocklist.

Meta Vaults — Diversified Strategy

Meta Vaults do not register validators directly — instead, they delegate accumulated assets to sub-Vaults, which are managed by the Vault Admin. Each sub-Vault must have at least one registered validator.

Deposits are distributed across underlying sub-Vaults (up to 50 maximum) according to curator-defined allocation logic. The default BalancedCurator distributes assets evenly across eligible sub-Vaults. The Curator contract can be changed by the Admin.

MetaVaults can be deployed using the EthMetaVaultFactory contract, and currently, only the factory owner is permitted to deploy new MetaVaults.

Capacity

Vault capacity is an immutable deposit limit that Vault operators set once during initialization to control the maximum amount of ETH their Vault can accept. When left unset, Vaults have unlimited capacity by default. The capacity is enforced on every deposit transaction, reverting with a CapacityExceeded error if exceeded. Capacity helps control validator set size based on operator infrastructure capabilities.

MEV Strategy

MEV (Maximum Extractable Value) represents additional profits that validators can earn when proposing blocks. Vaults can use either a Smoothing Pool or Own Escrow for collecting the block rewards.

Smoothing Pool — Pooled Rewards

Rewards are pooled across multiple Vaults and distributed evenly, providing more stable and predictable returns regardless of block proposal frequency.

For example, a Vault with only a few validators can receive periodic small payouts from the Smoothing Pool, which come from the block proposal rewards contributed by other participating Vaults. In return, when the Vault does get the chance to earn a block proposal reward, it will flow to the Smoothing Pool as well, to be shared amongst all participating Vaults.

The main advantage of using the Smoothing Pool is achieving a consistent level of rewards from block production, and a consistent Vault APY.

Any Vault that opts into using the Smoothing Pool is required to operate one of the StakeWise DAO-approved MEV relays. This is necessary to ensure a consistently high contribution to the Smoothing Pool from every participating Vault.

Own Escrow — Own Rewards

Rewards are collected solely by individual Vaults. Own Escrow allows a Vault to choose an independent approach to earning block production rewards, like using any relay of choice, because it does not rely on sharing such rewards with other Vaults. Own Escrow targets maximum value capture but with increased variability.

Management Roles

Every Vault has several key roles for the internal management of the staking process:

Admin

Primary controller of the Vault. Responsible for overall Vault configuration.

• Manage all roles and permissions
• Modify fees and fee recipients
• Update Vault branding (name, description, image)
• Configure Vault settings and parameters

The Admin can be a single wallet, multisig, or DAO and can be changed through the setAdmin function. Only the current Admin can call this function.

Vault fee claimer

Can claim accumulated Vault fees on behalf of shareholders.

Whitelist / Blocklist manager

Access controller for deposit permissions.

• Add/remove accounts authorized to deposit (whitelist)
• Add/remove accounts prohibited from depositing (blocklist)

This role only appears for Private Vaults or Vaults with blocklist functionality enabled.

Validators manager

Technical operator responsible for validator operations.

Branding

Vault operators can set their Vault's name, description, and image simply through the StakeWise interface and these can be updated anytime by the Admin.

Authenticity Guarantee

Stakers can be confident about the authenticity of this information, i.e., a Vault branded by Operator A is indeed controlled and run by Operator A. Verification is a manual process managed by the core StakeWise team.

Fee

Vault operators can charge fees on staking rewards to compensate for infrastructure and management costs. These fees are set by the Vault Admin and can be updated over time, subject to protocol-enforced restrictions to protect users from sudden changes.

Deep Dive

For complete details about Vault fees, see Fees →.

Staking into a Vault

When staking into a Vault, users deposit ETH or GNO and receive Vault shares representing their proportional ownership of the pool's assets. There are no minimum deposit requirements and no maximum limits except the Vault's capacity limit.

Vaults use a shares-based accounting system where:

• Shares are non-transferable (unless the Vault is an ERC-20 Vault)
• Shares may not appear in portfolio tracking applications
• Share value increases automatically as staking rewards accumulate
• No token swaps or conversions occur during staking

For immediate liquidity, users can mint osTokens (osETH or osGNO) using their Vault shares as collateral.

Evaluating Vault Performance

StakeWise provides performance grades (Excellent, Good, Moderate, Bad) to help users evaluate Vault quality based on validator operational excellence. These grades reflect the average Vault performance over the last 7 days. View detailed grade criteria →.

Important

Performance grades help users identify well-operated Vaults but should be considered alongside other factors like fees, capacity, and operator reputation.

Technical Details

For operators seeking detailed information about performance calculations, scoring formulas, and optimization strategies, see Vault Performance →.

Technical Architecture

Vault Deployment

Each Vault in the StakeWise protocol is deployed as an upgradeable ERC-1967 ↗ proxy contract. The proxy is the contract users interact with. It holds all persistent state — including user balances — and stores Vault-specific configuration set during initialization, which defines its core operational characteristics. Vaults are created through factory contracts such as VaultFactory ↗ by:

1. Deploying a proxy that reserves storage for all Vault data and sets its initial configuration during the initializer call.
2. Pointing the proxy to a shared implementation contract that contains the Vault's logic and module integration.
3. Registering the Vault in the VaultsRegistry ↗ — the canonical on-chain list of all valid Vaults and factories.

Important

To mitigate economic attacks during the vulnerable initial phase of a Vault's lifetime, the factory requires a security deposit of 1 gwei at creation.

Deep Dive

All Vault factory addresses can be found in Networks →.

Modular Design

The constructor parameters set during deployment link the Vault to essential StakeWise infrastructure and the Ethereum Beacon Chain. Each Vault is built from specialized modules that split responsibilities into distinct areas, including:

Validator lifecycle — adding, approving, and exiting validators.

Deposit and withdrawal — staking to and withdrawing from the Beacon Chain.

Fee enforcement — calculating and applying protocol and operator fees.

MEV capture — routing execution-layer rewards either to a Vault-specific escrow or to a Smoothing Pool.

Architecture Note

This modular architecture ensures that all Vault types (ETH, GNO, private, ERC-20) share consistent behavior and allows new features to be added without breaking existing Vaults.

State Tracking

Vaults maintain an internal accounting ledger that tracks the value of all user stakes. This ledger is updated whenever user activity or protocol events affect stake values, such as deposits, withdrawals, reward distributions, or MEV payouts. Updates occur automatically when users interact with the Vault, and operators can trigger updates manually when necessary, for example, to refresh valuations before osETH minting.

Upgrade Flexibility

Every Vault is an independent staking pool, and its smart contracts cannot be unilaterally changed or upgraded by the StakeWise DAO. Because the proxy pattern separates storage from logic, upgrades can be applied without affecting user balances or redeploying the contract. Only the implementation contract changes, while the proxy — holding all state — remains untouched.

The DAO may release new Vault contract versions to improve efficiency or safety, but upgrading is always optional — Vaults can opt to keep their current version. All upgrades are subject to community governance approval, providing strong guarantees for user protection and protocol integrity.

The Vault architecture is deployed in parallel on both the Ethereum and Gnosis networks through equivalent contract implementations, such as EthVault and GnoVault.

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