Vaults

Introduction

Vaults are isolated staking pools that can process ETH and GNO deposits into 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 makes every Vault isolated from others, allowing depositors to customize 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, rewards 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 automatically 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 monitors deposit levels and handles the technical validator creation 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 system prioritizes funding existing 0x02 validators up to their maximum capacity before creating new validators.

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

Validator Registration Process

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.

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 may receive rewards only between their activation and exit epochs. Note that, after submitting a voluntary exit, there may be a delay while the validator moves through the exit queue until its exit epoch is passed. The validator is expected to participate as usual during this period.

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 validators with higher effective balances. This can improve efficiency and reduce infrastructure overhead, and allows 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.

Because direct Beacon chain state queries are not feasible in the EVM⁴, rewards are calculated off-chain by the StakeWise Oracle Network.

Deep Dive

For detailed information about the reward distribution process, see the Oracles → chapter.

Withdrawals

Users can mint osTokens for instant liquidity or withdraw. When a user chooses 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 compound validators (0x02) 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. More details on partial withdrawals are available in the Operator: Partial Withdrawals → section.

The process is as follows:

1. Daily check. On a daily cycle, 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 initiates validator exits to free up the remaining amount.
3. Oracle enforcement of exits. If the operator does not initiate partial or full withdrawals, the oracle network will automatically execute full withdrawal after 24 hours.

The exit queue advances whenever the Vault syncs state – both on user actions (entering the queue, deposits/withdrawals) and on operator service-driven syncs (e.g., harvest). 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 congestion. 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), giving 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 on deployement, 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 operator to build their own DeFi ecosystem using the Vault's Token. Operator sets its name and symbol (e.g. mntETH), which will be visible in most portfolio tracking applications. Users still can mint osToken and transfer their stake in the Vault as long as they don't have osToken minted.

Tokenless Vaults avoid potential tax events when exchanging ETH for 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, with the default BalancedCurator distributing assets evenly across eligible sub-Vaults. 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:

Vault Admin - The Vault Owner

Deploys the Vaults and sets the core parameters like the type of Vault, fee, and branding.

Vault Admin can be a single wallet, a multisig, or a DAO and can be changed through setAdmin function. The function can only be called by the current Vault Admin.

While Vault Admin cannot change the core parameters of the Vault set once at deployment, they can assign the Access Manager and Keys Manager roles to other wallets, and change the recipient of the staking fee.

Access Manager - Whitelist Controller

Wallet with the power to add and remove wallets from the whitelist of a Private Vault.

By default, Vault Admin is also the Access Manager. However, they can assign the Access Manager role to another wallet, and reclaim this role at any moment in the future.

Keys Manager - Deposit Data Controller

Wallet with the power to add and remove wallets from the whitelist of a Private Vault.

By default, Vault Admin is also the Keys Manager. However, they can assign the Keys Manager role to another wallet, and reclaim this role at any moment in the future.

Branding

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

Authenticity Guarantee

Stakers can be confident about the authenticity of these informations, 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 fee structures, limits, update restrictions, and how they interact with protocol fees, see the dedicated Fees → chapter.

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.

Vault shares use a shares-based accounting system where:

• Shares are non-transferable (unless the Vault is the 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 to help users evaluate Vault quality based on validator operational excellence. These grades reflect the average Vault performance over the last 7 days:

Scoring Grades:

• Excellent (99.6-100%): No missed blocks or very few. Validators perform excellently in attestations, with less than 0.5% missed attestation rewards.
• Good (99.2-99.6%): No missed blocks or very few. Validators perform well in attestations, with less than 1% missed attestation rewards.
• Moderate (97.1-99.2%): The Vault has issues, with up to 3% missed attestations and/or blocks.
• Bad (0-97.1%): Validators are not performing correctly, missing blocks or poorly handling attestations.

Important

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

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 EthVaultFactory ↗ 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 here ↗.

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 allow 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 for 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 (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. EIP-4788 is currently in the project phase and proposes a method to expose Ethereum's beacon chain block roots inside the EVM by committing each beacon block's hash tree root into execution payload headers and storing them in a smart contract. ↩

5. To disable this, use the flag --disable-withdrawals — in this case, funds will be withdrawn via full exits using oracles. ↩

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; Locked SWISE bond: 5M for ETH, 1M for GNO. ↩