diff --git a/docs/docs/vaults/boost.mdx b/docs/docs/vaults/boost.mdx index 29607298..f1d858e5 100644 --- a/docs/docs/vaults/boost.mdx +++ b/docs/docs/vaults/boost.mdx @@ -1,102 +1,68 @@ --- title: Boost -description: Amplify staking rewards up to 3x with StakeWise Boost. Learn how osToken looping on Aave works, safety mechanisms, and how to boost/unboost. +description: Amplify staking rewards up to 3x with StakeWise Boost. Learn how osETH looping on Aave works and the safety mechanisms behind it. --- import Image from '@theme/IdealImage' -# Boost +StakeWise Boost is a one-click yield amplification strategy that uses osETH as collateral to borrow additional ETH on Aave and restake it in the Vault. The process repeats multiple times, resulting in a single staking position. Boost’s rewards are the surplus from the extra staked ETH’s rewards, after the Aave borrowing fee. StakeWise charges no additional fee for using Boost. -StakeWise Boost is a yield amplification strategy that profits from the difference between the extra staking rewards and the cost of sourcing additional ETH. Boost uses osETH as collateral to borrow additional ETH on Aave and stake it again, creating a "looped" process that amplifies your staking position: +Boost flow -- **6x looping** in Vaults with 90% LTV -- **14x looping** in Vaults with 100% LTV -- **Up to 3x boost** in staking rewards compared to normal staking +Boost executes automatically in a few steps: -Over the mid term (6+ months holding period), Boost historically generates ~1–3 percentage points above the base staking rate, depending on the spread between staking rewards and Aave borrow rates, for a total APY of approximately **4–6%**. +1. The staker deposits osETH into [Boost via the Vault or Stake page](/staker/boost#how-to-boost). +2. Boost uses the osETH as collateral on Aave to borrow ETH against it. +3. The borrowed ETH is staked in the Vault, which mints new osETH. +4. Steps 2–3 repeat, increasing the amount of ETH earning staking rewards. -## How Boost Works +Boost reward flow -Built into every Vault by default, Boost combines your original deposit with ETH borrowed from Aave into a single staking position. -You deposit osETH into Boost via the Vault or Stake page. -Boost then uses your osETH as collateral on Aave to borrow additional ETH. -The borrowed ETH is staked in the Vault on your behalf. -This process repeats automatically. +The magnitude of amplification depends on the Vault's osETH LTV (how much osETH can be minted per unit of ETH staked), distinct from Aave's borrow LTV: -Boost flow explanation +- **6x looping** in Vaults with 90% osETH LTV +- **14x looping** in Vaults with 100% osETH LTV -Staking rewards are earned on the entire amount — so even after deducting Aave interest and operator fees, your net rewards are far greater than staking your original deposit alone — and StakeWise charges no additional fee for using Boost. Boost does not rely on the secondary market for repaying debt, so your strategy profit is not affected by slippage during exits. +Over the mid-term (6+ months), Boost has historically added **~1–3 percentage points** over the base staking rate, for a total APY of roughly **4–6%**. -Boost replaces 40+ manual steps with a single click, allowing even novice users to amplify their staking rewards without navigating the complex DeFi landscape — -with exposure limited to the node operators of your chosen Vault and the smart contracts of StakeWise and Aave. +:::custom-tips[Get Started With Boost] +To start using Boost right away, see [this guide](/staker/boost). +::: ## Safety -### Price Stability Protection - -Boost eliminates depeg-related liquidation risks through Aave's use of StakeWise's native price feed for osETH instead of volatile secondary market prices. This means osETH price fluctuations on DEXs cannot trigger liquidations, as your collateral value always equals the osETH redemption value rather than market price. This design ensures that temporary market volatility doesn't endanger your boosted position. - -### Safety Mechanisms - -LTV (Loan-to-Value) is the ratio of your borrowed amount to the value of your collateral. For example, at 93% LTV, you can borrow 0.93 ETH against an osETH deposit worth 1 ETH. -Three key LTV metrics determine how safe your boosted position is: - -**Max LTV**: 93% – the maximum you can borrow against your osETH collateral when initiating a loan - -**Current LTV** – the value of your loan relative to your collateral right now, influenced by the Aave borrow rate and osETH APY over time - -**Liquidation Threshold**: 95% – the point at which a position is considered undercollateralized and subject to liquidation +The biggest risks for a typical leveraged position are **collateral depeg** and **LTV drift toward liquidation**. Boost mitigates both by design. -The 2% gap between Max LTV and Liquidation Threshold acts as a safety buffer, providing substantial protection before any liquidation risk.1 +**No depeg liquidations.** Aave values osETH using StakeWise's native price feed rather than volatile secondary-market prices, so collateral is always worth what osETH can be redeemed for. This removes depeg as a source of liquidation. -![danger_zone](./img/danger_zone.png) +**A built-in LTV buffer.** If borrow costs ever exceed staking rewards, debt grows faster than collateral and LTV drifts upward. Boost has a 2% buffer between the Max LTV (93%) and the Liquidation Threshold (95%) on Aave, which gives it room to absorb sustained negative spread without a liquidation. For historical data, see the [blog post ↗](https://blog.stakewise.io/caseStudy/how-stakewise-boost-keeps-your-rewards-juicy-and-your-stake-safe). On Aave, LTV is the ratio of borrowed value to collateral value, and three numbers bound the position: -Current LTV and Liquidation Threshold are the key variables for maintaining a healthy borrow position and avoiding liquidation. +- **Max LTV (93%)**: the most that can be borrowed against the collateral when opening a loan. +- **Liquidation Threshold (95%)**: the point at which the position becomes undercollateralized. +- **Current LTV**: where the position sits now, drifting with the spread between staking APY and Aave's borrow APY. -### Automatic Unboost +In normal markets the drift goes the safe way: staking rewards outpace borrow costs, so collateral grows faster than debt and LTV decreases over time. -As an additional safety layer, Boost includes an automatic unboost mechanism that activates when positions approach the liquidation threshold. When any boosted position reaches 94.5% LTV, anyone in the community can trigger an automatic unboosting transaction to protect the user. -The StakeWise core team actively monitors all boosted positions and will trigger these protective exits when necessary, with all funds always remaining under the original owner's control. +**Automatic unboost.** As a final safeguard, when a position reaches **94.5% LTV** anyone can trigger an unboosting transaction on the holder's behalf, and the StakeWise core team monitors positions to do so when needed. Funds always remain under the holder's control, and since Boost never relies on the secondary market to repay debt, exits aren't exposed to slippage. -## Risks & Limitations +Smart-contract exposure is limited to the regularly audited StakeWise and Aave contracts. -Two market-driven conditions can affect your Boost position: +## Market Conditions -### Borrow APY Exceeds Staking APY +Two market-driven conditions can affect a Boost position. -Boost APY depends on the spread between your Vault's staking APY and Aave's variable WETH borrow APY. -Boost APY is positive when the borrow APY is lower than the staking APY, and negative when the borrow APY exceeds the staking APY. - -When the borrow APY is lower than the staking APY, your LTV gradually decreases, making your position progressively safer. -When the borrow APY exceeds the staking APY, your LTV gradually increases. +**When borrow APY exceeds staking APY.** Boost APY depends on the spread between the Vault's staking APY and Aave's variable WETH borrow APY: it's positive when borrow APY is below staking APY, and negative when it exceeds it. The current WETH variable borrow APY can be monitored in the **Borrow Info** section of the [WETH reserve on Aave ↗](https://app.aave.com/reserve-overview/?underlyingAsset=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2&marketName=proto_mainnet_v3). :::custom-warning[Negative APY Alert] -If you see a negative APY on your Boost position, it means the WETH borrow APY on Aave currently exceeds your Vault's staking APY. +A negative APY on a Boost position means the WETH borrow APY on Aave currently exceeds the Vault's staking APY. If the APY remains negative for more than 7 consecutive days, consider exiting Boost manually. Stay connected with the [StakeWise Discord ↗](https://discord.com/invite/2BSdr2g) community for real-time updates on market conditions. ::: -You can monitor the current WETH variable borrow APY in the **Borrow Info** section of the [WETH reserve on Aave ↗](https://app.aave.com/reserve-overview/?underlyingAsset=0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2&marketName=proto_mainnet_v3). - -### osETH Supply Cap Reached - -Boost deposits osETH as collateral on Aave, which enforces a maximum supply cap. -When total supplied osETH reaches this cap, no additional osETH can be deposited, making it impossible to open new boosted positions. -Existing boosted positions are not affected, but new boosts cannot be initiated until supply drops below the cap. - -You can monitor the current supply usage in the **Supply Info** section of the [osETH reserve on Aave ↗](https://app.aave.com/reserve-overview/?underlyingAsset=0xf1c9acdc66974dfb6decb12aa385b9cd01190e38&marketName=proto_mainnet_v3). - -:::custom-notes[Guide] -To start using Boost, see [How to Use Boost →](/staker/boost) -::: +**When the osETH supply cap is reached.** Boost deposits osETH as collateral on Aave, which enforces a maximum supply cap. When total supplied osETH reaches this cap, no additional osETH can be deposited, making it impossible to open new boosted positions. Existing boosted positions are not affected, but new boosts cannot be initiated until supply drops below the cap. The current supply level can be monitored in the **Supply Info** section of the [osETH reserve on Aave ↗](https://app.aave.com/reserve-overview/?underlyingAsset=0xf1c9acdc66974dfb6decb12aa385b9cd01190e38&marketName=proto_mainnet_v3). :::custom-notes[Further Reading] - [StakeWise Boost: A DeFi-Native Yield Amplification Strategy Made Simple ↗](https://blog.stakewise.io/caseStudy/stakewise-boost-a-defi-native-yield-amplification-strategy-made-simple) - [Maximize Your Rewards With StakeWise Boost ↗](https://blog.stakewise.io/productUpdate/maximize-your-rewards-with-stakewise-boost) - [How StakeWise Boost Keeps Your Rewards Juicy & Your Stake Safe ↗](https://blog.stakewise.io/caseStudy/how-stakewise-boost-keeps-your-rewards-juicy-and-your-stake-safe) ::: - -
- 1. Based on the historical analysis of 420 days, LTV increases only ~10.7% of the time (39 days per year). On the remaining days, LTV actually decreases — for every 1 day of LTV increase, there are ~8 days of decline, making positions progressively safer over time. Even in an extreme scenario where borrow APY consistently exceeds osETH APY by 2%, starting from 93% LTV, liquidation would take over a year. As for mass slashing, breaching the 2% buffer would require 480–1,150 validators to be slashed across the protocol simultaneously — an event that has never occurred in StakeWise's 4-year history. - ↩ -
diff --git a/docs/docs/vaults/configuration.mdx b/docs/docs/vaults/configuration.mdx new file mode 100644 index 00000000..00d5db72 --- /dev/null +++ b/docs/docs/vaults/configuration.mdx @@ -0,0 +1,92 @@ +--- +title: Configuration +description: Configure StakeWise Vault parameters — capacity, MEV strategy, management roles, branding, and fees. +toc_max_heading_level: 3 +--- + +import Image from '@theme/IdealImage' + +When [creating a Vault](/operator/create-regular-vault), operators set parameters that define how it operates — deposit capacity, MEV strategy, Vault management roles, branding, and fees. Some are fixed at creation; others can be updated later. + +Vault Configuration Parameters + +## Immutable Parameters + +Capacity and MEV strategy are immutable parameters set once during Vault creation. + +### Capacity + +The maximum amount of assets (ETH or GNO) a Vault can accept; if unset, deposits are unlimited. The cap is enforced on every deposit — transactions that would exceed it revert with a `CapacityExceeded` error. This is useful for matching Vault size to the node operator's infrastructure. + +### MEV Strategy + +Vault MEV strategy options - Smoothing Pool vs Own Escrow + +MEV (Maximal Extractable Value) is the extra profit validators can capture when proposing blocks. +Vaults can use either a **Smoothing Pool** or **Own Escrow** to collect MEV from proposing blocks. This choice is set at Vault creation and can't be changed later. + +#### Smoothing Pool {#smoothing-pool} + +Rewards are pooled across multiple Vaults and distributed in proportion to each Vault's total assets staked, providing more stable and predictable returns regardless of block proposal frequency. + +For example, a Vault with only a few validators will still receive periodic small payouts from the Smoothing Pool. +In return, when one of its validators does earn a block proposal reward, that reward flows to the Smoothing Pool to be shared among all participating Vaults. + +Vaults that use the Smoothing Pool must set every relay to one of the [StakeWise DAO-approved MEV relays](/operator/smoothing-pool-relays#approved-relay-endpoints). This ensures that individual Vaults' contributions to the Smoothing Pool are tracked and the risk of non-contribution is mitigated. + +#### Own Escrow + +Each Vault keeps its own MEV rewards. Because nothing is shared, the Vault can pick any relay — targeting maximum value capture at the cost of higher variability. + +## Roles + +Protocol Roles Diagram + +Every Vault has several key roles for the internal management of the staking process. All are assigned by the **Admin** — through the **Settings → Roles** tab on the Vault page, or by calling the corresponding function on the Vault contract. + +### Admin + +Primary controller of the Vault, and its creator by default. An Admin can be a single wallet, multisig, or DAO. The Admin's authority covers: + +- Assigning and reassigning every role, including its own +- Updating the Vault's branding and fees +- Setting the fee recipient and shareholder splits +- Upgrading the Vault to a new contract version + +### Vault Fee Claimer + +Triggers [claims of accumulated Vault fees](/operator/manage-vault/fee-claiming) on behalf of stakeholders. + +By default a Vault's fees go to a single recipient. To split them, the Admin submits the Fee Splitter address, a contract that divides incoming fees among multiple stakeholders according to specified proportions, as the Vault fee recipient, set on the Vault page under **Settings → Vault fee**. + +### Whitelist Manager + +Adds or removes the addresses authorized to deposit. Only present in Private Vaults. + +### Blocklist Manager + +Adds or removes the addresses blocked from depositing. Only present in Blocklist Vaults. + +### Validators Manager + +Authorizes the Vault's core validator operations — registration, funding, consolidation, and withdrawals. The [Operator Service automates most of the validator lifecycle](/operator/launch-operator-service#core-functions), and each on-chain action it submits must be signed by the address assigned to this role. + +## Settings + +Branding and fees are configurable parameters updated by the Admin. + +### Branding + +The Vault's name, description, and image. Set and updated on the Vault page under **Settings → Branding**. Updates go live immediately. Vault re-verification is required upon every Branding update. + +:::custom-stakewise[Vault Verification] +New or updated Vaults carry an **Unverified Vault** label until the StakeWise team reviews and marks the Vault as verified. 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. +::: + +### Fee + +A [percentage fee](../fees/intro) charged on staking rewards, ranging from 0% to 100%. + +Initially set during Vault creation and updated later on the Vault page under **Settings → Vault fee**, subject to protocol restrictions: each increase is capped at 20% relative to the current fee (e.g., a 10% fee can rise to at most 12%), with a 3-day delay between updates. If the current fee is 0%, it cannot exceed 1% on the first increase. + +The fee is automatically deducted from rewards when the Vault state is updated, and transferred to the Vault's fee recipient. diff --git a/docs/docs/vaults/customization.mdx b/docs/docs/vaults/customization.mdx deleted file mode 100644 index f1252b8a..00000000 --- a/docs/docs/vaults/customization.mdx +++ /dev/null @@ -1,130 +0,0 @@ ---- -title: Customization -description: Learn how to customize Vault settings, types, fees, and management roles ---- - -import Image from '@theme/IdealImage' - -# 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. - -:::custom-info[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. - -### MetaVaults — Diversified Strategy - -MetaVaults 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. - -Vault MEV strategy options - Smoothing Pool vs Own Escrow - -### 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. - -:::custom-stakewise[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. - -:::custom-notes[Deep Dive] -For complete details about Vault fees, see [Fees →](../fees/intro). -::: diff --git a/docs/docs/vaults/how-vaults-work.mdx b/docs/docs/vaults/how-vaults-work.mdx index 778e71c7..7f4e9d1d 100644 --- a/docs/docs/vaults/how-vaults-work.mdx +++ b/docs/docs/vaults/how-vaults-work.mdx @@ -1,135 +1,116 @@ --- title: How Vaults Work -description: Learn how Vaults register validators, distribute rewards, and process withdrawals +description: How Vaults accept deposits, register validators, distribute rewards, and process withdrawals. --- import Tooltip from '@site/src/components/Tooltip/Tooltip'; import Image from '@theme/IdealImage' -# How Vaults Work +Every Vault has [operator(s)](/operator/introduction) responsible for its validators. Operator(s) run the infrastructure directly or delegate it to a third party. Operating a Vault means running the [Operator Service ↗](https://github.com/stakewise/v3-operator) — StakeWise software that automates a Vault's day-to-day operations — alongside Ethereum [consensus](../../operator/staking-nodes#consensus-client) and [execution](../../operator/staking-nodes#execution-client) clients. -## Validator Registration +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 + +Deposit flow - user deposits ETH and gets Vault shares + +When a user deposits assets into the Vault (ETH or GNO), 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](./vault-types#erc-20-vault), where they are issued as a tradable token. -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. +Each Vault has a configurable [capacity](./configuration#capacity) — deposits of any size are accepted up to that limit. Some Vaults restrict who can deposit: [Private Vaults](./vault-types#private-vault) accept deposits only from whitelisted addresses, while [Blocklist Vaults](./vault-types#blocklist-vault) prohibit blocklisted wallets. -Vault operator(s)
Entities or individuals who run validators for a Vault. They operate the infrastructure and run the operator service software ↗ that automates essential Vault management tasks — such as validator registration, consolidations, and withdrawals.}>The Vault operator -runs specialized software (the [Operator Service ↗](https://github.com/stakewise/v3-operator)) alongside their Ethereum [consensus →](../../operator/staking-nodes#consensus-client) and [execution →](../../operator/staking-nodes#execution-client) clients -that monitor deposit levels and handle the technical validator setup process. +Depositors can also mint [osToken](../ostoken/intro) (osETH or osGNO) against their stake — a liquid token usable across DeFi while the underlying stake keeps earning rewards. osToken grows in value over time: for example, each osETH is worth more ETH as staking rewards accrue. How much osToken a user can mint depends on the Vault's LTV (Loan-to-Value) ratio. + +## Validator Registration Vault validator registration process diagram -When sufficient funds are available, this service submits validator registration requests to the StakeWise [Oracle network →](../oracles/intro). -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 ↗](https://www.validatorqueue.com/) conditions determine how quickly they begin earning staking rewards. +Vaults pool deposits and register validators on the Beacon Chain once they accumulate enough assets — 32 ETH on Ethereum, 1 GNO on Gnosis. -Vaults support two types of validators: `0x01` or `0x02`1. -The default type is `0x02`. To register `0x01` validators instead, add the `--validators-type=0x01` flag when starting the Operator Service. Note that automatic funding (topping up existing validators) is disabled when using `0x01` validators. -Existing `0x01` validators can be migrated to `0x02` via [consolidation](../../operator/manage-validators/consolidate-validators). -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 Operator Service monitors Vault balances and submits validator registration requests to the StakeWise [Oracle network](../oracles/intro), generating the deposit data automatically. Each registration requires [approval from 6 of 11 Oracles](../oracles/oracle-duties#validator-registration-approval) before it is submitted on-chain. Once approved, the Vault contract sends the required amount of assets to the network's staking deposit contract. Before the validator becomes active and starts attesting or proposing blocks, it travels through the Beacon Chain's activation pipeline. -The technical process for registering validators involves coordination between the Operator Service and the Oracle network: +:::custom-notes[Validator Activation Waiting Times] +Activation time depends on the Consensus Layer's [deposit queue ↗](https://www.validatorqueue.com/), which processes deposits at a capped rate. Once a deposit clears the queue, only a short fixed delay remains before the validator can participate. -:::custom-notes[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 messages2 using local keystores or a [remote signer →](../../operator/alternative-key-management/remote-signer) -4. Share the validator's exit signature with StakeWise Oracles: - - Split the BLS signature3 using [Shamir's Secret Sharing ↗](https://en.wikipedia.org/wiki/Shamir%27s_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. +1. **Deposit queue** — the deposit joins the Consensus Layer's processing queue (`state.pending_deposits`), rate-limited to 16 deposits per epoch and a churn budget shared between activations and exits (256 ETH per epoch on Ethereum, 2 GNO per epoch on Gnosis Chain). Under heavy demand, deposits can wait weeks or months. +2. **Fixed delay** — once written into the registry, the validator waits a fixed ~7–8 epochs (~45–50 min on Ethereum, ~9–11 min on Gnosis Chain, whose epochs are shorter). Most of this is a lookahead delay that stops anyone predicting and gaming committee assignments. +3. **Active** — the validator begins attesting and earning rewards. ::: -Vaults can have several node operators running validators and support Distributed Validator Technology
A solution designed to overcome a single-operator trust problem by splitting a validator's private key among multiple independent operators.
More on DVT - ethereum.org ↗}>Distributed Validator Technology (DVT) to increase redundancy. +The [Pectra ↗](https://ethereum.org/en/roadmap/pectra/) upgrade ([EIP-7251 ↗](https://eips.ethereum.org/EIPS/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. A similar upgrade was introduced on Gnosis Chain, raising the cap from 1 GNO to 64 GNO. + +The Operator Service registers new validators as `0x02` by default, and existing `0x01` validators can be migrated via [consolidation](../../operator/manage-validators/consolidate-validators). When registering, it prioritizes funding existing `0x02` validators — selecting those with the highest current balance and topping them up to 2048 ETH before creating new ones. -:::custom-notes[Deep Dive] -For more details on how Oracles handle the validator registration approval process, see [Validator Registration Approval →](../oracles/oracle-duties#validator-registration-approval). +:::custom-notes[Under the Hood] +The Operator Service performs the following steps: +1. Check if the Vault has enough assets to register a validator (32 ETH on Ethereum, 1 GNO on Gnosis Chain). +2. Get the next free validator key from the keystore. +3. Obtain the BLS signature for exit messages2 using local keystores or a [remote signer](../../operator/alternative-key-management/remote-signer). +4. Share the validator's exit signature with StakeWise Oracles: + - Split the BLS signature3 using [Shamir's Secret Sharing ↗](https://en.wikipedia.org/wiki/Shamir%27s_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 Vault reward distribution flow - consensus and execution rewards -Once validators are registered and active, they earn: -- **Consensus layer rewards**: Block proposals, attestations, and sync committee participation -- **Execution layer rewards**: MEV (Maximum Extractable Value)
Additional profits that validators can earn when proposing blocks by reordering, including, or excluding transactions within a block. MEV opportunities include arbitrage, liquidations, and sandwich attacks.}>MEV, transaction fees, and block tips +Once active, validators earn: -Validators receive rewards only between their activation and exit epochs. +- **Consensus Layer rewards** — for block proposals, attestations, and sync-committee participation. +- **Execution Layer rewards** — [MEV ↗](https://ethereum.org/developers/docs/mev/) and transaction priority fees. -The Vault initially holds rewards as liquid ETH until there is enough to register additional validators. +These rewards are [calculated off-chain](../oracles/oracle-duties#reward-distribution) by the StakeWise [Oracle network](../oracles/intro) every **12 hours**: Oracles publish per-Vault rewards to [IPFS ↗](https://ipfs.stakewise.io/ipfs/bafkreicoxcsrs652goyanvyjjhgljn6pqpf6zqweu7sobaeybdjrhqomfq), build a Merkle tree over that data, and submit a signed Merkle root to the [Keeper contract ↗](https://etherscan.io/address/0x6B5815467da09DaA7DC83Db21c9239d98Bb487b5), which verifies the signatures and stores the root. -After the Pectra
The Prague/Electra (Pectra) hardfork activated on 07-May-2025 at epoch 364032, introducing significant changes to both execution and consensus layers. Key features include variable validator effective balance (32-2048 ETH via EIP-7251), execution layer triggerable exits (EIP-7002), improved deposit processing (EIP-6110), BLS12-381 precompile (EIP-2537), programmable EOAs (EIP-7702), and increased blob throughput (EIP-7691), establishing a base layer for future scaling efforts.}>[Pectra ↗](https://ethereum.org/en/roadmap/pectra/) upgrade, -EIP-7251
Ethereum Improvement Proposal that increases the maximum effective balance of validators from 32 ETH to 2048 ETH, enabling validator consolidation and partial withdrawals.}>[EIP-7251 ↗](https://eips.ethereum.org/EIPS/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: +Each Vault then pulls in its own rewards through a **harvest**. -- Reinvest accumulated rewards into additional staking via consolidation, or +:::custom-notes[Harvest Mechanics] +A harvest does the following: -- Keep rewards as Unbounded ETH
ETH that is not locked in validators (32 ETH increments). This includes excess deposits, staking rewards, and MEV that have not been allocated to new validators yet.}>unbounded ETH -within the Vault for greater liquidity. +1. **Verifies the proof**. The Keeper contract checks the Vault's proof of 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 an MEV escrow; the Vault pulls them in. +4. **Applies the change**. The Vault's total assets are computed and per-share value is updated; only on gains, 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, making that portion of the queue claimable. +::: -Rewards are calculated off-chain by the StakeWise Oracle Network. +The Vault then decides what to do with those assets (ETH or GNO): -:::custom-notes[Deep Dive] -For detailed information about the reward distribution process, see [*Oracles*: Reward Distribution →](../oracles/oracle-duties#reward-distribution). -::: +- **Top up** — e.g. 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 assets as-is** — leave ETH or GNO in the Vault for greater liquidity. ## Withdrawals -Vault withdrawal and exit queue process +Vault withdrawal process - check queue, pay from available unbonded assets, partial withdrawals, full exits -Users can mint osTokens for instant liquidity or withdraw. When users choose to unstake, they enter the Vault's **exit queue** and receive an **exit queue 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. +Every **12 hours**, the Operator Service: -Partial withdrawals for `0x02` compound validators are now supported and can now be triggered from the execution layer via [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002)4. -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. +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 ↗](https://eips.ethereum.org/EIPS/eip-7002) if more ETH is needed. +3. **Triggers full validator exits** through a Vault contract call if partial withdrawals are insufficient. -:::custom-info[Processing Time] -On mainnet, partial withdrawals typically complete faster (≈27–28 hours), while full exits can take **up to one month** to finalize. +:::custom-info[Oracle Fallback] +If the Operator Service fails to trigger exits within **24 hours**, StakeWise Oracles execute them automatically using exit signatures pre-committed at registration. ::: -## 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. - Validator exit process with Oracle fallback -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**5. -Throughout the process, user assets are safe in the Vault's smart contracts and are never controlled by any third party. +When a user clicks [Unstake](/staker/vault-staking#how-to-unstake) or [Unboost](/staker/boost#how-to-unboost) in the StakeWise interface: -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 ↗](https://ethereum.org/en/staking/withdrawals/#validator-sweeping) to the Vault and becomes claimable by users according to their ticket number. +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. -## 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. - -:::custom-notes[Deep Dive] -For more details on how osToken works, see [osToken →](../ostoken/intro). -::: +Staked assets continue earning rewards until validators complete the exit. Once a validator fully exits, its balance is [swept ↗](https://ethereum.org/en/staking/withdrawals/#validator-sweeping) to the Vault and becomes claimable by users in ticket order. Exit processing time depends on Ethereum network conditions — check the current [validator queue ↗](https://www.validatorqueue.com/) for up-to-date estimates.
- 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. + 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. - By default, the `0x02` validators are registered. To register `0x01` validators, add the flag `--validators-type=0x01`. ↩
@@ -144,16 +125,3 @@ For more details on how osToken works, see [osToken →](../ostoken/intro). 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 by adding the `--disable-withdrawals` flag to the Operator Service start command. In this case, all withdrawals will be processed via full validator 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. ↩ -
diff --git a/docs/docs/vaults/img/MetaVaults_Architecture_Diagram.png b/docs/docs/vaults/img/MetaVaults_Architecture_Diagram.png index b597462d..adb8a4e8 100644 Binary files a/docs/docs/vaults/img/MetaVaults_Architecture_Diagram.png and b/docs/docs/vaults/img/MetaVaults_Architecture_Diagram.png differ diff --git a/docs/docs/vaults/img/boost_flow.png b/docs/docs/vaults/img/boost_flow.png index 95472542..06fa2ae3 100644 Binary files a/docs/docs/vaults/img/boost_flow.png and b/docs/docs/vaults/img/boost_flow.png differ diff --git a/docs/docs/vaults/img/boost_reward_flow.png b/docs/docs/vaults/img/boost_reward_flow.png new file mode 100644 index 00000000..dce15689 Binary files /dev/null and b/docs/docs/vaults/img/boost_reward_flow.png differ diff --git a/docs/docs/vaults/img/config.png b/docs/docs/vaults/img/config.png new file mode 100644 index 00000000..cfeb144a Binary files /dev/null and b/docs/docs/vaults/img/config.png differ diff --git a/docs/docs/vaults/img/danger_zone.png b/docs/docs/vaults/img/danger_zone.png deleted file mode 100644 index e7e29eac..00000000 Binary files a/docs/docs/vaults/img/danger_zone.png and /dev/null differ diff --git a/docs/docs/vaults/img/deposit_flow.png b/docs/docs/vaults/img/deposit_flow.png new file mode 100644 index 00000000..228c8d63 Binary files /dev/null and b/docs/docs/vaults/img/deposit_flow.png differ diff --git a/docs/docs/vaults/img/mev_strategy.png b/docs/docs/vaults/img/mev_strategy.png index 002597e6..c8452b7b 100644 Binary files a/docs/docs/vaults/img/mev_strategy.png and b/docs/docs/vaults/img/mev_strategy.png differ diff --git a/docs/docs/vaults/img/rewards_distribution.png b/docs/docs/vaults/img/rewards_distribution.png index d3df3817..c9a8c3b6 100644 Binary files a/docs/docs/vaults/img/rewards_distribution.png and b/docs/docs/vaults/img/rewards_distribution.png differ diff --git a/docs/docs/vaults/img/roles.png b/docs/docs/vaults/img/roles.png new file mode 100644 index 00000000..625487fe Binary files /dev/null and b/docs/docs/vaults/img/roles.png differ diff --git a/docs/docs/vaults/img/stakewise_boost_money_flow.png b/docs/docs/vaults/img/stakewise_boost_money_flow.png deleted file mode 100644 index a344fd83..00000000 Binary files a/docs/docs/vaults/img/stakewise_boost_money_flow.png and /dev/null differ diff --git a/docs/docs/vaults/img/technical_architecture.png b/docs/docs/vaults/img/technical_architecture.png index bec10e8a..9bab6564 100644 Binary files a/docs/docs/vaults/img/technical_architecture.png and b/docs/docs/vaults/img/technical_architecture.png differ diff --git a/docs/docs/vaults/img/vault_types.png b/docs/docs/vaults/img/vault_types.png new file mode 100644 index 00000000..2332eba9 Binary files /dev/null and b/docs/docs/vaults/img/vault_types.png differ diff --git a/docs/docs/vaults/intro.mdx b/docs/docs/vaults/intro.mdx index ba5dfc86..e7e78ddb 100644 --- a/docs/docs/vaults/intro.mdx +++ b/docs/docs/vaults/intro.mdx @@ -1,19 +1,17 @@ --- title: Vaults -description: Learn what Vaults are and what you can do with them +description: Dive deep into Vaults — permissionless, non-custodial, highly configurable staking pools for ETH and GNO with complementary in-protocol yield features like Boost and osETH. --- -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. +import Tooltip from '@site/src/components/Tooltip/Tooltip'; -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. +A Vault is an isolated staking pool — a smart contract that processes ETH and GNO deposits, distributes rewards, and handles withdrawals in a trustless, non-custodial manner. +Vaults do not socialize risk: each deposit can only fund that Vault's validators, and any [rewards](/staker/rewards) or penalties are contained within the Vault. -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. +Anyone — from solo stakers to DAOs and institutions — can [create a Vault](/operator/create-regular-vault) and run it on their own terms: bespoke fee, MEV strategy, and an optional ERC-20 Vault token. [MetaMask ↗](https://blog.stakewise.io/caseStudy/how-metamask-launched-pooled-staking-with-stakewise), [Chorus One ↗](https://blog.stakewise.io/caseStudy/how-chorus-one-launched-retail-staking-with-stakewise), and [NodeSet ↗](https://blog.stakewise.io/caseStudy/how-nodeset-launched-decentralized-pooled-staking-with-stakewise) use StakeWise Vaults to power their staking products. -All deposits, reward distribution, and withdrawals are handled by smart contracts, making staking in Vaults fully non-custodial. +Every Vault lets depositors mint [osToken](../ostoken/intro) against their staked position as collateral. osToken is an overcollateralized, liquid token that unlocks [DeFi yield opportunities](https://app.stakewise.io/ecosystem) while continuing to earn staking rewards. -When staking into a Vault, users deposit ETH or GNO and receive Vault shares representing their proportional ownership of the pool's assets. 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 +Beyond base staking rewards, StakeWise Vaults on Ethereum include access to [Boost](./boost), a built-in one-click strategy that uses osETH as collateral to borrow ETH on Aave and restake it in the Vault, potentially leading to more rewards. + +The pages that follow cover this in depth: [how Vaults work](./how-vaults-work) step by step, the different [Vault types](./vault-types), how to [configure a Vault](./configuration), how [performance](./vault-performance) is measured, the [Boost](./boost) strategy, and the underlying [technical architecture](./technical-architecture). diff --git a/docs/docs/vaults/meta-vaults.mdx b/docs/docs/vaults/meta-vaults.mdx deleted file mode 100644 index a202f336..00000000 --- a/docs/docs/vaults/meta-vaults.mdx +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: MetaVaults -description: Learn about MetaVaults — multi-layer Vaults that delegate assets to sub-vaults for diversified staking, flexible fees, and institutional-grade setups. ---- - -import Image from '@theme/IdealImage' - -# MetaVaults - -A MetaVault is a specialized Vault that doesn't run validators itself. Instead, it accepts deposits and routes them across a set of underlying Vaults — called *sub-vaults* — which handle validator operations. Just like with a Regular Vault, stakers can mint osETH against their position and redeem it for the underlying stake at any time. - -MetaVaults are also available in **ERC-20** and **Private** variants: the ERC-20 variant issues a transferable token as the share representation, while the Private variant adds a whitelist gate on deposits. - -MetaVaults Architecture Diagram - -## Use Cases - -Any third party can deploy a MetaVault permissionlessly, which opens up modular, layered staking strategies: - -- [Diversified staking ↗](https://blog.stakewise.io/guide/diversified-staking-with-metavaults) — spread stake across multiple operators through a single MetaVault, reducing single-operator exposure, optimizing fees, and giving you one place to deposit, withdraw, and manage your osETH position. -- [Dedicated MetaVaults for clients ↗](https://blog.stakewise.io/guide/setting-up-per-client-metavaults) — create a separate MetaVault for each client while routing all deposits into a shared Regular Vault. This keeps client funds isolated, supports per-client fees, delivers higher and more stable APY, and simplifies operations by managing a single validator fleet. - - -## How MetaVaults Work - -Allocation is handled by a **Curator** — a contract that decides how ETH is distributed to and withdrawn from sub-vaults. Curator contracts must be approved by the DAO and registered in the [`CuratorsRegistry` ↗](https://etherscan.io/address/0xa23F7c8d25f4503cA4cEd84d9CC2428e8745933C#code). Currently, one curator is available: the [`BalancedCurator` ↗](https://etherscan.io/address/0xe01351f866C118FbD04d222f9262A470F1d44d90#code), which spreads deposits and withdrawals evenly across sub-vaults. - -Before routing, the `BalancedCurator` checks each sub-vault's remaining capacity and distributes within those limits, saturating or skipping sub-vaults that are full. This means deposits continue to succeed even when one sub-vault in the set has reached its cap, instead of the entire deposit reverting. A MetaVault can route across up to 50 sub-vaults. diff --git a/docs/docs/vaults/technical-architecture.mdx b/docs/docs/vaults/technical-architecture.mdx index 32fcdf87..78edf973 100644 --- a/docs/docs/vaults/technical-architecture.mdx +++ b/docs/docs/vaults/technical-architecture.mdx @@ -1,65 +1,44 @@ --- title: Technical Architecture -description: Learn about Vault deployment, modular design, and upgrade flexibility +description: Learn how Vaults are deployed across Ethereum and Gnosis, the proxy pattern that makes them upgradeable, and their modular design. --- import Image from '@theme/IdealImage' -# Technical Architecture +A Vault is a self-contained on-chain system: a proxy that holds state, an implementation that holds logic, and a set of modules within it, each handling one responsibility — staking, accounting, fees, MEV, access control, and more. + +## Vault Deployment StakeWise Vault technical architecture overview -## Vault Deployment +Each Vault is deployed as an upgradeable [ERC-1967 ↗](https://eips.ethereum.org/EIPS/eip-1967) proxy contract. The proxy is what users interact with — it holds all persistent state, including user balances and the Vault-specific configuration set during initialization. Logic lives in a separate implementation contract, so new Vault versions can be released without redeploying each Vault or migrating user data. -Each Vault in the StakeWise protocol is deployed as an upgradeable [ERC-1967 ↗](https://eips.ethereum.org/EIPS/eip-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 ↗](https://etherscan.io/address/0x7a8cbbf690084e43de778173cfacf7313c9122dd#code) by: +Vaults are created through network-specific factory contracts. On Ethereum, an [`EthVaultFactory` ↗](https://etherscan.io/address/0x7a8cbbf690084e43de778173cfacf7313c9122dd#code) is deployed for each Vault variant (Standard, ERC-20, Private, Blocklist); on Gnosis, the equivalent [`GnoVaultFactory` ↗](https://gnosisscan.io/address/0x7A8cbBf690084E43De778173cfAcf7313c9122DD#code) plays the same role. Each call to `createVault`: -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 ↗](https://etherscan.io/address/0x3a0008a588772446f6e656133C2D5029CC4FC20E#code) — the canonical on-chain list of all valid Vaults and factories. +1. Deploys a new ERC-1967 proxy pointing to the shared implementation contract. +2. Calls the proxy's initializer to set the Vault's initial configuration. +3. Registers the new Vault in the [VaultsRegistry ↗](https://etherscan.io/address/0x3a0008a588772446f6e656133C2D5029CC4FC20E#code) — the canonical on-chain list of all valid Vaults. -:::custom-warning[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. -::: +If the Vault is configured to use its own MEV rewards escrow, the factory also deploys an [`OwnMevEscrow`](../../contracts/api/vaults/ethereum/mev/OwnMevEscrow) contract and wires it to the Vault during initialization. Otherwise, the Vault is connected to the [`SharedMevEscrow` ↗](https://etherscan.io/address/0x48319f97E5Da1233c21c48b80097c0FB7a20Ff86) (Smoothing Pool). -:::custom-notes[Deep Dive] -All Vault factory addresses can be found in [Networks →](../../contracts/networks/). +:::custom-warning[Security Deposit Required] +To mitigate the [ERC-4626 ↗](https://github.com/OpenZeppelin/openzeppelin-contracts/issues/3706) inflation attack while a Vault's share supply is still small, initialization requires a security deposit of at least 1 gwei. ::: ## Modular Design StakeWise Vault modular smart contract architecture -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. - -:::custom-notes[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. -::: +At initialization, the Vault is linked to [StakeWise smart contracts](../../contracts/networks/) and the Ethereum or Gnosis Beacon Chain. These links are immutable: once set, they cannot be changed. Each Vault is then composed from specialized modules, each responsible for a distinct area: -## State Tracking +**User deposits and exits** — minting shares for deposited assets and processing withdrawal requests against the exit queue. -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. +**Validator lifecycle** — registering new validators on the Beacon Chain, funding them from pooled deposits, and processing their exits. -## Upgrade Flexibility +**Fee enforcement** — calculating and applying protocol and operator fees on accrued rewards. -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. +**MEV capture** — routing Execution Layer rewards either to a Vault-specific escrow or to the shared Smoothing Pool. -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. +**osETH integration** — letting depositors mint osETH against their staked position without unstaking. -The Vault architecture is deployed in parallel on both the Ethereum and Gnosis networks through equivalent contract implementations, -such as `EthVault` and `GnoVault`. +Modules combine in different ways to produce the [Vault types](./vault-types). ERC-20, Private, and Blocklist Vaults are additive variants of the same staking core, layering tokenization or membership rules on top. MetaVaults reuse the same share-accounting, fee, and exit-queue logic, but delegate staking itself to a set of sub-vaults. diff --git a/docs/docs/vaults/vault-performance.mdx b/docs/docs/vaults/vault-performance.mdx index 15c9995a..f2266ee1 100644 --- a/docs/docs/vaults/vault-performance.mdx +++ b/docs/docs/vaults/vault-performance.mdx @@ -5,127 +5,130 @@ description: Understand StakeWise Vault performance scoring, including proposer import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -import Admonition from '@theme/Admonition'; -import useBaseUrl from '@docusaurus/useBaseUrl'; -# Vault Performance +A Vault's performance score measures how reliably its validators carry out their on-chain duties: attestations and block proposals. It is not an arbitrary rating. The Beacon Chain rewards and penalizes every validator according to exact protocol rules. -## Overview +For each validator, the [Beacon API ↗](https://ethereum.github.io/beacon-APIs/#/Rewards/getAttestationsRewards) reports two numbers: `ideal_rewards` (what flawless performance would have earned) and `total_rewards` (what the validator actually earned, after any penalties). StakeWise reads these values and calculates a single score across all of a Vault's validators over the **last 7 days**. -Vault performance represents the average performance of its validators. The scoring system derives a simple and effective formula for calculating Vault efficiency by evaluating the ratio of rewards to penalties, minimizing the influence of luck. +Each Vault gets one of four grades depending on the score: -:::custom-info[Performance Components] -Vault efficiency consists of two main components: -- **rewardsProposer Performance** (**20% weight**) -- **sparksAttester Performance** (**80% weight**) -::: + + greenExcellent} default> + **Ethereum: [99.61, 100]% · Gnosis: [98.1, 100]%** -## Proposer Performance + - No missed blocks, or a very small percentage of them + - Validators attest with near-perfect accuracy + - Less than 0.5% missed attestation rewards + + yellowGood}> + **Ethereum: [99.21, 99.61)% · Gnosis: [97.5, 98.1)%** -Block proposals depend on luck, but we penalize validators who miss MEV opportunities. Since MEV rewards can vary greatly between blocks, we focus only on the number of blocks processed and ignore reward sizes to avoid relying on chance. + - No missed blocks, or a very small percentage of them + - Validators perform well in attestations + - Less than 1% missed attestation rewards + + orangeModerate}> + **Ethereum: [97.09, 99.21)% · Gnosis: [96.2, 97.5)%** -### Calculation Method + - The Vault has issues + - Up to 3% missed attestations and/or blocks + + redBad}> + **Ethereum: [0, 97.09)% · Gnosis: [0, 96.2)%** -We calculate the `proposal_score` by dividing the number of produced blocks by the total number of blocks. Validators are not negatively penalized for missed blocks; they get a score of 0 if they miss all their opportunities. + - Validators are not performing correctly + - Missing blocks or poorly handling attestations + + -:::custom-notes[Formula: Proposer Score] -``` -proposal_score = proposed_block_count / (proposed_block_count + missed_block_count) -``` +Read on to see what makes up this score and how it is calculated. -**Where:** -- `proposed_block_count` – Number of successfully mined MEV blocks -- `missed_block_count` – Number of missed MEV blocks -::: +## Attester Performance — 80% -:::custom-warning[Fee Recipient Configuration] -A block is considered **missing** if the transaction fee or MEV is sent to the incorrect address, which negatively impacts the Vault performance score. +Attester performance is **80% of the Vault score**. -Verify that your validator clients are configured with the correct **fee recipient address**. You can locate this address (Block reward recipient) on the Vault page in the **Details** section. -::: +Most of a validator's work is attesting. Once per epoch, the validator publishes a signed attestation that contains three votes1: -The proposer score is determined from statistics collected over the **past 7 days**. +- **Source vote**: a timely vote for the correct source checkpoint. +- **Target vote**: a timely vote for the correct target checkpoint. +- **Head vote**: a timely vote for the correct head block. -## Attester Performance +These votes keep the network in agreement and are a validator's **primary source of income**. Each vote carries a certain weight toward the reward, and together the three make up **84.4% of total rewards**. Missing the source or target vote carries a penalty, while a missed head vote only forgoes its share. -### Attestation Rewards +The Beacon API provides `ideal_rewards` for an epoch — the most a validator could have earned with optimal performance. The attester score compares actual to ideal: -85% of validator rewards come from attestations containing valuable information about consensus layer correctness and inclusion delay. +$$ +{\small \text{attester\_score} = \frac{\text{total\_rewards}}{\text{ideal\_rewards}}} +$$ -An attestation consists of three votes: -- **Head vote** -- **Source vote** -- **Target vote** +**Where:** +- `total_rewards` – sum of the Vault's validator rewards, from the Beacon API +- `ideal_rewards` – sum of the corresponding ideal rewards -If a validator votes correctly on all three with optimal inclusion delay, they receive 100% of potential reward. +:::custom-notes[How Attestations Secure Ethereum] +New to attestations? Each one is a validator's vote on the state of the chain. -### Calculation Method +The chain runs in **epochs** split into **slots** (32 on Ethereum, 16 on Gnosis), and each validator attests once per epoch. The first slot of an epoch is its **checkpoint**, a shared reference point the network justifies and finalizes. -The beacon node API provides `idealReward` for an epoch representing maximum potential rewards based on optimal performance, allowing us to calculate attester efficiency: +An attestation's three votes do two jobs: -:::custom-notes[Formula: Attester Score] -``` -attester_score = total_rewards / ideal_rewards -``` +- **Keep growing** — the *head vote* names the current tip to build on (fork-choice rule LMD-GHOST). +- **Lock in history** — the *source* and *target* votes finalize old blocks (Casper FFG). The **source** is the latest checkpoint already justified; the **target** is the one being justified next. -**Where:** -- `total_rewards` – Sum of validators rewards fetched via beacon API -- `ideal_rewards` – Sum of ideal rewards fetched via beacon API +When two-thirds of staked ETH back the same source→target link, the target is **justified**; once the next checkpoint is justified too, it becomes **finalized**. Reversing a finalized checkpoint would take a third of all staked ETH being slashed, and that cost is the finality guarantee. + +For more, see [Ethereum's Gasper overview ↗](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/gasper/). ::: -The attester score is determined from statistics collected over the **past 7 days**. +## Proposer Performance — 20% -### Sync Committee Exclusion +Proposer performance is **20% of the Vault score**. -:::custom-info[Why Sync Committee is Ignored] -Sync committee rewards are excluded from calculations as they constitute only 3% of consensus layer rewards and depend entirely on luck. -::: +Every so often, a validator is randomly chosen to **propose** a block. Because the payout — transaction-fee tips and **MEV** (*maximal extractable value*: extra value from how transactions are ordered) — swings wildly from block to block, the score ignores *how much* a block earns and counts only *whether* an assigned block was proposed. This keeps the metric about reliability, not luck. -## Final Scoring Formula +$$ +{\small \text{proposal\_score} = \frac{\text{proposed\_block\_count}}{\text{proposed\_block\_count} + \text{missed\_block\_count}}} +$$ -The overall Vault performance combines both proposer and attester scores with weighted importance: +**Where:** +- `proposed_block_count` – Number of blocks the validator successfully proposed +- `missed_block_count` – Number of blocks the validator was assigned but missed -:::custom-notes[Formula: Overall Score] -``` -score = (8/10 * attestations_score + 2/10 * proposal_score) * 100 -``` +A missed proposal only forgoes its reward; there's no extra penalty. A block also counts as **missed** if its fees or MEV go to the wrong address, which lowers the Vault's score. -This formula reflects that attestations are the primary source of validator rewards (80% weight), while block proposals provide additional value (20% weight). -::: +## Final Scoring Formula -## Performance Grades +The overall Vault score combines the two components by weight: -Vault grades are calculated based on the average performance over the last **7 days**: +$$ +{\small \text{score} = \left( \frac{8}{10} \times \text{attester\_score} + \frac{2}{10} \times \text{proposal\_score} \right) \times 100} +$$ - - - **99.6-100%** +The **80/20 split is StakeWise's own choice**, not the protocol's exact reward split. It keeps the metric simple while still reflecting reality: attestations do most of the work and are the steadiest signal of real performance, whereas proposals — and the MEV attached to them — are unpredictable, since a validator can be offline for five minutes and miss its only block of the week. - - No missed blocks or a very small percentage of them - - Validators perform excellently in attestations - - Less than 0.5% missed attestation rewards - - - **99.2-99.6%** +This is a deliberate simplification of beaconcha.in's [BeaconScore ↗](https://docs.beaconcha.in/beaconscore/introduction), which is **reward-weighted** across *three* duties, with each weight set by that duty's share of ideal reward over the window. Long-term, those shares track the protocol's reward budget: - - No missed blocks or a very small percentage of them - - Validators perform well in attestations - - Less than 1% missed attestation rewards - - - **97.1-99.2%** +- ~84% attestation duties (54/64) +- ~13% block proposals (8/64) +- ~3% sync committee duties (2/64) - - The Vault has issues - - Up to 3% missed attestations and/or blocks - - - **0-97.1%** +StakeWise uses just two components — **attester (80%)** and **proposer (20%)** — and leaves sync committee duty out of the score entirely, so a Vault's grade comes down to the two duties that dominate day to day and are most within an operator's control. - - Validators are not performing correctly - - Missing blocks or poorly handling attestations - - +:::custom-info[MetaVaults] +A MetaVault has no validators of its own — it spreads deposits across several Sub-vaults. Its performance score is the **share-weighted average** of its Sub-vaults' scores, so each Sub-vault influences the grade in proportion to how much stake sits in it: + +$$ +{\small \text{score}_{\text{meta}} = \frac{\sum_i \text{score}_i \times \text{shares}_i}{\sum_i \text{shares}_i}} +$$ -:::custom-notes[Further Reading] -Learn more about tracking performance metrics in [Monitoring →](../../operator/operator-monitoring) and [Rated Network integration →](../../operator/manage-validators/rated-network). +**Where:** +- $\text{score}_i$ – the performance score of Sub-vault $i$, computed with the 80/20 formula above +- $\text{shares}_i$ – Sub-vault $i$'s total shares (its size) + +Larger Sub-vaults move the MetaVault's score more than smaller ones. A MetaVault is scored only once **all** of its Sub-vaults have a score; if any is still unscored, it stays unscored rather than showing a partial average. Nested MetaVaults resolve **bottom-up**: the innermost are scored first, feeding into their parents. ::: + +
+ 1. The three votes differ in how quickly they must be included. The source vote must be recorded within 5 slots (its inclusion deadline), and the head vote in the very next slot. Since [EIP-7045 ↗](https://eips.ethereum.org/EIPS/eip-7045), the target vote has no separate inclusion deadline; it counts anywhere within the valid inclusion window, which the EIP extended to the end of the next epoch. + ↩ +
diff --git a/docs/docs/vaults/vault-types.mdx b/docs/docs/vaults/vault-types.mdx new file mode 100644 index 00000000..0d4cec9b --- /dev/null +++ b/docs/docs/vaults/vault-types.mdx @@ -0,0 +1,51 @@ +--- +title: Vault Types +description: Explore StakeWise Vault types — Standard, ERC-20, Private, Blocklist, and MetaVault — and how each serves different staking use cases. +--- + +import Image from '@theme/IdealImage' + +Each Vault is [assembled from modules](./technical-architecture#modular-design) that define how it operates, and different combinations produce different Vault types. The **Standard** Vault is the base type: adding a tokenization module makes its shares a transferable token (**ERC-20**), a whitelist module only allows deposits from approved addresses (**Private**), and a blocklist module blocks specific addresses from depositing (**Blocklist**). + +There is also a special type — the **MetaVault** — which doesn't run validators itself but delegates staking to underlying sub-vaults. Like the Standard Vault, it can layer on the same tokenization (**ERC-20**) and whitelist (**Private**) modules. + +Every Vault supports optional osToken minting via the [`VaultOsToken`](../../contracts/api/vaults/modules/VaultOsToken) module, letting depositors [mint osToken](/staker/vault-staking) against their staked position as collateral. + +A Vault's type is set once at deployment. + +Vault Types + +## Standard Vault + +The default Vault type. Accepts deposits from any wallet and issues non-transferable shares that represent each depositor's proportional stake and accrued rewards. Best suited for solo stakers and open pooled staking, where transferability of the staked position isn't required. + +## ERC-20 Vault + +Issues Vault shares as a transferable ERC-20 token, letting operators build a DeFi ecosystem around the Vault's own token. The operator sets the token's name and symbol (e.g., `mntETH`), so it appears in most portfolio trackers. Users can move the token freely — or put it to work as collateral, for example to [borrow against it on Morpho ↗](https://blog.stakewise.io/guide/stakewise-morpho-borrow-against-your-vault-token-without-unstaking) — as long as their remaining balance still covers any minted osToken position at the current LTV. + +## Private Vault + +Accepts deposits only from wallets whitelisted by the Whitelist Manager. Useful for permissioned staking setups of all kinds — from institutional pools with KYC requirements, to DAO treasuries restricted to members, to community Vaults limited to a pre-approved group. + +## Blocklist Vault + +Open to any wallet by default, but the Blocklist Manager can block specific addresses from depositing. This is useful for meeting sanctions or compliance requirements, or enforcing community moderation decisions, without restricting everyone else. + +## MetaVault + +MetaVaults Architecture Diagram + +A MetaVault is a specialized Vault that doesn't run validators itself. Instead, it accepts deposits and routes them across a set of underlying Vaults — called *sub-vaults* — which handle validator operations. Just like with a regular Vault, stakers can mint osToken against their position and burn it to unlock their stake at any time. + +### Use Cases + +Any third party can deploy a MetaVault permissionlessly, which opens up modular, layered staking strategies: + +- [Diversified staking ↗](https://blog.stakewise.io/guide/diversified-staking-with-metavaults) — spread stake across multiple operators through a single MetaVault, reducing single-operator exposure, optimizing fees, and giving stakers one place to deposit, withdraw, and manage their osToken position. +- [Dedicated MetaVaults for clients ↗](https://blog.stakewise.io/guide/setting-up-per-client-metavaults) — create a separate MetaVault for each client while routing all deposits into a shared Regular Vault. This keeps client funds isolated, supports per-client fees, delivers higher and more stable APY, and simplifies operations by managing a single validator fleet. + +### How MetaVaults Work + +Allocation is handled by a **Curator** — a contract that decides how deposited assets are distributed to and withdrawn from sub-vaults. Curator contracts must be approved by the DAO and registered in the [`CuratorsRegistry` ↗](https://etherscan.io/address/0xa23F7c8d25f4503cA4cEd84d9CC2428e8745933C#code). Currently, one Curator is available: the [`BalancedCurator` ↗](https://etherscan.io/address/0xe01351f866C118FbD04d222f9262A470F1d44d90#code), which spreads deposits and withdrawals evenly across sub-vaults. + +Before routing, the `BalancedCurator` checks each sub-vault's remaining capacity and distributes within those limits, filling each sub-vault up to its cap and skipping any that are already full. This means deposits continue to succeed even when one sub-vault in the set has reached its cap, instead of the entire deposit reverting. A MetaVault can route across up to 50 sub-vaults. diff --git a/operator/create-regular-vault.mdx b/operator/create-regular-vault.mdx index 20420e1e..44513a35 100644 --- a/operator/create-regular-vault.mdx +++ b/operator/create-regular-vault.mdx @@ -38,7 +38,7 @@ Vault type is set once at creation — select **Regular Vault**. You can optiona Configure your Vault parameters. Most of these parameters are permanent — only the [Vault fee](/docs/fees/intro#vault-fee) can be changed after creation: -- **Vault capacity** – Set maximum [ETH capacity](/docs/vaults/customization#capacity) (default: unlimited ∞). +- **Vault capacity** – Set maximum [asset capacity](/docs/vaults/configuration#capacity) (default: unlimited ∞). - **Vault fee** – Vault fee percentage applied to users' staking rewards, in addition to sub-vault fees. If you enabled the **ERC-20 Token**, you will also need to set: @@ -51,7 +51,7 @@ The Vault Fee can be updated after creation via **Settings → Vault fee → Edi ## Step 3: Block Rewards Destination -Choose [how block rewards are distributed](/docs/vaults/customization#mev-strategy). This is a **permanent decision**. +Choose [how block rewards are distributed](/docs/vaults/configuration#mev-strategy). This is a **permanent decision**. Most operators choose Smoothing Pool for stable returns, while Vault Escrow gives you full control but with volatile rewards. diff --git a/operator/introduction.mdx b/operator/introduction.mdx index 7a5df893..c0afd11e 100644 --- a/operator/introduction.mdx +++ b/operator/introduction.mdx @@ -29,7 +29,7 @@ What you can earn depends on your strategy but your earnings mainly consist of: A Vault with 1,000 ETH staked at ~3.5% APY and a 5% fee earns approximately 1.75 ETH/year in operator fees. At 10,000 ETH, that becomes 17.5 ETH/year. ::: -- [MEV rewards](/docs/vaults/customization#mev-strategy) — Choose between the Smoothing Pool (rewards are shared across participating Vaults proportional to their size, more consistent) or Own MEV Escrow (your Vault keeps all its MEV, higher upside but more variable). +- [MEV rewards](/docs/vaults/configuration#mev-strategy) — Choose between the Smoothing Pool (rewards are shared across participating Vaults proportional to their size, more consistent) or Own MEV Escrow (your Vault keeps all its MEV, higher upside but more variable). ## What Are the Costs? diff --git a/operator/meta-vault/create-meta-vault.mdx b/operator/meta-vault/create-meta-vault.mdx index 8a8d7245..dc233c7b 100644 --- a/operator/meta-vault/create-meta-vault.mdx +++ b/operator/meta-vault/create-meta-vault.mdx @@ -35,7 +35,7 @@ Vault type is set once at creation — select **MetaVault**. You can optionally Configure your Vault parameters. Most of these parameters are permanent — only the [Vault fee](/docs/fees/intro#vault-fee) can be changed after creation: -- **Vault capacity** – Set maximum [ETH capacity](/docs/vaults/customization#capacity) (default: unlimited ∞). +- **Vault capacity** – Set maximum [staked assets capacity](/docs/vaults/configuration#capacity) (default: unlimited ∞). - **Vault fee** – The fee percent your Vault will charge from users' staking rewards. If you enabled the **ERC-20 Token**, you will also need to set: diff --git a/operator/meta-vault/overview.mdx b/operator/meta-vault/overview.mdx index cef61ab7..d1275947 100644 --- a/operator/meta-vault/overview.mdx +++ b/operator/meta-vault/overview.mdx @@ -7,7 +7,7 @@ import Image from '@theme/IdealImage' # MetaVault -A [MetaVault](/docs/vaults/meta-vaults) doesn't run validators — it delegates deposited assets to sub-vaults that run validators on its behalf. Because there's no validator infrastructure to configure, the creation flow is shorter than for a Regular Vault. +A [MetaVault](/docs/vaults/vault-types#metavault) doesn't run validators — it delegates deposited assets to sub-vaults that run validators on its behalf. Because there's no validator infrastructure to configure, the creation flow is shorter than for a Regular Vault. Once the MetaVault is created, start the Operator Service to keep it in sync with its sub-vaults — harvesting rewards, claiming completed exit requests, and forwarding new deposits down to the sub-vaults. diff --git a/redirects.ts b/redirects.ts index 07ed5870..c3ccd69b 100644 --- a/redirects.ts +++ b/redirects.ts @@ -35,6 +35,14 @@ export default [ from: '/operator/additional-actions/add-extra-rewards', to: '/operator/manage-vault/add-extra-rewards', }, + { + from: '/docs/vaults/customization', + to: '/docs/vaults/configuration', + }, + { + from: '/docs/vaults/meta-vaults', + to: '/docs/vaults/vault-types#metavault', + }, { from: '/docs/governance/dao-treasury', to: '/docs/governance/treasury', diff --git a/sidebars.ts b/sidebars.ts index 0181b796..aa7c7df7 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -26,11 +26,11 @@ const sidebars: SidebarsConfig = { }, items: [ 'docs/vaults/how-vaults-work', - 'docs/vaults/customization', + 'docs/vaults/vault-types', + 'docs/vaults/configuration', 'docs/vaults/vault-performance', 'docs/vaults/boost', 'docs/vaults/technical-architecture', - 'docs/vaults/meta-vaults' ], }, { diff --git a/staker/rewards.mdx b/staker/rewards.mdx index dbd4227a..61d09b5d 100644 --- a/staker/rewards.mdx +++ b/staker/rewards.mdx @@ -20,6 +20,6 @@ On top of these rewards, [Boost](/staker/boost) further amplifies your APY by us If a Vault's validators are penalized or slashed, the loss works the same way in reverse — the Vault's total ETH decreases, reducing the value of each share proportionally across all stakers in that Vault. Penalties in one Vault do not affect stakers in other Vaults, so your risk depends on the Vault you choose and the quality of its operators.
- 1. MEV rewards are highly volatile. To smooth this out, StakeWise offers a [Smoothing Pool](/docs/vaults/customization#smoothing-pool--pooled-rewards) — a shared escrow where MEV rewards from all participating Vaults are pooled and redistributed proportionally to each Vault's stake, resulting in a steadier yield. Each Vault's MEV strategy is shown on its page. + 1. MEV rewards are highly volatile. To smooth this out, StakeWise offers a [Smoothing Pool](/docs/vaults/configuration#smoothing-pool) — a shared escrow where MEV rewards from all participating Vaults are pooled and redistributed proportionally to each Vault's stake, resulting in a steadier yield. Each Vault's MEV strategy is shown on its page. ↩
diff --git a/staker/risks.mdx b/staker/risks.mdx index 89b06bbe..4e06a2b3 100644 --- a/staker/risks.mdx +++ b/staker/risks.mdx @@ -23,4 +23,4 @@ osETH could temporarily trade below its fair value on secondary markets. The pro ## Boost -As with any leveraged strategy, [Boost](/docs/vaults/boost) carries liquidation and penalty risks. If Aave's borrow rate exceeds the staking rate for too long, your Boost APY turns negative and your position loses value every day it stays open, while your LTV drifts toward Aave's liquidation threshold. A [2% safety buffer](/docs/vaults/boost#safety-mechanisms) between max borrow LTV and the liquidation threshold gives your position room to absorb this drift, and StakeWise automatically unboosts as you approach the threshold. Stay updated via [StakeWise Discord ↗](https://discord.com/invite/2BSdr2g). +As with any leveraged strategy, [Boost](/docs/vaults/boost) carries liquidation and penalty risks. If Aave's borrow rate exceeds the staking rate for too long, your Boost APY turns negative and your position loses value every day it stays open, while your LTV drifts toward Aave's liquidation threshold. A [2% safety buffer](/docs/vaults/boost#safety) between max borrow LTV and the liquidation threshold gives your position room to absorb this drift, and StakeWise automatically unboosts as you approach the threshold. Stay updated via [StakeWise Discord ↗](https://discord.com/invite/2BSdr2g). diff --git a/staker/simple-staking.mdx b/staker/simple-staking.mdx index f39b3c2b..f41f0ed5 100644 --- a/staker/simple-staking.mdx +++ b/staker/simple-staking.mdx @@ -8,7 +8,7 @@ import Tooltip from '@site/src/components/Tooltip/Tooltip'; # Simple Staking -The simplest way to stake with StakeWise is through the [StakeWise App ↗](https://app.stakewise.io) — deposit any amount of ETH and stake it in a single click. Your assets are routed through a [MetaVault](/docs/vaults/meta-vaults) that distributes them across the best-performing Sub-vaults — currently just the [Genesis Vault](https://app.stakewise.io/vault/mainnet/0xac0f906e433d58fa868f936e8a43230473652885), with more to come. +The simplest way to stake with StakeWise is through the [StakeWise App ↗](https://app.stakewise.io) — deposit any amount of ETH and stake it in a single click. Your assets are routed through a [MetaVault](/docs/vaults/vault-types#metavault) that distributes them across the best-performing Sub-vaults — currently just the [Genesis Vault](https://app.stakewise.io/vault/mainnet/0xac0f906e433d58fa868f936e8a43230473652885), with more to come. When staking, you'll automatically receive [osETH](/docs/ostoken/intro), which represents your staked assets plus accumulated rewards. osETH can be used [across DeFi to boost your yield](https://app.stakewise.io/ecosystem). diff --git a/static/icons/stakewise/green.png b/static/icons/stakewise/green.png new file mode 100644 index 00000000..996e4786 Binary files /dev/null and b/static/icons/stakewise/green.png differ diff --git a/static/icons/stakewise/orange.png b/static/icons/stakewise/orange.png new file mode 100644 index 00000000..be8e8449 Binary files /dev/null and b/static/icons/stakewise/orange.png differ diff --git a/static/icons/stakewise/red.png b/static/icons/stakewise/red.png new file mode 100644 index 00000000..b2c0635e Binary files /dev/null and b/static/icons/stakewise/red.png differ diff --git a/static/icons/stakewise/yellow.png b/static/icons/stakewise/yellow.png new file mode 100644 index 00000000..1a59e88c Binary files /dev/null and b/static/icons/stakewise/yellow.png differ