Collateral Risk Assessment - StakeWise Staked ETH (osETH)
Collateral Risk Assessment - StakeWise Staked ETH (osETH)
Collateral Risk Assessment - StakeWise Staked ETH (osETH)
Useful Links
Website: stakewise.io
Documentation: docs.stakewise.io
Social: twitter.com/stakewise_io
Contracts: github.com/stakewise/contracts
Markets: UniswapV3 (osETH/USDC), BalancerV2 (osETH/WETH), Curve (osETH/rETH)
Introduction
This report is conducted by the Prisma independent risk and research team operated by Llama Risk as part of a series on LSD collateral risk assessments. In this report, we examine StakeWise's osETH.
This report will comprehensively cover all relevant risk factors of StakeWise's osETH for collateral onboarding. Our approach involves both quantitative and qualitative analysis to help determine whether the collateral can be safely onboarded and to what extent there should be restrictions on the Protocol's exposure to the collateral.
As Prisma will be onboarding a variety of LSDs as collateral, our review involves comparative analysis to determine suitability as collateral. Risks are categorized into:
Market Risk - risks related to market liquidity and volatility
Technology Risk - risks related to smart contracts, dependencies, and Oracle price feeds
Counterparty Risk - risks related to governance, centralization vectors, and legal/regulatory considerations
These risk categories will be summarized in the final section of this report and are meant to assist tokenholders in their determination around osETH onboarding and setting suitable parameters.
Section 1: Protocol Fundamentals
This section addresses the fundamentals of the proposed collateral. It is essential to convey (1) the value proposition of osETH, and (2) the overall architecture of the Protocol. This section contains descriptive elements that cannot be quantified and act as an explanatory introduction to the collateral.
This section is divided into two sub-sections:
1.1: Description of the Protocol
1.2: System Architecture
1.1 Description of the Protocol
StakeWise is a platform that offers liquid staking services and infrastructure enabling liquid staking markets. In its V3 version, StakeWise introduced the osETH liquid staking token — which stands for overcollateralized staked ETH. Through a unified and flexible infrastructure based on the ERC4626 vault standard, stakers can stake and mint osETH tokens against their share of a vault through three main pathways:
One click staking. Users can easily stake their ETH by depositing it into the StakeWise-managed GenesisVault, which automatically converts 100% of the deposited ETH into osETH tokens. This simple staking solution allows users to earn staking rewards without the need to actively manage their stake or maintain any infrastructure, as StakeWise handles all the technical aspects of staking on their behalf.
Stake within a specific vault. A marketplace of vault operators where anyone can create and manage a vault with custom parameters. Stakers can select the vault with the parameters and performance track records that suit their needs while still being able to mint osETH against their stake. The staking rewards and penalties are specific to the vault selected by the staker. Four different types of vaults can be created by combining the possibility of having the vault public or private and by enabling the creation of a vault token or not. MEV smoothing and block relays are also some of the vault's specific features.
Solo staking. Solo stakers can liquify their stake by creating a private vault and staking their own ETH. By doing so, they control the infrastructure that secures their stake and can select their node clients, MEV relay, and potentially enable DVT to maximize attestation performance and reliability. The osETH minting fee is still collected by the StakeWise DAO.
Regardless of how a staker uses the protocol, the same osETH liquid staking token can be minted. Its value is guaranteed by a complex set of mechanisms that makes it usable across DeFi as an ETH staking derivative.
1.1.1 Underlying Collateral
osETH is a yield-bearing asset with a soft peg to ETH. It follows a repricing pattern, where a fixed quantity of osETH is backed and can be exchanged for a given amount of ETH in the protocol over time. The exchange rate between osETH and ETH is determined at the smart contract level based on the total amount of ETH staked in the protocol, the total supply of osETH tokens minted, and the combined performance of all vaults.
To obtain osETH, users must deposit ETH into a vault. An off-chain service called the Operator, managed by the vault's admin, periodically checks the vault's balance to create new validators. The number of validators created equals the modulo 32 of the vault's address, as each validator requires exactly 32 ETH. Any remaining ETH stays in the vault until enough is accumulated to create the next validator, ensuring optimal use of the deposited ETH.
Once ETH is deposited into a vault, a staker can mint osETH against their share of the vault, with a maximum collateralization threshold of 90%. In section 1.1.6, we detail the mechanisms used to maintain this threshold. Maintaining proper collateralization across all vaults is crucial for ensuring the stability and security of osETH, as the token can be minted against various vaults managed by different operators. By isolating the performance and risk of each vault, the protocol protects all osETH holders and maintains the value of osETH against ETH.
The maximum 90% Loan-to-Value (LTV) ratio, enforced in each vault, ensures a minimum 3.2 ETH buffer per validator to absorb potential staking penalties without impacting osETH holders. If a validator is slashed, the protocol can withstand a loss of approximately 1 ETH under normal conditions. However, the severity of the slashing penalty increases proportionately with the number of validators that were slashed within the last 36 days, with all the stake being lost if that value reaches more than 33%. However, this extreme penalty is unlikely, and in practice, a 10% buffer sufficiently protects osETH holders and ensures the stability and resilience of the StakeWise protocol.
1.1.2 Yield Accrual Mechanism
Being a repricing token, osETH can be exchanged for a dynamically adjusted amount of ETH staked in the StakeWise protocol. The rate, called fair exchange rate, is calculated by the StakeWise smart contract and can be viewed in the PriceFeed contract. At launch, one osETH was equal to 1 ETH. The rate of increase, known as the osETH APY, is publicly disclosed on the StakeWise landing page and is net of the vault fee, which is 5% for the main StakeWise-operated vault (the GenesisVault).
Source: Stakewise main page - May 9th, 2024
Source: Etherscan - May 9th, 2024
The osETH APY is calculated as a weighted average of the net APY from all vaults with a fee percentage less than or equal to 15% and at least one registered validator. Each vault's net APY is determined by taking the sum of consensus and execution rewards, subtracting the vault fee, and dividing the result by the product of the number of validators activated at least 6 hours ago and their effective balance.
It is important to note that the exchange rate combines all vault's APY, which means it can be lower or higher than a specific vault's APY. The APY that osETH yields is collectivized and not bound to the particular vault from which it was minted. Therefore, the outperformance or underperformance of a specific vault relative to the exchange rate is that of the particular vault operator and not the collective of all osETH users.
1.1.3 Provider Fee
Each vault has a specific fee, applied as a percentage of the rewards accrued by the ETH staked in the vault. The GenesisVault, the main StakeWise public vault, currently has a 5% vault fee. Vault admins can freely decide the fees for their vaults. Free market forces will then determine each vault's relative stake according to their specific characteristics. The 5% reward fee of the GenesisVault accrues to an EOA of the StakeWise DAO.
Source: Genesis vault page - May 9th, 2024
StakeWise also retains a 5% fee on rewards accumulated by osETH liquid staking tokens, regardless of the vault the osETH tokens were minted from. Because the maximum LTV of minted osETH is 90%, this 5% fee only applies to the reward accumulated by this 90% and not the total ETH staked inside the vault. The 5% osETH minting fee accrues to the StakeWise DAO multisig wallet.
1.1.4 Node Operator Set
The node operator set depends on the specific vault that is considered, since vault operators can freely decide how to operate their validators. For the main StakeWise public vault — The GenesisVault — a total of 4 professional node operators are used:
Cryptomanufaktur 9,822 validators, or 0.99% of the total staking share.
Deutsche Telekom 144 validators, less than 0.01% of total staking share.
Finoa 2,335 validators or 0.23% of total staking share.
StakeWise Labs 1,071 validators or 0.11% of total staking share.
Node operator statistics were sourced from rated.network. We show the total number of validators managed by the entity and not the number of validators managed by the entity on behalf of StakeWise specifically. For StakeWise-specific numbers, please refer to section 5.2.2.
We note the presence of Deutsche Telekom as a node operator, a German telecommunication giant and Fortune 500 company that resulted from the privatization of a state monopoly in 1995, which indicates interesting ties with the traditional telecommunication industry.
1.1.5 Validator Selection
The permissioned node operators for the GenesisVault are selected based on their track record as reliable node operators and for their historic attestation performance.
Node operators for other vaults can be professional node operators like the ones of the GenesisVault or nodes operated by the vault admin. Because of the mechanism described in the next section, osETH holders are protected from the bad performance of node operators, but not the staker which minted osETH against their share of staked ETH in a vault. In other words, the osETH APY is collectivized for osETH holders, but osETH minters are liable for the performance of the vault they minted osETH from.
1.1.6 Validator Collateralization
A maximum of 90% of the staked ETH can be used to mint osETH tokens. This can be understood as taking a collateralized loan against the staked ETH, with a maximum LTV of 90%. The following LTV threshold denominations are used:
Position is healthy if the value of minted osETH does not exceed 90% of the staked ETH.
Position health is moderate if the value of minted osETH is between 90% and 91% of the staked ETH.
Position health is risky if the value of minted osETH is between 91% and 92% of the staked ETH. Those positions will participate in the osETH redemption mechanism.
Position health is deemed unhealthy if the value of minted osETH is above 92% of the staked ETH. Those positions will be subjected to the liquidation mechanism.
Suppose all osETH tokens provide the same yield (calculated using the formula in section 1.1.2) and can be considered the same tokens. They are minted from different vaults with various performance track records, different node operators, and risk profiles. Therefore, the StakeWise protocol must ensure that any osETH can always be redeemed for its underlying ETH collateral and that only stakers who minted osETH against their staked ETH bear the risks of the specific vault they minted osETH from. This is achieved through two mechanisms: the redemption mechanism and the liquidation mechanism.
Redemption mechanism
All vaults whose position health is greater than 91.5% (called the redemption threshold and determined by the StakeWise DAO) but lower than 92% are sorted in decreasing order of position health. Then, users wishing to redeem osETH for ETH are matched to the vaults with the worst position health in priority. The fair exchange rate for osETH/ETH is used to determine how much ETH should be redeemed from those vaults using the following formula:
Amount of osETH to be redeemed = 10 * amount of osETH currently minted - 9 * amount of ETH staked / osETH exchange rate
During the withdrawal of osETH for ETH, osETH tokens are burned and redeemed for the vaults' ETH. This requires the vaults to contain unbounded ETH, which is not staked in Ethereum's consensus layer. If a vault doesn't have enough unbounded ETH available, one or more validators operated on behalf of the vault will be automatically exited to satisfy the requested withdrawal amount. It is important to note that although the staked ETH of an osETH minter is reduced in its vault, the osETH minter loss is strictly limited to the loss induced by the validators of the vault. If the osETH minter had not minted osETH against its staked ETH, it would have suffered from the same loss. In that sense, the redemption mechanism is fair to the positions of osETH minters. However, this differs from the liquidation mechanism in the next section.
Liquidation mechanism
The liquidation mechanism is a last resort tentative to maintain the LTV of of a vault below 90% despite its unhealthy status. It kicks in when a vault's position health exceeds the 92% threshold. In that case, any user can step in and burn the entire osETH position of a vault to redeem the corresponding ETH collateral, plus a 1% reward called the liquidation premium applied to the total value of the ETH redeemed. The liquidation premium acts as a penalty inflicted upon the osETH minter, incentivizing liquidators to step in and maintain the vaults' position health. After a vault liquidation, the proportion of ETH that will remain in the vault will not be 8% but approximately 7% because of the liquidation premium: osETH minters would lose approximately 1% of their staked ETH for failing to maintain the 90% maximum LTV.
According to data gathered by IntoTheBlock RiskRadar, no position has been liquidated so far. However, positions were prioritized for redemptions as their LTV increased past the 91.5% redemption threshold. It is interesting to note that, in theory, the redemption mechanism should always catch positions whose health is slowly degrading due to lower than expected performance. The liquidation mechanism should only intervene if the validators of a vault are slashed, which would instantly move the vault's individual positions above the 92% threshold without leaving enough time for the redemption threshold to correct the situation.
1.1.7 Governance Model
The StakeWise DAO governs the parameters of the StakeWise protocol. Powered by the SWISE token, it decides various aspects of the Protocol, such as staking fees, liquidity incentive campaigns, or the approval of new contract changes. Anyone can propose and discuss protocol changes on the StakeWise Forum, which counts 460 users as of April 20, 2024. If enough positive feedback is received on a proposal on the forum, the proposal goes through a vote on Snapshot.org, and must reach a voting threshold of 3M votes, where 1 SWISE token equals one vote.
If accepted by token holders, protocol changes are automatically allowed to be deployed on-chain by the protocol multisig thanks to the SafeSnap module. SafeSnap allows for the decentralized execution of governance proposals from off-chain votes. Based on an Oracle and integrating with Snapshot.org and a Gnosis Safe, SWISE token holders can create multisig transactions independently from the multisig signers. However, it is important to note that the final execution (or rejection) of the multisig transaction is in the hands of the multisig signers. They can cancel or refuse to execute a transaction with at least four signatures.
The StakeWiseV3 documentation states that, in the future, the DAO Treasury committee will be dissolved and that SWISE token holders can submit SWISE bonds and vote on whether or not the transaction should be executed.
The Safe multisig signers are the following public persona:
1.2 System Architecture Diagram
1.2.1 Network Architecture Overview
StakeWise V3 architecture is built around vaults, which are essentially pools of stakers. These vaults adhere to the ERC-4626 Tokenized Vault Standard, ensuring compatibility and ease of integration with other systems. To better understand the StakeWise V3 ecosystem, examining the architecture from the perspectives of different stakeholders involved in the process is helpful.
Vault operators
Anyone can create a vault and become its admin by interacting with one of the four vault factories. We currently count 79 vaults. Four of them are blacklisted in the UI, as they seem to be the result of a manual deployments that went wrong — their contract either contain no code or have wrong parameters like a 0% vault fee. Each vault factory is a smart contract that has the responsibility to create ERC-4626 vault contracts on demand:
The Protocol keeps track of existing vaults through the VaultRegistry smart contract. For validators to secure the stake of a vault, the vault admin must install an off-chain service called the Operator, linking it to its node clients and validators on one side and to the vault contract on the other.
osETH minter
Stakers can choose a vault that aligns with their desired characteristics and preferences. Stakers start earning rewards as soon as they deposit ETH into a vault. Minting osETH is a separate process where the staker can decide to mint up to 90% of their stake and receive osETH tokens. In that case, they are responsible for maintaining their LTV below 90% or risk being subjected to the liquidation mechanism.
If an osETH minter wants to retrieve 100% of their staked ETH, they must return the total balance of osETH minted against their stake. If the vault went through the redemption or liquidation processes, they might receive less than 100% of the ETH they initially deposited. Therefore, they bear more risks than a simple staker.
Simple staker
A simple staking web modal can exchange one's ETH for osETH directly. In practice, this uses the GenesisVault operated by StakeWise. Simple stakers do not have to worry about their position's health since they did not mint osETH tokens themselves.
1.2.2 Architecture Diagram
Source: StakeWise documentation, April 20th, 2024
Aside from the vault type and fee, each vault can decide to register into the StakeWise MEV smoothing pool. Because block proposals and MEV rewards follow a long tail distribution, small vaults will, on average, significantly increase their overall staking APY by signing into the smoothing pool. Vaults that don't want to can also use the block relay of their choice or build their own blocks.
Source: StakeWise documentation, April 20th, 2024
1.2.3 Key Components
osETH
At its core, osETH is an ERC20 contract, which tracks user balances and enables the transfer of osETH. The minting of new osETH tokens is controlled by the OsTokenVaultController contract, which tracks accrued rewards and vaults' position health. Through the Keeper contract, off-chain oracles update the accrued rewards periodically in the OsTokenVaultController contract, which updates the osETH/ETH exchange rate.
The OsTokenVaultController contract calls the mint function of the OsToken contract when stakers want to borrow osETH against their ETH stake in a vault. The OsTokenVaultController contract is also responsible for keeping track of the primary exchange rate between osETH and ETH.
The parameters of the redemption and liquidation mechanisms are set by the StakeWise DAO in the OsTokenConfig contract. It includes the maximum LTV (90% as of Tuesday, April 30, 2024) and the liquidation threshold (92%).
Vaults
Vaults are created by calling the VaultFactory contract, and are all registered in the VaultRegistry contract. When a staker wants to mint osETH against their staked ETH, they call the vault contract, which first verifies the LTV of the staker by calling the OsTokenConfig contract and requests the minting of new osETH tokens by calling the OsTokenVaultController contract.
The presence of an ERC-20 vault token enables advanced use cases for sub-communities formed on top of the StakeWise V3 protocol. The most common type of vault is public without a token since it allows stakers to delegate their stake to an operator in exchange for a vault fee. In practice, we have not seen any vault that proposed a vault token with a significant TVL.
Keeper contract
The Keeper contract is responsible for gathering and validating reports from a network of off-chain oracles. Oracles can be updated by the owner of the contract, which is the StakeWise multisig.
Every 12 hours, off-chain oracles participate in a majority vote with a voting threshold of 6/11. The reward per second rate update is limited to a maximum corresponding to approximately ~22% APR to avoid oracle manipulations, resulting in an unfair exchange rate that an attacker could use to steal funds from the Protocol. The updateRewards method of the Keeper contract is called by the Oracles with the following structure:
/**
* @notice A struct containing parameters for rewards update
* @param rewardsRoot The new rewards merkle root
* @param avgRewardPerSecond The new average reward per second
* @param updateTimestamp The update timestamp used for rewards calculation
* @param rewardsIpfsHash The new IPFS hash with all the Vaults' rewards for the new root
* @param signatures The concatenation of the Oracles' signatures
*/
struct RewardsUpdateParams {
bytes32 rewardsRoot;
uint256 avgRewardPerSecond;
uint64 updateTimestamp;
string rewardsIpfsHash;
bytes signatures;
}Source: Keeper contract source code (12-05-24)
The Keeper contract is also a registry of all validators operating in all vaults. It approves new validators' requests and keeps track of their exit signatures on-chain. This way, the StakeWise protocol can unilaterally decide to exit validators regardless of the node operator's cooperation and retrieve users' funds. The updateExitSignatures method of the Keeper contract is called by the Oracles with the IPFS hash of the validator exit signatures as argument, as well as the approveValidators method with the following structure:
/**
* @notice Struct for approving registration of one or more validators
* @param validatorsRegistryRoot The deposit data root used to verify that oracles approved validators
* @param deadline The deadline for submitting the approval
* @param validators The concatenation of the validators' public key, signature and deposit data root
* @param signatures The concatenation of Oracles' signatures
* @param exitSignaturesIpfsHash The IPFS hash with the validators' exit signatures
*/
struct ApprovalParams {
bytes32 validatorsRegistryRoot;
uint256 deadline;
bytes validators;
bytes signatures;
string exitSignaturesIpfsHash;
}Source: Keeper contract source code (12-05-24)
Section 2: Performance Analysis
This section evaluates osETH from a quantitative perspective. It analyzes token usage and competitive metrics and addresses any subsidized economic activity.
This section is divided into three sub-sections:
2.1: Usage Metrics
2.2: Competitive Analysis Metrics
2.3: Subsidization of Economic Activity
2.1 Usage Metrics
2.1.1 Total Value Locked (TVL)
The Protocol's TVL has been largely correlated with ETH's market price. TVL in ETH terms has gradually increased until reaching a plateau of around 100K ETH.
Useful Links
Website: stakewise.io
Documentation: docs.stakewise.io
Social: twitter.com/stakewise_io
Contracts: github.com/stakewise/contracts
Markets: UniswapV3 (osETH/USDC), BalancerV2 (osETH/WETH), Curve (osETH/rETH)
Introduction
This report is conducted by the Prisma independent risk and research team operated by Llama Risk as part of a series on LSD collateral risk assessments. In this report, we examine StakeWise's osETH.
This report will comprehensively cover all relevant risk factors of StakeWise's osETH for collateral onboarding. Our approach involves both quantitative and qualitative analysis to help determine whether the collateral can be safely onboarded and to what extent there should be restrictions on the Protocol's exposure to the collateral.
As Prisma will be onboarding a variety of LSDs as collateral, our review involves comparative analysis to determine suitability as collateral. Risks are categorized into:
Market Risk - risks related to market liquidity and volatility
Technology Risk - risks related to smart contracts, dependencies, and Oracle price feeds
Counterparty Risk - risks related to governance, centralization vectors, and legal/regulatory considerations
These risk categories will be summarized in the final section of this report and are meant to assist tokenholders in their determination around osETH onboarding and setting suitable parameters.
Section 1: Protocol Fundamentals
This section addresses the fundamentals of the proposed collateral. It is essential to convey (1) the value proposition of osETH, and (2) the overall architecture of the Protocol. This section contains descriptive elements that cannot be quantified and act as an explanatory introduction to the collateral.
This section is divided into two sub-sections:
1.1: Description of the Protocol
1.2: System Architecture
1.1 Description of the Protocol
StakeWise is a platform that offers liquid staking services and infrastructure enabling liquid staking markets. In its V3 version, StakeWise introduced the osETH liquid staking token — which stands for overcollateralized staked ETH. Through a unified and flexible infrastructure based on the ERC4626 vault standard, stakers can stake and mint osETH tokens against their share of a vault through three main pathways:
One click staking. Users can easily stake their ETH by depositing it into the StakeWise-managed GenesisVault, which automatically converts 100% of the deposited ETH into osETH tokens. This simple staking solution allows users to earn staking rewards without the need to actively manage their stake or maintain any infrastructure, as StakeWise handles all the technical aspects of staking on their behalf.
Stake within a specific vault. A marketplace of vault operators where anyone can create and manage a vault with custom parameters. Stakers can select the vault with the parameters and performance track records that suit their needs while still being able to mint osETH against their stake. The staking rewards and penalties are specific to the vault selected by the staker. Four different types of vaults can be created by combining the possibility of having the vault public or private and by enabling the creation of a vault token or not. MEV smoothing and block relays are also some of the vault's specific features.
Solo staking. Solo stakers can liquify their stake by creating a private vault and staking their own ETH. By doing so, they control the infrastructure that secures their stake and can select their node clients, MEV relay, and potentially enable DVT to maximize attestation performance and reliability. The osETH minting fee is still collected by the StakeWise DAO.
Regardless of how a staker uses the protocol, the same osETH liquid staking token can be minted. Its value is guaranteed by a complex set of mechanisms that makes it usable across DeFi as an ETH staking derivative.
1.1.1 Underlying Collateral
osETH is a yield-bearing asset with a soft peg to ETH. It follows a repricing pattern, where a fixed quantity of osETH is backed and can be exchanged for a given amount of ETH in the protocol over time. The exchange rate between osETH and ETH is determined at the smart contract level based on the total amount of ETH staked in the protocol, the total supply of osETH tokens minted, and the combined performance of all vaults.
To obtain osETH, users must deposit ETH into a vault. An off-chain service called the Operator, managed by the vault's admin, periodically checks the vault's balance to create new validators. The number of validators created equals the modulo 32 of the vault's address, as each validator requires exactly 32 ETH. Any remaining ETH stays in the vault until enough is accumulated to create the next validator, ensuring optimal use of the deposited ETH.
Once ETH is deposited into a vault, a staker can mint osETH against their share of the vault, with a maximum collateralization threshold of 90%. In section 1.1.6, we detail the mechanisms used to maintain this threshold. Maintaining proper collateralization across all vaults is crucial for ensuring the stability and security of osETH, as the token can be minted against various vaults managed by different operators. By isolating the performance and risk of each vault, the protocol protects all osETH holders and maintains the value of osETH against ETH.
The maximum 90% Loan-to-Value (LTV) ratio, enforced in each vault, ensures a minimum 3.2 ETH buffer per validator to absorb potential staking penalties without impacting osETH holders. If a validator is slashed, the protocol can withstand a loss of approximately 1 ETH under normal conditions. However, the severity of the slashing penalty increases proportionately with the number of validators that were slashed within the last 36 days, with all the stake being lost if that value reaches more than 33%. However, this extreme penalty is unlikely, and in practice, a 10% buffer sufficiently protects osETH holders and ensures the stability and resilience of the StakeWise protocol.
1.1.2 Yield Accrual Mechanism
Being a repricing token, osETH can be exchanged for a dynamically adjusted amount of ETH staked in the StakeWise protocol. The rate, called fair exchange rate, is calculated by the StakeWise smart contract and can be viewed in the PriceFeed contract. At launch, one osETH was equal to 1 ETH. The rate of increase, known as the osETH APY, is publicly disclosed on the StakeWise landing page and is net of the vault fee, which is 5% for the main StakeWise-operated vault (the GenesisVault).
Source: Stakewise main page - May 9th, 2024
Source: Etherscan - May 9th, 2024
The osETH APY is calculated as a weighted average of the net APY from all vaults with a fee percentage less than or equal to 15% and at least one registered validator. Each vault's net APY is determined by taking the sum of consensus and execution rewards, subtracting the vault fee, and dividing the result by the product of the number of validators activated at least 6 hours ago and their effective balance.
It is important to note that the exchange rate combines all vault's APY, which means it can be lower or higher than a specific vault's APY. The APY that osETH yields is collectivized and not bound to the particular vault from which it was minted. Therefore, the outperformance or underperformance of a specific vault relative to the exchange rate is that of the particular vault operator and not the collective of all osETH users.
1.1.3 Provider Fee
Each vault has a specific fee, applied as a percentage of the rewards accrued by the ETH staked in the vault. The GenesisVault, the main StakeWise public vault, currently has a 5% vault fee. Vault admins can freely decide the fees for their vaults. Free market forces will then determine each vault's relative stake according to their specific characteristics. The 5% reward fee of the GenesisVault accrues to an EOA of the StakeWise DAO.
Source: Genesis vault page - May 9th, 2024
StakeWise also retains a 5% fee on rewards accumulated by osETH liquid staking tokens, regardless of the vault the osETH tokens were minted from. Because the maximum LTV of minted osETH is 90%, this 5% fee only applies to the reward accumulated by this 90% and not the total ETH staked inside the vault. The 5% osETH minting fee accrues to the StakeWise DAO multisig wallet.
1.1.4 Node Operator Set
The node operator set depends on the specific vault that is considered, since vault operators can freely decide how to operate their validators. For the main StakeWise public vault — The GenesisVault — a total of 4 professional node operators are used:
Cryptomanufaktur 9,822 validators, or 0.99% of the total staking share.
Deutsche Telekom 144 validators, less than 0.01% of total staking share.
Finoa 2,335 validators or 0.23% of total staking share.
StakeWise Labs 1,071 validators or 0.11% of total staking share.
Node operator statistics were sourced from rated.network. We show the total number of validators managed by the entity and not the number of validators managed by the entity on behalf of StakeWise specifically. For StakeWise-specific numbers, please refer to section 5.2.2.
We note the presence of Deutsche Telekom as a node operator, a German telecommunication giant and Fortune 500 company that resulted from the privatization of a state monopoly in 1995, which indicates interesting ties with the traditional telecommunication industry.
1.1.5 Validator Selection
The permissioned node operators for the GenesisVault are selected based on their track record as reliable node operators and for their historic attestation performance.
Node operators for other vaults can be professional node operators like the ones of the GenesisVault or nodes operated by the vault admin. Because of the mechanism described in the next section, osETH holders are protected from the bad performance of node operators, but not the staker which minted osETH against their share of staked ETH in a vault. In other words, the osETH APY is collectivized for osETH holders, but osETH minters are liable for the performance of the vault they minted osETH from.
1.1.6 Validator Collateralization
A maximum of 90% of the staked ETH can be used to mint osETH tokens. This can be understood as taking a collateralized loan against the staked ETH, with a maximum LTV of 90%. The following LTV threshold denominations are used:
Position is healthy if the value of minted osETH does not exceed 90% of the staked ETH.
Position health is moderate if the value of minted osETH is between 90% and 91% of the staked ETH.
Position health is risky if the value of minted osETH is between 91% and 92% of the staked ETH. Those positions will participate in the osETH redemption mechanism.
Position health is deemed unhealthy if the value of minted osETH is above 92% of the staked ETH. Those positions will be subjected to the liquidation mechanism.
Suppose all osETH tokens provide the same yield (calculated using the formula in section 1.1.2) and can be considered the same tokens. They are minted from different vaults with various performance track records, different node operators, and risk profiles. Therefore, the StakeWise protocol must ensure that any osETH can always be redeemed for its underlying ETH collateral and that only stakers who minted osETH against their staked ETH bear the risks of the specific vault they minted osETH from. This is achieved through two mechanisms: the redemption mechanism and the liquidation mechanism.
Redemption mechanism
All vaults whose position health is greater than 91.5% (called the redemption threshold and determined by the StakeWise DAO) but lower than 92% are sorted in decreasing order of position health. Then, users wishing to redeem osETH for ETH are matched to the vaults with the worst position health in priority. The fair exchange rate for osETH/ETH is used to determine how much ETH should be redeemed from those vaults using the following formula:
Amount of osETH to be redeemed = 10 * amount of osETH currently minted - 9 * amount of ETH staked / osETH exchange rate
During the withdrawal of osETH for ETH, osETH tokens are burned and redeemed for the vaults' ETH. This requires the vaults to contain unbounded ETH, which is not staked in Ethereum's consensus layer. If a vault doesn't have enough unbounded ETH available, one or more validators operated on behalf of the vault will be automatically exited to satisfy the requested withdrawal amount. It is important to note that although the staked ETH of an osETH minter is reduced in its vault, the osETH minter loss is strictly limited to the loss induced by the validators of the vault. If the osETH minter had not minted osETH against its staked ETH, it would have suffered from the same loss. In that sense, the redemption mechanism is fair to the positions of osETH minters. However, this differs from the liquidation mechanism in the next section.
Liquidation mechanism
The liquidation mechanism is a last resort tentative to maintain the LTV of of a vault below 90% despite its unhealthy status. It kicks in when a vault's position health exceeds the 92% threshold. In that case, any user can step in and burn the entire osETH position of a vault to redeem the corresponding ETH collateral, plus a 1% reward called the liquidation premium applied to the total value of the ETH redeemed. The liquidation premium acts as a penalty inflicted upon the osETH minter, incentivizing liquidators to step in and maintain the vaults' position health. After a vault liquidation, the proportion of ETH that will remain in the vault will not be 8% but approximately 7% because of the liquidation premium: osETH minters would lose approximately 1% of their staked ETH for failing to maintain the 90% maximum LTV.
According to data gathered by IntoTheBlock RiskRadar, no position has been liquidated so far. However, positions were prioritized for redemptions as their LTV increased past the 91.5% redemption threshold. It is interesting to note that, in theory, the redemption mechanism should always catch positions whose health is slowly degrading due to lower than expected performance. The liquidation mechanism should only intervene if the validators of a vault are slashed, which would instantly move the vault's individual positions above the 92% threshold without leaving enough time for the redemption threshold to correct the situation.
1.1.7 Governance Model
The StakeWise DAO governs the parameters of the StakeWise protocol. Powered by the SWISE token, it decides various aspects of the Protocol, such as staking fees, liquidity incentive campaigns, or the approval of new contract changes. Anyone can propose and discuss protocol changes on the StakeWise Forum, which counts 460 users as of April 20, 2024. If enough positive feedback is received on a proposal on the forum, the proposal goes through a vote on Snapshot.org, and must reach a voting threshold of 3M votes, where 1 SWISE token equals one vote.
If accepted by token holders, protocol changes are automatically allowed to be deployed on-chain by the protocol multisig thanks to the SafeSnap module. SafeSnap allows for the decentralized execution of governance proposals from off-chain votes. Based on an Oracle and integrating with Snapshot.org and a Gnosis Safe, SWISE token holders can create multisig transactions independently from the multisig signers. However, it is important to note that the final execution (or rejection) of the multisig transaction is in the hands of the multisig signers. They can cancel or refuse to execute a transaction with at least four signatures.
The StakeWiseV3 documentation states that, in the future, the DAO Treasury committee will be dissolved and that SWISE token holders can submit SWISE bonds and vote on whether or not the transaction should be executed.
The Safe multisig signers are the following public persona:
1.2 System Architecture Diagram
1.2.1 Network Architecture Overview
StakeWise V3 architecture is built around vaults, which are essentially pools of stakers. These vaults adhere to the ERC-4626 Tokenized Vault Standard, ensuring compatibility and ease of integration with other systems. To better understand the StakeWise V3 ecosystem, examining the architecture from the perspectives of different stakeholders involved in the process is helpful.
Vault operators
Anyone can create a vault and become its admin by interacting with one of the four vault factories. We currently count 79 vaults. Four of them are blacklisted in the UI, as they seem to be the result of a manual deployments that went wrong — their contract either contain no code or have wrong parameters like a 0% vault fee. Each vault factory is a smart contract that has the responsibility to create ERC-4626 vault contracts on demand:
The Protocol keeps track of existing vaults through the VaultRegistry smart contract. For validators to secure the stake of a vault, the vault admin must install an off-chain service called the Operator, linking it to its node clients and validators on one side and to the vault contract on the other.
osETH minter
Stakers can choose a vault that aligns with their desired characteristics and preferences. Stakers start earning rewards as soon as they deposit ETH into a vault. Minting osETH is a separate process where the staker can decide to mint up to 90% of their stake and receive osETH tokens. In that case, they are responsible for maintaining their LTV below 90% or risk being subjected to the liquidation mechanism.
If an osETH minter wants to retrieve 100% of their staked ETH, they must return the total balance of osETH minted against their stake. If the vault went through the redemption or liquidation processes, they might receive less than 100% of the ETH they initially deposited. Therefore, they bear more risks than a simple staker.
Simple staker
A simple staking web modal can exchange one's ETH for osETH directly. In practice, this uses the GenesisVault operated by StakeWise. Simple stakers do not have to worry about their position's health since they did not mint osETH tokens themselves.
1.2.2 Architecture Diagram
Source: StakeWise documentation, April 20th, 2024
Aside from the vault type and fee, each vault can decide to register into the StakeWise MEV smoothing pool. Because block proposals and MEV rewards follow a long tail distribution, small vaults will, on average, significantly increase their overall staking APY by signing into the smoothing pool. Vaults that don't want to can also use the block relay of their choice or build their own blocks.
Source: StakeWise documentation, April 20th, 2024
1.2.3 Key Components
osETH
At its core, osETH is an ERC20 contract, which tracks user balances and enables the transfer of osETH. The minting of new osETH tokens is controlled by the OsTokenVaultController contract, which tracks accrued rewards and vaults' position health. Through the Keeper contract, off-chain oracles update the accrued rewards periodically in the OsTokenVaultController contract, which updates the osETH/ETH exchange rate.
The OsTokenVaultController contract calls the mint function of the OsToken contract when stakers want to borrow osETH against their ETH stake in a vault. The OsTokenVaultController contract is also responsible for keeping track of the primary exchange rate between osETH and ETH.
The parameters of the redemption and liquidation mechanisms are set by the StakeWise DAO in the OsTokenConfig contract. It includes the maximum LTV (90% as of Tuesday, April 30, 2024) and the liquidation threshold (92%).
Vaults
Vaults are created by calling the VaultFactory contract, and are all registered in the VaultRegistry contract. When a staker wants to mint osETH against their staked ETH, they call the vault contract, which first verifies the LTV of the staker by calling the OsTokenConfig contract and requests the minting of new osETH tokens by calling the OsTokenVaultController contract.
The presence of an ERC-20 vault token enables advanced use cases for sub-communities formed on top of the StakeWise V3 protocol. The most common type of vault is public without a token since it allows stakers to delegate their stake to an operator in exchange for a vault fee. In practice, we have not seen any vault that proposed a vault token with a significant TVL.
Keeper contract
The Keeper contract is responsible for gathering and validating reports from a network of off-chain oracles. Oracles can be updated by the owner of the contract, which is the StakeWise multisig.
Every 12 hours, off-chain oracles participate in a majority vote with a voting threshold of 6/11. The reward per second rate update is limited to a maximum corresponding to approximately ~22% APR to avoid oracle manipulations, resulting in an unfair exchange rate that an attacker could use to steal funds from the Protocol. The updateRewards method of the Keeper contract is called by the Oracles with the following structure:
/**
* @notice A struct containing parameters for rewards update
* @param rewardsRoot The new rewards merkle root
* @param avgRewardPerSecond The new average reward per second
* @param updateTimestamp The update timestamp used for rewards calculation
* @param rewardsIpfsHash The new IPFS hash with all the Vaults' rewards for the new root
* @param signatures The concatenation of the Oracles' signatures
*/
struct RewardsUpdateParams {
bytes32 rewardsRoot;
uint256 avgRewardPerSecond;
uint64 updateTimestamp;
string rewardsIpfsHash;
bytes signatures;
}Source: Keeper contract source code (12-05-24)
The Keeper contract is also a registry of all validators operating in all vaults. It approves new validators' requests and keeps track of their exit signatures on-chain. This way, the StakeWise protocol can unilaterally decide to exit validators regardless of the node operator's cooperation and retrieve users' funds. The updateExitSignatures method of the Keeper contract is called by the Oracles with the IPFS hash of the validator exit signatures as argument, as well as the approveValidators method with the following structure:
/**
* @notice Struct for approving registration of one or more validators
* @param validatorsRegistryRoot The deposit data root used to verify that oracles approved validators
* @param deadline The deadline for submitting the approval
* @param validators The concatenation of the validators' public key, signature and deposit data root
* @param signatures The concatenation of Oracles' signatures
* @param exitSignaturesIpfsHash The IPFS hash with the validators' exit signatures
*/
struct ApprovalParams {
bytes32 validatorsRegistryRoot;
uint256 deadline;
bytes validators;
bytes signatures;
string exitSignaturesIpfsHash;
}Source: Keeper contract source code (12-05-24)
Section 2: Performance Analysis
This section evaluates osETH from a quantitative perspective. It analyzes token usage and competitive metrics and addresses any subsidized economic activity.
This section is divided into three sub-sections:
2.1: Usage Metrics
2.2: Competitive Analysis Metrics
2.3: Subsidization of Economic Activity
2.1 Usage Metrics
2.1.1 Total Value Locked (TVL)
The Protocol's TVL has been largely correlated with ETH's market price. TVL in ETH terms has gradually increased until reaching a plateau of around 100K ETH.
Source: DefiLlama (27-04-24)
2.1.2 Transaction Volume
The osETH transaction volume over the observed 90-day period demonstrates significant volatility, with daily volumes ranging from a minimum of $98,539 to a maximum of $11,908,025. This high volatility is likely influenced by the activities of large-scale investors or "whales," whose substantial transactions can cause notable spikes in the trading volume. Additionally, considering osETH's characteristics as an ETH liquid staking token and a yield-bearing asset, periods of low transaction volume are expected, as investors may hold onto their assets to accrue potential yields rather than engage in frequent trading. This behavior aligns with the typical market dynamics of similar asset types in the DeFi space.
Source: IntoTheBlock - from 01-Feb to 01-May-2024
Source: IntoTheBlock - from 01-Feb to 01-May-2024
2.1.3 DEX Volume
Source: Bitquery (01-05-24)
2.1.4 Average Transaction Size
Source: IntoTheBlock - from 01-Feb to 01-May-2024
2.1.5 Trading Volume to Market Capitalization Ratio
The "Trading Volume to Market Cap Ratio" for osETH over the observed period generally shows low levels of trading activity relative to its market capitalization, averaging 0.453%. The ratio ranges from a minimum of 0.058% to a maximum of 2.167%. This low ratio typically indicates that the daily trading volume represents only a small fraction of the total market capitalization of osETH (LST Market Cap = LST protocol ETH TVL). The implication of such a low trading volume relative to market capitalization is a potentially lower liquidity risk.
Source: Defi Llama and CoinGecko (01-05-24)
2.1.6 Active Addresses/Users
Active addresses show daily unique addresses that initiate an osETH transaction.
Source: Dune (25-04-24)
2.1.7 User Growth
We measure user growth by observing unique addresses that are holders of osETH daily.
Source: Dune (25-04-24)
2.2 Competitive Analysis Metrics
2.2.1 Market Share
Source: DefiLlama (27-04-24)
StakeWise represents 0.75% of the total liquid staking market, which puts it in 8th position.
Source: DefiLlama (27-04-24)
In terms of dominance, it peaked at 8.6% of the total liquid staking market in April 2021. Competition was significantly less important at the time, and the merge had yet to happen.
2.2.2 Inflows Share
Source: Defi Llama (25-04-24)
2.2.3 Protocol Staking Yield
For the last 90 days, the average staking APY rate has been 3.61%, between 3.18% (min) and 4.72% (max).
StakeWise - daily staking APY over the last 90 days:
Source: Defi Llama - from 01-Feb to 01-May-2024
2.2.4 Slashing Rate
To our knowledge, no validator operated on behalf of StakeWise has been slashed.
2.3 Subsidization of Economic Activity
2.3.1 Existence of an Incentive Program
Main liquidity incentives
StakeWise DAO increases the liquidity of its tokens through the emission of SWISE tokens. Liquidity for StakeWise V3 was first discussed in this forum post. The main liquidity pools are:
Here is a summary of the osETH liquidity funding allocated month-over-month and the 30-day average dollar value before the snapshot proposal:
Source: StakeWise forum (25-04-24)
Allocated SWISE tokens are transferred from the DAO vesting contract to the SLC multisig (StakeWise Liquidity Committee), a 2/2 multisig. The SLC budget is revisited month-over-month. Operators of the SLC multisig are compensated with a monthly sum approximating 5000 $USD per month in SWISE tokens.
Independently, SWISE liquidity is also helped by the DAO in the UniswapV3 SWISE/ETH pool. The community discussed and approved this in this forum post. Here is a breakdown of the last months in terms of liquidity incentives:
Source: StakeWise forum (25-04-24)
We can see that the liquidity cost to the DAO drastically increased in March 2024. This is due to the significant price drop of the SWISE token and a drop in capital efficiency from the Curve and Balancer pools.
Arbitrum liquidity incentives
The StakeWise DAO applied to and was granted 300K ARB tokens from the Arbitrum Foundation, approximating a total dollar value of 300K $USD as of April 24, 2024, to bootstrapping the osETH liquidity on Arbitrum. A condition of this grant is for the StakeWise DAO to match the dollar value of this grant on a 1-1 basis for the nine months starting in August 2024. A snapshot proposal was created and accepted by the community. As of the proposal start date, this was an estimated 11,500,000 extra SWISE tokens for a dollar value of 345,000 $USD.
MorphoBlue liquidity incentives
This incentive is aimed at bootstrapping the liquidity for osETH on MorphoBlue, a decentralized lending protocol that improves the lending and borrowing rates, and where anyone can create a vault whose risk is segregated from others. Approved by the community, it targets a total incentive of 900K SWISE tokens over three months.
Section 3: Market Risk
This section addresses the ease of liquidation based on historical market conditions. It seeks to clarify (1) the Liquid Staking Basis & Volatility of osETH, and (2) the liquidity profile of the collateral. Market risk refers to the potential for financial losses resulting from adverse changes in market conditions.
This section is divided into 2 sub-sections:
3.1: Volatility Analysis
3.2: Liquidity Analysis
3.1 Volatility Analysis
3.1.1 Liquid Staking Basis (LSB)
osETH Liquid Staking Basis over the last 90 days:
Source: Etherscan and CoinGecko - from 01-Feb to 01-May-2024
The absolute osETH LSB:
Source: Etherscan and CoinGecko - from 01-Feb to 01-May-2024
Source: OsTokenVaultController contract and CoinGecko - from 01-Feb to 01-May-2024
We can observe larger deviations when osETH was first launched, which can be explained by the lower liquidity. As liquidity gradually increased over time, it helped to stabilize the secondary market rate concerning the internal exchange rate of the Protocol. Lately, we observed a small but consistent positive deviation of the secondary market rate. This can be explained by the entry queue of the Ethereum consensus, which recently reached a length of 10 days.
According to the documentation, the StakeWise withdrawal modal should automatically switch to secondary markets if the exchange rate is higher there, which benefits stakers and helps reduce the deviation of the market rate from the internal exchange rate.
3.1.2 LSD Volatility
The volatility of osETH is marginally higher than its underlying asset, ETH. The data shows that osETH's daily average volatility is 3.42%, compared to ETH's 3.37%. When extrapolated annually, osETH's volatility rises to 65.29%, compared to ETH's 64.38%.
Source: CoinGecko - from 21-Jan to 29-Apr-2024
3.1.3 Yield Volatility
Yield volatility is calculated from DeFillama data Median APY. The data is compared against the STYETH ETH staking yield index data.
Source: Defi Llama and Compass ETH Staking APY index (28-04-2024)
3.2 Liquidity Analysis
3.2.1 Supported DEXs and CEXs
osETH is only supported on the following decentralized exchanges:
Source: Nansen (28-04-2024)
3.2.2 LSD Token Total On-chain Liquidity
Source: DexGuru, Balancer and Etherscan - from 22-Mar to 01-May 2024
Liquidity can be seen to consistently be most concentrated on Balancer where it is paired with WETH.
Source: IntoTheBlock - from 31-Oct to 06-Jun 2024
3.2.3 Token Distribution
Here are the top addresses by ownership of osETH tokens.
Source: Nansen (05-May-2024)
The largest concentration of osETH tokens is in the EigenLayer osETH Strategy, holding 56.45% of the total tokens. This significant allocation suggests a strategic emphasis on restaking, which might be aimed at maximizing yield through compound staking strategies. Such a high concentration can influence the liquidity of the token and its market behavior, as a large volume is locked up and potentially less available for regular trading.
The distribution of osETH across various DEXs showcases a strategic placement of liquidity that enhances price stability on these platforms. osETH is supported on only two lending protocols: Morpho Blue, a money market with permissionless market creation, and Gravita, an ETH LST-backed CDP protocol.
3.2.4 Liquidity Utilization Rate
Source: DexGuru and Bitquery (01-May-2024)
3.2.5 LSD Leverage Ratio
osETH is supported as collateral only on two lending protocols: Morpho Blue (permissionless market creation) and Gravita (lending protocol). Morpho Blue osETH/WETH is at the moment at 49.9% Utilization rate:
Source: BlockAnalitica (28-04-2024)
For the osETH market, the Gravita protocol system utilization rate is 41.79%:
Source: Gravita protocol (28-04-2024)
3.2.6 Slippage
An analysis using DeFi Llama's "Liquidity tool" shows that a trade of 8,602.46 osETH to 8,641.50 ETH, valued at approximately $26,171,875, results in a slippage of 1.14%, indicating a moderate liquidity depth for osETH. CowSwap facilitates efficient trade execution, which reduces the price impact on large transactions.
Source: Defi Llama - Token Liquidity (28-04-2024)
Section 4: Technological Risk
This section addresses the persistence of collateral properties from a technological perspective. It aims to convey (1) where technological risk arises that can change the fundamental properties of the collateral (e.g., unresolved audit issues) and (2) do any composability/dependency requirements present potential issues (e.g., is a reliable price feed oracle available?).
This section is divided into three sub-sections:
4.1: Smart Contract Risk
4.2: Product and Layer Composability
4.3: Oracle Pricefeed Availability
4.1 Smart Contract Risk
4.1.1 Protocol Audits
The StakeWise V3 protocol has received a total of 3 audits:
Halborn (2023-05): 5 findings including one high risk.
Halborn (2023-08): 3 findings including one medium.
SigmaPrime (2023-08): 21 findings including two critical risks, five high risks, and one medium risk.
4.1.2 Concerning Audit Signs
The latest SigmaPrime audit found two significant issues related to migrating from V2 to V3. Both were acknowledged and fixed by StakeWise.
Deposits From V2 Pool Escrow Misinterpreted As User Deposit
V3 vaults usually receive ETH on two occasions: when they receive staker deposits, which triggers the receive() function, or when funds are withdrawn from the beacon chain upon validator exits. Beacon chain withdrawals are gasless transactions and do not trigger any logic in the contract.
Since the withdrawal address of validators cannot be changed once set, it is set to an intermediary contract called the PoolEscrow contract, which then sends its funds to the V3GenesisVault. Although this transaction represents a beacon chain withdrawal, it is interpreted as a regular staker deposit, which triggers the receive logic because it is a normal transaction. This causes the staking shares to be allocated to the PoolEscrow contract, which can never be redeemed. Consequently, funds received from the PoolEscrow do not increase the balance of funds allocated to existing depositor shares (whether from V2 or V3) but are allocated to spin-off validators once again.
Rewards From Stakewise V2 not Shared With V2 Stakers
This second important issue is related to the previous one. Although the team had previously communicated its intent to consider rewards from V2 stakers and V3 stakers as belonging to the same pool and therefore planning to split them evenly, it was not the case in practice. All rewards from the V2 system were found to be sent to the V3GenesisVault, which allocated 100% of them to V3 stakers. Consequently, V2 stakers would have lost rewards upon migrating to the V3 protocol.
4.1.3 Bug Bounty
A bug bounty is available on Immunefi. It started on May 31, 2022, and was last updated on April 8, 2024. A maximum bounty of 200,000$ can be claimed for critical risk vulnerabilities or 50,000$ for high-risk vulnerabilities without the need for KYC. No one was able to claim a bounty so far.
We note that the proposed bounty deviates from the industry's norm by limiting itself to 200,000$ instead of the more commonly used 10% of funds at risk. Furthermore, the payout can be made in USDC or SWISE tokens at the discretion of the StakeWise team. The limited liquidity of the SWISE token can be underwhelming when considering the maximum payout of 200,000$, with an estimated -12% loss in that case when exchanging SWISE tokens for ETH using the main pool available (UniswapV3 SWISE/ETH).
4.1.4 Immutability
Apart from the vault contracts, all contracts are immutable. Upgrades are made by deploying a new contract and then updating the contract address that each other contract references.
The StakeWise team can develop new vault contracts so that vault owners can decide to upgrade to the latest version. This is done through the VaultVersion abstract contract, which implements the UUPSUpgradeable interface. Notably, some of the vault's parameters remain immutable, like the vault's fee or the type of vault (private, public, MEV smoothing, etc). This is to protect vault stakers from any unilateral decision of the vault's admin. Some parameters, such as the allowed depositors for private vaults, can be changed after deployment.
We note that the lack of a pausing mechanism — while strengthening the permisonlessness of the Protocol — severely limits any intervention the team could make to protect it in case of active exploit. The StakeWise team can only pause osETH minting or provide vault contract updates (which vault operators would then have to accept manually).
4.1.5 Developer Activity
The number of commits through time is relatively low compared to the size and code complexity of the github.com/stakewise/v3-core repository. This is explained by using PR (pull requests) from feature branches against the repository's main branch. This workflow facilitates code reviews and visibility from other developers. Each PR seems to be related to a specific feature and can be made of many commits that were "squashed" into a single one before being merged into the main branch. In that sense, the commit history on the main branch is not representative of the level of developer activity but rather of the frequency of feature changes on the main branch.
Source: Github (23-04-2024)
We note that commits were made with cryptographic signatures on October 11, 2024, before V3 was deployed to the mainnet. This makes it more difficult for an attacker to commit malicious code to the repository, which could later be deployed on-chain. There are currently 3 PRs opened in the v3-core repository.
4.1.6 SC Maturity
A manual review of the smart contract code for V3, which is publicly available on GitHub, indicates professional development practices. Because of the flexibility of the StakeWise V3 protocol, the smart contract codebase is relatively large and complex. However, it is also highly modular and documented, which helps to navigate and understand it.
StakeWise has publicly open-sourced various git repositories, including the Operator off-chain service, developer tools like an SDK, and a Subgraph. However, the source code for the Oracle off-chain service is only available for StakeWiseV2 and not StakeWiseV3. Although this service is decentralized by being operated by 11 different entities, it is a strata-critical component that could fail or be exploited. Publicly shared audits and scrutiny could help alleviate the centralization risk it represents, as security through obscurity is generally not a recommended practise.
GitHub repositories:
4.1.7 Previous Incidents
To our knowledge, StakeWise has not been impacted by any incidents since its inception.
4.2 Product and Layer Composability
4.2.1 Dependencies
StakeWise V3 depends on two different off-chain services: the Operator and the Oracle off-chain services. The Operator off-chain service is open source, but not the Oracle. When asked about it, the StakeWise team indicated that "no plans are made to make it public in the intermediate future". They also mentionned a lack of public audit for it, but that several companies have done their due diligence and privately audited the complete StakeWise stack — including the Oracle offchain service.
Oracle offchain services
Like all liquid staking protocols deployed before EIP-4788, StakeWiseV3 relies on an off-chain service. The Oracle in StakeWiseV3 is used to automate tasks that smart contracts cannot do or provide information from outside the EVM. Despite its name, the responsibilities of an Oracle go beyond that of the reporting of consensus layer information — that is the balance of each validator and their rewards — and also include:
Registration and validation of validator keys — the withdrawal address must correspond to their vault's contract address.
Exiting validators when needed — that is, when osETH withdrawal requests for ETH are made or to facilitate both the redemption and liquidation mechanisms.
Source: StakeWise documentation (24-05-2024)
Eleven different permissioned entities operate the Oracle off-chain service with a voting threshold of seven acting as consensus. Oracle operators are known entities that the StakeWise DAO has vetted through a snapshot.org vote, and are comprised of:
Bitfly (operator of beaconcha.in)
The StakeWise development team
The Oracle network is a critical component of the StakeWiseV3 infrastructure because it reports the balances and rewards accrued by each vault. If manipulated, it could trigger either the redemption or the liquidation mechanisms on certain vaults, resulting in a loss of funds for osETH stakers. That being said, the Keeper contract, which receives information from the Oracle off-chain services, has an internal check preventing the reward rate from deviating too much from expected values.
Operator off-chain services
The Operator service acts as an intermediary between the vaults (on-chain) and the validators securing the staked ETH of that vault. Each node operator runs this off-chain service and connects it to its execution and consensus node clients. The Operator exposes two HTTP API endpoints:
GET /validatorsto retrieve available validators to be registered.POST /validatorswill be used to submit exit signatures for validators identified using the previous endpoint.GET /metricsfor Prometheus to gather information for Graphana dashboards.
In practice, the validator endpoints are called by the Oracle off-chain services based on both the execution and consensus on-chain information. This service is available as a binary or docker image or can be built from the source. Instructions on how to run it inside a Kubernetes cluster are provided, indicating attention to scalability.
The Operator service periodically checks the state of its vault on-chain to check if there is enough ETH deposited to create new validators. If yes, then the Operator proceeds as follows:
Send a registration request to the
Oracles.Oraclevalidates the request and returns the signed payload if it is valid.The
Operatorsubmits the signed payload to the vault on-chain, which moves ETH to the beacon chain contract. One or more validators are then provisioned.
The Operator service can generate a validator mnemonic phrase and derive validator keys from it. Those can also be generated separately, but the withdrawal address must be set to the vault contract address to be deemed valid by the Oracles. In any case, many validator deposit keys must be pre-generated and uploaded to the vault. This can be done through the StakeWise web UI or the Operator CLI by calculating Merkle tree root deposit data and sending the result to the vault's contract using its setValidatorsRoot method. If multiple node operators are behind a single vault, their deposit data must be merged into a single file before being set into the vault's contract.
In case one would not want the Operator service from accessing the validator keys directly, it is possible to use a remote signer service to get signatures for validator exit messages.
4.2.3 Oracle Pricefeed Availability
A RedStone osETH/USD price oracle is available, with a frequency of 1 minute. This price results from an active collaboration between StakeWise and RedStone, which was publicly communicated as a case study. It uses the median of 3 on-chain sources whose liquidity is funded by the StakeWise DAO through SWISE token emissions:
This pricefeed is used by the following protocols:
AAVE uses a combination of Chainlink ETH/USD feed and osETH/ETH rate which assumes osETH parity with ETH. It is interesting to note that osETH has just completed its onboarding process on AAVE as collateral. Feedback from the ChaosLabs risk team was positive.
Section 5: Counterparty Risk
This section addresses the persistence of osETH's properties from an ownership rights perspective (i.e., possession, use, transfer, exclusion, profiteering, control, legal claim). The reader should get a clear idea of (1) who can legitimately change properties of the collateral (e.g., minting additional units) and what their reputation is, (2) the extent to which changes can be implemented, and the effect on the collateral.
This section is divided into four subsections:
5.1: Governance
5.2: Decentralization of the LSD
5.3: Economic Performance
5.4: Legal
5.1 Governance
5.1.1 Governance Scope
StakeWise V3 is governed by the StakeWise DAO through the SWISE token. Possessing the SWISE token grants linear voting power on governance proposals, which are first discussed on the StakeWise governance forum. Depending on feedback from the community, proposals are refined and then formally proposed on snapshot.org. While Snapshot represents an offchain governance system that requires trust in some admin to execute the outcome of votes, StakeWise mitigates this centralization vector through the implementation of a SafeSnap module. This essentially automates the outcome of Snapshot votes through an oracle-based solution, giving tokenholders direct governance power over the on-chain execution of contract upgrades and change in parameters. The SafeSnap module works as follows:
Creation of a SnapShot proposal, where each outcome contains an array of multisend transactions (can be empty as well).
Once the proposal vote closes, an escalation game starts to obtain the real outcome onchain. An initial outcome must be selected and a minimum bond must be provided using governance tokens. The questionTimeout period starts.
If one wishes to change the outcome, a bond that is twice the size of the previous one must be provided.
Once an outcome finalizes, the questionCooldown period starts. This allows the protocol multisig to censor the proposal if deemed invalid or malicious.
At the end of the questionCooldown period, the one who posted the last bond gets the whole bond balance. Anyone can execute the multisend transaction associated with the finalized outcome. An expiration timer starts, at the end of which the proposal expires.
Game theory guarantees that the true outcome of the proposal will end up onchain as there is an incentive to set the right outcome — indeed, invalidating an outcome amounts to receiving the previous bonds as reward. However, the following conditions must be satisfied for the system to work as intended:
Proposals must be monitored through offchain services by multiple parties, so that one can always set the right outcome of a proposal.
A long enough proposalTimeout must be set, so that participants have enough time to post a bond (more than 48 hours recommended).
A high enough minimumBond must be set to prevent malicious proposals.
Analysis of the StakeWise SafeSnap module reveals a minimum bond of 200K SWISE tokens (equivalent to ~6000 $USD as of the end of Mai 2024), a questionTimeout of 24 hours, a questionCooldown of 24 hours, and a answerExpiration of 7 days. We believe that both the questionTimeout and the questionCooldown durations could be increased to give more times for participants to intervene and ensure the right outcome gets onchain.
5.1.2 Access Control
Contracts controlled by the StakeWise team:
VaultRegistry: Ownable2Step by 4/7 protocol multisig wallet.
Keeper: Ownable2Step by 4/7 protocol multisig wallet.
OsToken: Ownable2Step by 4/7 protocol multisig wallet.
OsTokenConfig: Ownable2Step by 4/7 protocol multisig wallet.
OsTokenVaultController: Ownable2Step 4/7 protocol multisig wallet.
CumulativeMerkleDrop: Ownable2Step by 2/2 protocol multisig.
Contracts controlled by vault admins:
Vault: deployed behind a ERC1967Proxy. The GenesisVault is owned by a 1/2 protocol multisig. Other vaults are owned by third-party admins.
SharedMEVEscrow: each vault can have its own SharedMEVEscrow. Only the associated vault can withdraw from it.
RewardSplitter: Each vault has its own RewardSplitter which receives the vault fee. It is owned by the vault admin. The one of the GenesisVault contract is owned by a 1/2 protocol multisig.
Most core contracts use Ownable2Step, which defines a contract owner that can be reassigned as part of a two-step process. The owner of an Ownable2Step contract must initiate the ownership transfer by calling transferOwnership(address newOwner). Then, the new owner must accept the transfer by calling acceptOwnership(). This process prevents the contract's ownership from being transferred to the wrong owner. The RewardSplitter contract is the only one using the OwnableUpgradeable library which, contrary to Ownable2Step, does not require approval from the new owner. The owner must call transferOwnership(address newOwner) to transfer the ownership.
Notably, StakeWise contracts do not use role-based access control. The owner of core contracts is the StakeWise 4/7 protocol multisig wallet. No pausing mechanism or ways to change contract implementations by the StakeWise DAO are present. The minting of osETH tokens can be paused, either by calling the setCapacity method of the OsTokenVaultController contract to set the capacity variable to a value lower than the current minted supply of osETH, or by removing faulty vaults from the VaultRegistry contract.
5.1.3 Distribution of Governance Tokens
The SWISE token allocation started in April 1st 2021, represents a total of 1,000,000,000 SWISE tokens, and can be summarized as follow:
25% for investors, six months cliff, and 24 months of vesting
25% for founders, six months cliff, and 48 months of vesting
50% for the community, no cliff, and 48 months of vesting
Source: StakeWise documentation, 19/04/24
Investors are somewhat prioritized in this vesting schedule, having almost 50% of the circulating supply at the end of their vesting period. Their relative share then slowly diminishes in favor of the community. At least temporarily, significant profit-taking from investors at the end of their vesting period could severely impact market prices. As of April 20, 2024 — 3 years into the token allocation process — the peak investor share of the circulating supply would have happened approximately one year ago. The SWISE token currently trades at its lowest point since its inception in April 2021.
5.1.4 Proposals Frequency
Since the deployment of StakeWiseV3 on November 29, 2023, we counted an average of 4 monthly proposals. Because of how the governance process works, with ample discussions and feedback gathered in the forum, snapshot.org proposals are generally expected to be accepted when created. Protocol changes are deployed on-chain in a permissionless way following a positive vote from SWISE token holders, making snapshot.org proposals an integral part of the deployment process.
Source: snapshot.org (27-04-24)
5.1.5 Participation
The StakeWise forum counts 235 topics, spread into different categories including proposals, ideas, ecosystem, node operators and general discussion. Four hundred fifty-one users are active on the forum.
Source: StakeWise forum (27-04-24)
Three tags are used to identify the stage of a post on the forum. Phase 1 defines an idea that still needs to be formally defined and has yet to see significant community support. Phase 2 corresponds to the creation of a StakeWise Improvement Proposal (SWIP) along with a forum poll that lasts five days. If the poll reveals relatively higher support in favor of the change, then the post moves to Phase 3 in seven days: the SWIP is refined and goes through a vote on snapshot.org. In practice, forum tags are not correctly assigned and updated to reflect the true stage of proposals and can't be relied upon.
Source: StakeWise forum stats (27-04-24)
The forum seems to be relatively quiet during the last 30 days compared to the all-time high, although this must be taken into perspective with the forum age — 3 years as of May 2024. Forum participation is highly skewed toward a few users responsible for most of the activity, but this is not uncommon in a DAO setting.
Source: StakeWise forum users (27-04-24)
5.2 Decentralization of the LSD
5.2.1 Number of Node Operators
The StakeWise Genesis vault, which is the default vault operated by the StakeWise team that is used by users who don't wish to select a specific vault, is powered by four permissioned node operators:
5.2.2 Validators per Node Operator
When asked for information regarding its node operators and validator count, the StakeWise team redirected us to the rated.network website. However, the data provided by this platform might not accurately represent the current state of things and should be taken with a grain of salt.
Source: rated.network (05-04-24)
Almost half of the validators are operated by StakeWise, the rest being split relatively evenly between CryptoManufaktur, Finoa and DeutscheTelekom. The Lighthouse consensus client has a majority share in all node operators except for DeutscheTelekom which mostly uses Teku. Prysm, the only consensus client above the 33% majority threshold, is almost non-existent, which is positive.
We cannot attest to the diversity of the execution node clients since such information is private. This area is of concern since Geth usage is still too high, with an estimated 63% of the total execution client share, which is above the 33% majority risk of the Ethereum consensus. Using Geth by StakeWise node operators could result in a significant loss of capital in case of a bug in this client.
5.2.3 validator Enter/Exit (Churn)
Monthly Churn Rate = (exits/number of validators before a month) * 100
Monthly Churn Rate = (86 / 2319) * 100 = ~3.7%
Source: Rated Network (05-05-24)
5.3 Economic Performance
5.3.1 Revenue
According to TokenTerminal's data, StakeWise generated $37.56k in revenue in April 2024. The expenses totaled $9.08k, and the financial report only refers to the token incentives as an expense.
Source: TokenTerminal
5.3.2 Net Profit
According to TokenTerminal, StakeWiseV3 made a profit of $28.48k in April 2024.
Source: TokenTerminal (27-04-24)
5.4 Legal
5.4.1 Legal Structure
Creative Tech Free Zone Co. is the user-facing entity nominated by StakeWise Terms of Service. The company was established in a free zone in the UAE. This specific incorporation type permits a somewhat opaque ownership structure, a characteristic attributed to the legalities of free zone setups. The UAE is home to over 40 multidisciplinary free zones, designed to attract foreign investment by allowing investors full ownership of their enterprises. Among the remarkable benefits of establishing a business in a free zone are fiscal incentives such as complete exemption from corporate and income taxes, freedom to repatriate 100% of capital and profits, and independent laws and regulations for each zone.
On the downside, no one-stop-shop solution for checking the company status in all dispersed registries in the UAE seriously hampers verifying the corporate structure and ownership of Creative Tech Free Zone Co.
5.4.2 Licenses
In Dubai, the Virtual Asset Regulatory Authority (VARA) is the primary regulatory body overseeing Virtual Asset services. It is compulsory for Virtual Asset Service Providers (VASPs) aiming to engage in crypto-related operations within the Emirate to secure a license from VARA.
Licensed VASPs authorized to provide Custody Services have benefited significantly from the VARA Custody Services Rulebook updates. These updates allow them to offer staking services directly to their customers under the same legal entity without needing a separate license for Virtual Asset Management and Investment Services.
""Staking from Custody Services" is defined as 'staking' or otherwise using, committing, pledging, or locking up Virtual Assets for which the VASP is providing Custody Services to participate in the consensus mechanisms or other maintenance, operation or functioning of a DLT to which those Virtual Assets relate, and may include receiving rewards generated and distributed for that participation."
VARA binds the definition of staking only to the scope of activities allowed for VASPs. No reference for non-custodial staking is made in the rulebook. Non-custodial staking technically is not entangled with a particular organization (regardless of its licensing status) to secure the blockchain network. The regulator does not touch upon the cases where users pledge their crypto assets to a smart contract to reach the same output, i.e., participating in the consensus mechanism.
We need to determine whether all the staking models differing from those conducted by custodians are intentionally excluded from the legislative scope. Currently, VARA only provides instructions for this staking. The authority also needs to clarify if operators of portals giving access to non-custodial services shall be subject to VASP license requirements.
Creative Tech Free Zone Co is not entered in the Public record of Licensed Virtual Asset Service Providers. A counter-argument for the omitted listing is the entity's obligation to comply with VASP regulations. At the same time, it does not carry out any of the activities prescribed therein.
5.4.3 Enforcement Actions
No records of any specific enforcement actions, lawsuits, or regulatory measures directly mentioning StakeWise or Creative Tech Free Zone Co. These entities have not been involved recently in any public legal or regulatory issues documented in the available sources.
5.4.4 Sanctions
Eligibility for website or application access depends (among other requirements) on the user's association with sanctions designations.
Specifically, access is restricted for any individual or entity, as well as entities owned or controlled by such persons, who conduct activities directly or on behalf of sanctioned individuals or entities. This prohibition extends to those in sanctioned regions, including Belarus, Burundi, Crimea and Sevastopol, Cuba, the Democratic Republic of Congo, Iran, Iraq, Libya, North Korea, Somalia, Sudan, Syria, Venezuela, or Zimbabwe. Additionally, access is denied to those who are subject to sanctions administered or enforced by the U.S. Department of the Treasury's Office of Foreign Assets Control, the U.S. Department of State, or any other governmental authority identified on the Denied Persons, Entity, or Unverified Lists by the U.S. Department of Commerce's Bureau of Industry and Security; or are located, organized, or resident in any country or territory currently under economic sanctions.
5.4.5 Liability Risk
Terms of Service (ToS) represent a legally binding agreement between the user and Creative Tech Free Zone Co., governing access to stakewise.io website, the application app.stakewise.io, and other related platforms. The services provided include web-based interfaces that enable users to engage directly with decentralized protocols to stake ETH on the Ethereum blockchain. ToS provisions highlight that Stakewise does not operate as a broker, dealer, exchange, investment adviser, custodian, or financial service provider of any kind; rather, the services are purely technical, facilitating user access to software for direct crypto asset staking on the Ethereum blockchain without any intermediation by Stakewise.
Users can independently configure, administer, and initiate a Vault using the "Vault Toolkit" via the Protocol. Each user who sets up a Vault is solely responsible for its management, including the associated validator node(s).
Through the Protocol, users may acquire an ERC-20 cryptographic receipt token known as "osETH," which is freely transferable. This token proves that the holder is entitled to receive, control, hold, and dispose of staked ETH and any rewards from the Ethereum network accruing to such staked ETH. The governance of osETH is subject to separate terms and conditions as detailed in the osETH User Agreement, which is constructed by the laws of the United Arab Emirates.
Creative Tech Free Zone Co. disclaims liability for any loss of osETH and shall not be held liable for any consequential, indirect, incidental, or special damages as stipulated in the User Agreement. The risk disclaimer sections clearly state that osETH is issued by the Protocol on an "as-is" and "as-available" basis, and the company does not make any warranties in this regard.
Disputes, claims, and controversies arising from the User Agreement shall be subject to binding arbitration in the UK under the auspices of the London Court of International Arbitration. The arbitrator will enforce the substantive laws of the United Arab Emirates, specifically excluding any conflict of law or choice of law provisions. Furthermore, the User Agreement includes a waiver of class action and jury trial rights.
5.4.6 Adverse Media Check
Several discussions on the governance forums indicate instances of scams by StakeWise impersonation.
Fake DAO Proposal: User reported being tricked by a proposal on what seemed to be the StakeWise DAO's official site. The proposal turned out to be a scam, leading the user to malicious sites where they were deceived into signing transactions that resulted in the theft of funds.
Phishing Attempts: There were complaints about the presence of scammers in the forums who responded to users' queries with deceptive intentions, aiming to manipulate them into unsafe actions.
Airdrop Scam: A specific incident involved a user who believed they were claiming a token drop, which led to their funds being stolen.
Section 6: Risk Management
This section will summarize the findings of the report by highlighting the most significant risk factors in each of the three risk categories: Market Risk, Technology Risk, and Counterparty Risk.
6.1.1 Market Risk
LIQUIDITY: Does the LSD have a liquid market that can facilitate liquidations in all foreseeable market events?
57% of all osETH tokens are deposited into EigenLayer, a portion so significant that any event specific to EigenLayer could directly impact osETH's liquidity. Although the osETH peg relative to ETH has been relatively stable so far, so much liquidity stuck in EigenLayer could adversely impact the peg on secondary markets, and this despite active liquidity incentives effort from the StakeWise team.
It is clear StakeWise attempts to distribute liquidity across several venues where it is paired with different assets. This, along with its relatively stable liquidity profile in recent months, does create additional confidence in its resiliency in various market scenarios, including platform specific issues.
VOLATILITY: Has the LSD had any significant depeg event?
Minor volatility has been witnessed at the beginning of V3. Lately, there has been a minor but constant positive depeg, indicating a relatively high demand for osETH on secondary markets which is outside StakeWise's control. An effort was made to prioritize users while maintaining the osETH peg on secondary markets by having the modal automatically switch between protocol withdrawals and secondary market swaps.
The 10% buffer of overcollateralized ETH protects osETH holders from underperforming or slashed validators operated on their behalf. It is bigger than what is commonly observed in other liquid staking protocols, and can tolerate small to moderate slashing penalties. The soft peg of osETH to ETH has been successfully maintained through redemptions, while no liquidation has been witnessed so far. We note that this system hasn't been live for long, and its efficacy remains to be proven on the longer term under more adverse conditions.
6.1.2 Technology Risk
SMART CONTRACTS: Does the analysis of the audits and development activity suggest any cause for concern?
Three audits were conducted on the V3 codebase, and many more on previous versions of the protocol — we believe this previous experience provided engineers with valuable insights for creating V3. Audits revealed few issues that were fixed by the team, most of them related to migrating V2 to V3.
The codebase is public, well documented and modular, and repository activity is indicative of professional development practices. A bug bounty is available on Immunefi, although the maximum payout is relatively small compared to industry standards. The protocol has not suffered from any breach of security so far, nor was anyone able to claim an Immunefi bounty.
DEPENDENCIES: Does the analysis of dependencies (e.g., oracles) suggest any cause for concern?
The StakeWise V3 protocol depends on two offchain services — the Operator and the Oracle. Although both are important, the Oracle is not open source, which represents a gray area of the protocol. That being said, it is operated by a decentralized network of known entities over which the StakeWise has no direct control, which helps to alleviate centralization concerns. Moreover, manipulation of reported validator balances and rewards or validator exit credentials is prevented by smart contract checks.
The RedStone pricefeed, which is based on the median of three well funded liquidity pools that are incentivized by StakeWise and used by protocols such as Morpho and Gravita, is the available oracle option. However, RedStone is relatively centralized and secures substantially lower values than the incumbent oracle provider Chainlink, and thus we consider it more suitable for isolated lending markets than collateralized stablecoin protocols.
6.1.3 Counterparty Risk
CENTRALIZATION: Are there any significant centralization vectors that could rug users?
The StakeWise V3 protocol is fairly decentralized and permissionless, with limited control from the StakeWise team over deployed contracts, and no control over vault contracts. Those are controlled by vault admins, and there is no obvious ways one could get hold of the users' funds inside of them.
A 4/7 multisig is the owner of all but the vault contracts. Signers are known public entities that StakeWise has no direct control over. The network of offchain Oracles are also operated by a set of publicly known entities separated from StakeWise. We regret however that the code for the Oracle remains private, as its role in the protocol is central. The execution client diversity remains unknown, especially the share of validators depending on Geth, which is a cause for concern as currently a bug in Geth could put users' funds at risk.
LEGAL: Does the legal analysis of the Protocol suggest any cause for concern?
StakeWise is incorporated in a free zone of the UAE, which provides a lot of flexibility from a business administration standpoint, yet the ownership structure often remains opaque. VARA, the regulatory authority in the UAE, has not yet extended its oversight to include non-custodial staking which suggests a degree of regulatory latitude for Stakewise, provided that the protocol refrains from engaging in illicit activities. The terms governing user interactions are meticulously detailed, distinguishing clearly between interactions with the protocol itself and the usage of the osETH token. Emphasis is placed on limiting liability and disclaiming any warranties concerning osETH and the use of the protocol.
6.1.4 Risk Rating
Based on the risks identified for each category, the following chart summarizes a risk rating for osETH as collateral. The rating for each category is ranked from excellent, good, ok, and poor.
We rank osETH as ok on liquidity because, despite it being mostly deposited into EigenLayer, it still displays acceptable liquidity venues thanks to its liquidity incentive program.
We rank osETH as good on volatility because the mechanisms in place successfully managed to preserve its soft peg to ETH so far, although the reduced liquidity could adversely impact it eventually.
We rank osETH as excellent on smart contract because it has undergone three audits with few small findings, and analysis of the open source code displays professional development practices.
We rank osETH as ok on dependencies because there is a RedStone price feed available, although we are not prepared to endorse its usage in the Prisma protocol.
We rank osETH as good on decentralization because there are no significant centralization vectors, although a more advanced access control system could further strengthen the protocol and allow the team to better intervene in case of a security breach.
We rank osETH as good on legal because its legal structure is created with a compliance-oriented mindset. Responsibilities are clearly outlined in their user agreements, such that users can interact with the protocol in full awareness of the risks involved.
Source: DefiLlama (27-04-24)
2.1.2 Transaction Volume
The osETH transaction volume over the observed 90-day period demonstrates significant volatility, with daily volumes ranging from a minimum of $98,539 to a maximum of $11,908,025. This high volatility is likely influenced by the activities of large-scale investors or "whales," whose substantial transactions can cause notable spikes in the trading volume. Additionally, considering osETH's characteristics as an ETH liquid staking token and a yield-bearing asset, periods of low transaction volume are expected, as investors may hold onto their assets to accrue potential yields rather than engage in frequent trading. This behavior aligns with the typical market dynamics of similar asset types in the DeFi space.
Source: IntoTheBlock - from 01-Feb to 01-May-2024
Source: IntoTheBlock - from 01-Feb to 01-May-2024
2.1.3 DEX Volume
Source: Bitquery (01-05-24)
2.1.4 Average Transaction Size
Source: IntoTheBlock - from 01-Feb to 01-May-2024
2.1.5 Trading Volume to Market Capitalization Ratio
The "Trading Volume to Market Cap Ratio" for osETH over the observed period generally shows low levels of trading activity relative to its market capitalization, averaging 0.453%. The ratio ranges from a minimum of 0.058% to a maximum of 2.167%. This low ratio typically indicates that the daily trading volume represents only a small fraction of the total market capitalization of osETH (LST Market Cap = LST protocol ETH TVL). The implication of such a low trading volume relative to market capitalization is a potentially lower liquidity risk.
Source: Defi Llama and CoinGecko (01-05-24)
2.1.6 Active Addresses/Users
Active addresses show daily unique addresses that initiate an osETH transaction.
Source: Dune (25-04-24)
2.1.7 User Growth
We measure user growth by observing unique addresses that are holders of osETH daily.
Source: Dune (25-04-24)
2.2 Competitive Analysis Metrics
2.2.1 Market Share
Source: DefiLlama (27-04-24)
StakeWise represents 0.75% of the total liquid staking market, which puts it in 8th position.
Source: DefiLlama (27-04-24)
In terms of dominance, it peaked at 8.6% of the total liquid staking market in April 2021. Competition was significantly less important at the time, and the merge had yet to happen.
2.2.2 Inflows Share
Source: Defi Llama (25-04-24)
2.2.3 Protocol Staking Yield
For the last 90 days, the average staking APY rate has been 3.61%, between 3.18% (min) and 4.72% (max).
StakeWise - daily staking APY over the last 90 days:
Source: Defi Llama - from 01-Feb to 01-May-2024
2.2.4 Slashing Rate
To our knowledge, no validator operated on behalf of StakeWise has been slashed.
2.3 Subsidization of Economic Activity
2.3.1 Existence of an Incentive Program
Main liquidity incentives
StakeWise DAO increases the liquidity of its tokens through the emission of SWISE tokens. Liquidity for StakeWise V3 was first discussed in this forum post. The main liquidity pools are:
Here is a summary of the osETH liquidity funding allocated month-over-month and the 30-day average dollar value before the snapshot proposal:
Source: StakeWise forum (25-04-24)
Allocated SWISE tokens are transferred from the DAO vesting contract to the SLC multisig (StakeWise Liquidity Committee), a 2/2 multisig. The SLC budget is revisited month-over-month. Operators of the SLC multisig are compensated with a monthly sum approximating 5000 $USD per month in SWISE tokens.
Independently, SWISE liquidity is also helped by the DAO in the UniswapV3 SWISE/ETH pool. The community discussed and approved this in this forum post. Here is a breakdown of the last months in terms of liquidity incentives:
Source: StakeWise forum (25-04-24)
We can see that the liquidity cost to the DAO drastically increased in March 2024. This is due to the significant price drop of the SWISE token and a drop in capital efficiency from the Curve and Balancer pools.
Arbitrum liquidity incentives
The StakeWise DAO applied to and was granted 300K ARB tokens from the Arbitrum Foundation, approximating a total dollar value of 300K $USD as of April 24, 2024, to bootstrapping the osETH liquidity on Arbitrum. A condition of this grant is for the StakeWise DAO to match the dollar value of this grant on a 1-1 basis for the nine months starting in August 2024. A snapshot proposal was created and accepted by the community. As of the proposal start date, this was an estimated 11,500,000 extra SWISE tokens for a dollar value of 345,000 $USD.
MorphoBlue liquidity incentives
This incentive is aimed at bootstrapping the liquidity for osETH on MorphoBlue, a decentralized lending protocol that improves the lending and borrowing rates, and where anyone can create a vault whose risk is segregated from others. Approved by the community, it targets a total incentive of 900K SWISE tokens over three months.
Section 3: Market Risk
This section addresses the ease of liquidation based on historical market conditions. It seeks to clarify (1) the Liquid Staking Basis & Volatility of osETH, and (2) the liquidity profile of the collateral. Market risk refers to the potential for financial losses resulting from adverse changes in market conditions.
This section is divided into 2 sub-sections:
3.1: Volatility Analysis
3.2: Liquidity Analysis
3.1 Volatility Analysis
3.1.1 Liquid Staking Basis (LSB)
osETH Liquid Staking Basis over the last 90 days:
Source: Etherscan and CoinGecko - from 01-Feb to 01-May-2024
The absolute osETH LSB:
Source: Etherscan and CoinGecko - from 01-Feb to 01-May-2024
Source: OsTokenVaultController contract and CoinGecko - from 01-Feb to 01-May-2024
We can observe larger deviations when osETH was first launched, which can be explained by the lower liquidity. As liquidity gradually increased over time, it helped to stabilize the secondary market rate concerning the internal exchange rate of the Protocol. Lately, we observed a small but consistent positive deviation of the secondary market rate. This can be explained by the entry queue of the Ethereum consensus, which recently reached a length of 10 days.
According to the documentation, the StakeWise withdrawal modal should automatically switch to secondary markets if the exchange rate is higher there, which benefits stakers and helps reduce the deviation of the market rate from the internal exchange rate.
3.1.2 LSD Volatility
The volatility of osETH is marginally higher than its underlying asset, ETH. The data shows that osETH's daily average volatility is 3.42%, compared to ETH's 3.37%. When extrapolated annually, osETH's volatility rises to 65.29%, compared to ETH's 64.38%.
Source: CoinGecko - from 21-Jan to 29-Apr-2024
3.1.3 Yield Volatility
Yield volatility is calculated from DeFillama data Median APY. The data is compared against the STYETH ETH staking yield index data.
Source: Defi Llama and Compass ETH Staking APY index (28-04-2024)
3.2 Liquidity Analysis
3.2.1 Supported DEXs and CEXs
osETH is only supported on the following decentralized exchanges:
Source: Nansen (28-04-2024)
3.2.2 LSD Token Total On-chain Liquidity
Source: DexGuru, Balancer and Etherscan - from 22-Mar to 01-May 2024
Liquidity can be seen to consistently be most concentrated on Balancer where it is paired with WETH.
Source: IntoTheBlock - from 31-Oct to 06-Jun 2024
3.2.3 Token Distribution
Here are the top addresses by ownership of osETH tokens.
Source: Nansen (05-May-2024)
The largest concentration of osETH tokens is in the EigenLayer osETH Strategy, holding 56.45% of the total tokens. This significant allocation suggests a strategic emphasis on restaking, which might be aimed at maximizing yield through compound staking strategies. Such a high concentration can influence the liquidity of the token and its market behavior, as a large volume is locked up and potentially less available for regular trading.
The distribution of osETH across various DEXs showcases a strategic placement of liquidity that enhances price stability on these platforms. osETH is supported on only two lending protocols: Morpho Blue, a money market with permissionless market creation, and Gravita, an ETH LST-backed CDP protocol.
3.2.4 Liquidity Utilization Rate
Source: DexGuru and Bitquery (01-May-2024)
3.2.5 LSD Leverage Ratio
osETH is supported as collateral only on two lending protocols: Morpho Blue (permissionless market creation) and Gravita (lending protocol). Morpho Blue osETH/WETH is at the moment at 49.9% Utilization rate:
Source: BlockAnalitica (28-04-2024)
For the osETH market, the Gravita protocol system utilization rate is 41.79%:
Source: Gravita protocol (28-04-2024)
3.2.6 Slippage
An analysis using DeFi Llama's "Liquidity tool" shows that a trade of 8,602.46 osETH to 8,641.50 ETH, valued at approximately $26,171,875, results in a slippage of 1.14%, indicating a moderate liquidity depth for osETH. CowSwap facilitates efficient trade execution, which reduces the price impact on large transactions.
Source: Defi Llama - Token Liquidity (28-04-2024)
Section 4: Technological Risk
This section addresses the persistence of collateral properties from a technological perspective. It aims to convey (1) where technological risk arises that can change the fundamental properties of the collateral (e.g., unresolved audit issues) and (2) do any composability/dependency requirements present potential issues (e.g., is a reliable price feed oracle available?).
This section is divided into three sub-sections:
4.1: Smart Contract Risk
4.2: Product and Layer Composability
4.3: Oracle Pricefeed Availability
4.1 Smart Contract Risk
4.1.1 Protocol Audits
The StakeWise V3 protocol has received a total of 3 audits:
Halborn (2023-05): 5 findings including one high risk.
Halborn (2023-08): 3 findings including one medium.
SigmaPrime (2023-08): 21 findings including two critical risks, five high risks, and one medium risk.
4.1.2 Concerning Audit Signs
The latest SigmaPrime audit found two significant issues related to migrating from V2 to V3. Both were acknowledged and fixed by StakeWise.
Deposits From V2 Pool Escrow Misinterpreted As User Deposit
V3 vaults usually receive ETH on two occasions: when they receive staker deposits, which triggers the receive() function, or when funds are withdrawn from the beacon chain upon validator exits. Beacon chain withdrawals are gasless transactions and do not trigger any logic in the contract.
Since the withdrawal address of validators cannot be changed once set, it is set to an intermediary contract called the PoolEscrow contract, which then sends its funds to the V3GenesisVault. Although this transaction represents a beacon chain withdrawal, it is interpreted as a regular staker deposit, which triggers the receive logic because it is a normal transaction. This causes the staking shares to be allocated to the PoolEscrow contract, which can never be redeemed. Consequently, funds received from the PoolEscrow do not increase the balance of funds allocated to existing depositor shares (whether from V2 or V3) but are allocated to spin-off validators once again.
Rewards From Stakewise V2 not Shared With V2 Stakers
This second important issue is related to the previous one. Although the team had previously communicated its intent to consider rewards from V2 stakers and V3 stakers as belonging to the same pool and therefore planning to split them evenly, it was not the case in practice. All rewards from the V2 system were found to be sent to the V3GenesisVault, which allocated 100% of them to V3 stakers. Consequently, V2 stakers would have lost rewards upon migrating to the V3 protocol.
4.1.3 Bug Bounty
A bug bounty is available on Immunefi. It started on May 31, 2022, and was last updated on April 8, 2024. A maximum bounty of 200,000$ can be claimed for critical risk vulnerabilities or 50,000$ for high-risk vulnerabilities without the need for KYC. No one was able to claim a bounty so far.
We note that the proposed bounty deviates from the industry's norm by limiting itself to 200,000$ instead of the more commonly used 10% of funds at risk. Furthermore, the payout can be made in USDC or SWISE tokens at the discretion of the StakeWise team. The limited liquidity of the SWISE token can be underwhelming when considering the maximum payout of 200,000$, with an estimated -12% loss in that case when exchanging SWISE tokens for ETH using the main pool available (UniswapV3 SWISE/ETH).
4.1.4 Immutability
Apart from the vault contracts, all contracts are immutable. Upgrades are made by deploying a new contract and then updating the contract address that each other contract references.
The StakeWise team can develop new vault contracts so that vault owners can decide to upgrade to the latest version. This is done through the VaultVersion abstract contract, which implements the UUPSUpgradeable interface. Notably, some of the vault's parameters remain immutable, like the vault's fee or the type of vault (private, public, MEV smoothing, etc). This is to protect vault stakers from any unilateral decision of the vault's admin. Some parameters, such as the allowed depositors for private vaults, can be changed after deployment.
We note that the lack of a pausing mechanism — while strengthening the permisonlessness of the Protocol — severely limits any intervention the team could make to protect it in case of active exploit. The StakeWise team can only pause osETH minting or provide vault contract updates (which vault operators would then have to accept manually).
4.1.5 Developer Activity
The number of commits through time is relatively low compared to the size and code complexity of the github.com/stakewise/v3-core repository. This is explained by using PR (pull requests) from feature branches against the repository's main branch. This workflow facilitates code reviews and visibility from other developers. Each PR seems to be related to a specific feature and can be made of many commits that were "squashed" into a single one before being merged into the main branch. In that sense, the commit history on the main branch is not representative of the level of developer activity but rather of the frequency of feature changes on the main branch.
Source: Github (23-04-2024)
We note that commits were made with cryptographic signatures on October 11, 2024, before V3 was deployed to the mainnet. This makes it more difficult for an attacker to commit malicious code to the repository, which could later be deployed on-chain. There are currently 3 PRs opened in the v3-core repository.
4.1.6 SC Maturity
A manual review of the smart contract code for V3, which is publicly available on GitHub, indicates professional development practices. Because of the flexibility of the StakeWise V3 protocol, the smart contract codebase is relatively large and complex. However, it is also highly modular and documented, which helps to navigate and understand it.
StakeWise has publicly open-sourced various git repositories, including the Operator off-chain service, developer tools like an SDK, and a Subgraph. However, the source code for the Oracle off-chain service is only available for StakeWiseV2 and not StakeWiseV3. Although this service is decentralized by being operated by 11 different entities, it is a strata-critical component that could fail or be exploited. Publicly shared audits and scrutiny could help alleviate the centralization risk it represents, as security through obscurity is generally not a recommended practise.
GitHub repositories:
4.1.7 Previous Incidents
To our knowledge, StakeWise has not been impacted by any incidents since its inception.
4.2 Product and Layer Composability
4.2.1 Dependencies
StakeWise V3 depends on two different off-chain services: the Operator and the Oracle off-chain services. The Operator off-chain service is open source, but not the Oracle. When asked about it, the StakeWise team indicated that "no plans are made to make it public in the intermediate future". They also mentionned a lack of public audit for it, but that several companies have done their due diligence and privately audited the complete StakeWise stack — including the Oracle offchain service.
Oracle offchain services
Like all liquid staking protocols deployed before EIP-4788, StakeWiseV3 relies on an off-chain service. The Oracle in StakeWiseV3 is used to automate tasks that smart contracts cannot do or provide information from outside the EVM. Despite its name, the responsibilities of an Oracle go beyond that of the reporting of consensus layer information — that is the balance of each validator and their rewards — and also include:
Registration and validation of validator keys — the withdrawal address must correspond to their vault's contract address.
Exiting validators when needed — that is, when osETH withdrawal requests for ETH are made or to facilitate both the redemption and liquidation mechanisms.
Source: StakeWise documentation (24-05-2024)
Eleven different permissioned entities operate the Oracle off-chain service with a voting threshold of seven acting as consensus. Oracle operators are known entities that the StakeWise DAO has vetted through a snapshot.org vote, and are comprised of:
Bitfly (operator of beaconcha.in)
The StakeWise development team
The Oracle network is a critical component of the StakeWiseV3 infrastructure because it reports the balances and rewards accrued by each vault. If manipulated, it could trigger either the redemption or the liquidation mechanisms on certain vaults, resulting in a loss of funds for osETH stakers. That being said, the Keeper contract, which receives information from the Oracle off-chain services, has an internal check preventing the reward rate from deviating too much from expected values.
Operator off-chain services
The Operator service acts as an intermediary between the vaults (on-chain) and the validators securing the staked ETH of that vault. Each node operator runs this off-chain service and connects it to its execution and consensus node clients. The Operator exposes two HTTP API endpoints:
GET /validatorsto retrieve available validators to be registered.POST /validatorswill be used to submit exit signatures for validators identified using the previous endpoint.GET /metricsfor Prometheus to gather information for Graphana dashboards.
In practice, the validator endpoints are called by the Oracle off-chain services based on both the execution and consensus on-chain information. This service is available as a binary or docker image or can be built from the source. Instructions on how to run it inside a Kubernetes cluster are provided, indicating attention to scalability.
The Operator service periodically checks the state of its vault on-chain to check if there is enough ETH deposited to create new validators. If yes, then the Operator proceeds as follows:
Send a registration request to the
Oracles.Oraclevalidates the request and returns the signed payload if it is valid.The
Operatorsubmits the signed payload to the vault on-chain, which moves ETH to the beacon chain contract. One or more validators are then provisioned.
The Operator service can generate a validator mnemonic phrase and derive validator keys from it. Those can also be generated separately, but the withdrawal address must be set to the vault contract address to be deemed valid by the Oracles. In any case, many validator deposit keys must be pre-generated and uploaded to the vault. This can be done through the StakeWise web UI or the Operator CLI by calculating Merkle tree root deposit data and sending the result to the vault's contract using its setValidatorsRoot method. If multiple node operators are behind a single vault, their deposit data must be merged into a single file before being set into the vault's contract.
In case one would not want the Operator service from accessing the validator keys directly, it is possible to use a remote signer service to get signatures for validator exit messages.
4.2.3 Oracle Pricefeed Availability
A RedStone osETH/USD price oracle is available, with a frequency of 1 minute. This price results from an active collaboration between StakeWise and RedStone, which was publicly communicated as a case study. It uses the median of 3 on-chain sources whose liquidity is funded by the StakeWise DAO through SWISE token emissions:
This pricefeed is used by the following protocols:
AAVE uses a combination of Chainlink ETH/USD feed and osETH/ETH rate which assumes osETH parity with ETH. It is interesting to note that osETH has just completed its onboarding process on AAVE as collateral. Feedback from the ChaosLabs risk team was positive.
Section 5: Counterparty Risk
This section addresses the persistence of osETH's properties from an ownership rights perspective (i.e., possession, use, transfer, exclusion, profiteering, control, legal claim). The reader should get a clear idea of (1) who can legitimately change properties of the collateral (e.g., minting additional units) and what their reputation is, (2) the extent to which changes can be implemented, and the effect on the collateral.
This section is divided into four subsections:
5.1: Governance
5.2: Decentralization of the LSD
5.3: Economic Performance
5.4: Legal
5.1 Governance
5.1.1 Governance Scope
StakeWise V3 is governed by the StakeWise DAO through the SWISE token. Possessing the SWISE token grants linear voting power on governance proposals, which are first discussed on the StakeWise governance forum. Depending on feedback from the community, proposals are refined and then formally proposed on snapshot.org. While Snapshot represents an offchain governance system that requires trust in some admin to execute the outcome of votes, StakeWise mitigates this centralization vector through the implementation of a SafeSnap module. This essentially automates the outcome of Snapshot votes through an oracle-based solution, giving tokenholders direct governance power over the on-chain execution of contract upgrades and change in parameters. The SafeSnap module works as follows:
Creation of a SnapShot proposal, where each outcome contains an array of multisend transactions (can be empty as well).
Once the proposal vote closes, an escalation game starts to obtain the real outcome onchain. An initial outcome must be selected and a minimum bond must be provided using governance tokens. The questionTimeout period starts.
If one wishes to change the outcome, a bond that is twice the size of the previous one must be provided.
Once an outcome finalizes, the questionCooldown period starts. This allows the protocol multisig to censor the proposal if deemed invalid or malicious.
At the end of the questionCooldown period, the one who posted the last bond gets the whole bond balance. Anyone can execute the multisend transaction associated with the finalized outcome. An expiration timer starts, at the end of which the proposal expires.
Game theory guarantees that the true outcome of the proposal will end up onchain as there is an incentive to set the right outcome — indeed, invalidating an outcome amounts to receiving the previous bonds as reward. However, the following conditions must be satisfied for the system to work as intended:
Proposals must be monitored through offchain services by multiple parties, so that one can always set the right outcome of a proposal.
A long enough proposalTimeout must be set, so that participants have enough time to post a bond (more than 48 hours recommended).
A high enough minimumBond must be set to prevent malicious proposals.
Analysis of the StakeWise SafeSnap module reveals a minimum bond of 200K SWISE tokens (equivalent to ~6000 $USD as of the end of Mai 2024), a questionTimeout of 24 hours, a questionCooldown of 24 hours, and a answerExpiration of 7 days. We believe that both the questionTimeout and the questionCooldown durations could be increased to give more times for participants to intervene and ensure the right outcome gets onchain.
5.1.2 Access Control
Contracts controlled by the StakeWise team:
VaultRegistry: Ownable2Step by 4/7 protocol multisig wallet.
Keeper: Ownable2Step by 4/7 protocol multisig wallet.
OsToken: Ownable2Step by 4/7 protocol multisig wallet.
OsTokenConfig: Ownable2Step by 4/7 protocol multisig wallet.
OsTokenVaultController: Ownable2Step 4/7 protocol multisig wallet.
CumulativeMerkleDrop: Ownable2Step by 2/2 protocol multisig.
Contracts controlled by vault admins:
Vault: deployed behind a ERC1967Proxy. The GenesisVault is owned by a 1/2 protocol multisig. Other vaults are owned by third-party admins.
SharedMEVEscrow: each vault can have its own SharedMEVEscrow. Only the associated vault can withdraw from it.
RewardSplitter: Each vault has its own RewardSplitter which receives the vault fee. It is owned by the vault admin. The one of the GenesisVault contract is owned by a 1/2 protocol multisig.
Most core contracts use Ownable2Step, which defines a contract owner that can be reassigned as part of a two-step process. The owner of an Ownable2Step contract must initiate the ownership transfer by calling transferOwnership(address newOwner). Then, the new owner must accept the transfer by calling acceptOwnership(). This process prevents the contract's ownership from being transferred to the wrong owner. The RewardSplitter contract is the only one using the OwnableUpgradeable library which, contrary to Ownable2Step, does not require approval from the new owner. The owner must call transferOwnership(address newOwner) to transfer the ownership.
Notably, StakeWise contracts do not use role-based access control. The owner of core contracts is the StakeWise 4/7 protocol multisig wallet. No pausing mechanism or ways to change contract implementations by the StakeWise DAO are present. The minting of osETH tokens can be paused, either by calling the setCapacity method of the OsTokenVaultController contract to set the capacity variable to a value lower than the current minted supply of osETH, or by removing faulty vaults from the VaultRegistry contract.
5.1.3 Distribution of Governance Tokens
The SWISE token allocation started in April 1st 2021, represents a total of 1,000,000,000 SWISE tokens, and can be summarized as follow:
25% for investors, six months cliff, and 24 months of vesting
25% for founders, six months cliff, and 48 months of vesting
50% for the community, no cliff, and 48 months of vesting
Source: StakeWise documentation, 19/04/24
Investors are somewhat prioritized in this vesting schedule, having almost 50% of the circulating supply at the end of their vesting period. Their relative share then slowly diminishes in favor of the community. At least temporarily, significant profit-taking from investors at the end of their vesting period could severely impact market prices. As of April 20, 2024 — 3 years into the token allocation process — the peak investor share of the circulating supply would have happened approximately one year ago. The SWISE token currently trades at its lowest point since its inception in April 2021.
5.1.4 Proposals Frequency
Since the deployment of StakeWiseV3 on November 29, 2023, we counted an average of 4 monthly proposals. Because of how the governance process works, with ample discussions and feedback gathered in the forum, snapshot.org proposals are generally expected to be accepted when created. Protocol changes are deployed on-chain in a permissionless way following a positive vote from SWISE token holders, making snapshot.org proposals an integral part of the deployment process.
Source: snapshot.org (27-04-24)
5.1.5 Participation
The StakeWise forum counts 235 topics, spread into different categories including proposals, ideas, ecosystem, node operators and general discussion. Four hundred fifty-one users are active on the forum.
Source: StakeWise forum (27-04-24)
Three tags are used to identify the stage of a post on the forum. Phase 1 defines an idea that still needs to be formally defined and has yet to see significant community support. Phase 2 corresponds to the creation of a StakeWise Improvement Proposal (SWIP) along with a forum poll that lasts five days. If the poll reveals relatively higher support in favor of the change, then the post moves to Phase 3 in seven days: the SWIP is refined and goes through a vote on snapshot.org. In practice, forum tags are not correctly assigned and updated to reflect the true stage of proposals and can't be relied upon.
Source: StakeWise forum stats (27-04-24)
The forum seems to be relatively quiet during the last 30 days compared to the all-time high, although this must be taken into perspective with the forum age — 3 years as of May 2024. Forum participation is highly skewed toward a few users responsible for most of the activity, but this is not uncommon in a DAO setting.
Source: StakeWise forum users (27-04-24)
5.2 Decentralization of the LSD
5.2.1 Number of Node Operators
The StakeWise Genesis vault, which is the default vault operated by the StakeWise team that is used by users who don't wish to select a specific vault, is powered by four permissioned node operators:
5.2.2 Validators per Node Operator
When asked for information regarding its node operators and validator count, the StakeWise team redirected us to the rated.network website. However, the data provided by this platform might not accurately represent the current state of things and should be taken with a grain of salt.
Source: rated.network (05-04-24)
Almost half of the validators are operated by StakeWise, the rest being split relatively evenly between CryptoManufaktur, Finoa and DeutscheTelekom. The Lighthouse consensus client has a majority share in all node operators except for DeutscheTelekom which mostly uses Teku. Prysm, the only consensus client above the 33% majority threshold, is almost non-existent, which is positive.
We cannot attest to the diversity of the execution node clients since such information is private. This area is of concern since Geth usage is still too high, with an estimated 63% of the total execution client share, which is above the 33% majority risk of the Ethereum consensus. Using Geth by StakeWise node operators could result in a significant loss of capital in case of a bug in this client.
5.2.3 validator Enter/Exit (Churn)
Monthly Churn Rate = (exits/number of validators before a month) * 100
Monthly Churn Rate = (86 / 2319) * 100 = ~3.7%
Source: Rated Network (05-05-24)
5.3 Economic Performance
5.3.1 Revenue
According to TokenTerminal's data, StakeWise generated $37.56k in revenue in April 2024. The expenses totaled $9.08k, and the financial report only refers to the token incentives as an expense.
Source: TokenTerminal
5.3.2 Net Profit
According to TokenTerminal, StakeWiseV3 made a profit of $28.48k in April 2024.
Source: TokenTerminal (27-04-24)
5.4 Legal
5.4.1 Legal Structure
Creative Tech Free Zone Co. is the user-facing entity nominated by StakeWise Terms of Service. The company was established in a free zone in the UAE. This specific incorporation type permits a somewhat opaque ownership structure, a characteristic attributed to the legalities of free zone setups. The UAE is home to over 40 multidisciplinary free zones, designed to attract foreign investment by allowing investors full ownership of their enterprises. Among the remarkable benefits of establishing a business in a free zone are fiscal incentives such as complete exemption from corporate and income taxes, freedom to repatriate 100% of capital and profits, and independent laws and regulations for each zone.
On the downside, no one-stop-shop solution for checking the company status in all dispersed registries in the UAE seriously hampers verifying the corporate structure and ownership of Creative Tech Free Zone Co.
5.4.2 Licenses
In Dubai, the Virtual Asset Regulatory Authority (VARA) is the primary regulatory body overseeing Virtual Asset services. It is compulsory for Virtual Asset Service Providers (VASPs) aiming to engage in crypto-related operations within the Emirate to secure a license from VARA.
Licensed VASPs authorized to provide Custody Services have benefited significantly from the VARA Custody Services Rulebook updates. These updates allow them to offer staking services directly to their customers under the same legal entity without needing a separate license for Virtual Asset Management and Investment Services.
""Staking from Custody Services" is defined as 'staking' or otherwise using, committing, pledging, or locking up Virtual Assets for which the VASP is providing Custody Services to participate in the consensus mechanisms or other maintenance, operation or functioning of a DLT to which those Virtual Assets relate, and may include receiving rewards generated and distributed for that participation."
VARA binds the definition of staking only to the scope of activities allowed for VASPs. No reference for non-custodial staking is made in the rulebook. Non-custodial staking technically is not entangled with a particular organization (regardless of its licensing status) to secure the blockchain network. The regulator does not touch upon the cases where users pledge their crypto assets to a smart contract to reach the same output, i.e., participating in the consensus mechanism.
We need to determine whether all the staking models differing from those conducted by custodians are intentionally excluded from the legislative scope. Currently, VARA only provides instructions for this staking. The authority also needs to clarify if operators of portals giving access to non-custodial services shall be subject to VASP license requirements.
Creative Tech Free Zone Co is not entered in the Public record of Licensed Virtual Asset Service Providers. A counter-argument for the omitted listing is the entity's obligation to comply with VASP regulations. At the same time, it does not carry out any of the activities prescribed therein.
5.4.3 Enforcement Actions
No records of any specific enforcement actions, lawsuits, or regulatory measures directly mentioning StakeWise or Creative Tech Free Zone Co. These entities have not been involved recently in any public legal or regulatory issues documented in the available sources.
5.4.4 Sanctions
Eligibility for website or application access depends (among other requirements) on the user's association with sanctions designations.
Specifically, access is restricted for any individual or entity, as well as entities owned or controlled by such persons, who conduct activities directly or on behalf of sanctioned individuals or entities. This prohibition extends to those in sanctioned regions, including Belarus, Burundi, Crimea and Sevastopol, Cuba, the Democratic Republic of Congo, Iran, Iraq, Libya, North Korea, Somalia, Sudan, Syria, Venezuela, or Zimbabwe. Additionally, access is denied to those who are subject to sanctions administered or enforced by the U.S. Department of the Treasury's Office of Foreign Assets Control, the U.S. Department of State, or any other governmental authority identified on the Denied Persons, Entity, or Unverified Lists by the U.S. Department of Commerce's Bureau of Industry and Security; or are located, organized, or resident in any country or territory currently under economic sanctions.
5.4.5 Liability Risk
Terms of Service (ToS) represent a legally binding agreement between the user and Creative Tech Free Zone Co., governing access to stakewise.io website, the application app.stakewise.io, and other related platforms. The services provided include web-based interfaces that enable users to engage directly with decentralized protocols to stake ETH on the Ethereum blockchain. ToS provisions highlight that Stakewise does not operate as a broker, dealer, exchange, investment adviser, custodian, or financial service provider of any kind; rather, the services are purely technical, facilitating user access to software for direct crypto asset staking on the Ethereum blockchain without any intermediation by Stakewise.
Users can independently configure, administer, and initiate a Vault using the "Vault Toolkit" via the Protocol. Each user who sets up a Vault is solely responsible for its management, including the associated validator node(s).
Through the Protocol, users may acquire an ERC-20 cryptographic receipt token known as "osETH," which is freely transferable. This token proves that the holder is entitled to receive, control, hold, and dispose of staked ETH and any rewards from the Ethereum network accruing to such staked ETH. The governance of osETH is subject to separate terms and conditions as detailed in the osETH User Agreement, which is constructed by the laws of the United Arab Emirates.
Creative Tech Free Zone Co. disclaims liability for any loss of osETH and shall not be held liable for any consequential, indirect, incidental, or special damages as stipulated in the User Agreement. The risk disclaimer sections clearly state that osETH is issued by the Protocol on an "as-is" and "as-available" basis, and the company does not make any warranties in this regard.
Disputes, claims, and controversies arising from the User Agreement shall be subject to binding arbitration in the UK under the auspices of the London Court of International Arbitration. The arbitrator will enforce the substantive laws of the United Arab Emirates, specifically excluding any conflict of law or choice of law provisions. Furthermore, the User Agreement includes a waiver of class action and jury trial rights.
5.4.6 Adverse Media Check
Several discussions on the governance forums indicate instances of scams by StakeWise impersonation.
Fake DAO Proposal: User reported being tricked by a proposal on what seemed to be the StakeWise DAO's official site. The proposal turned out to be a scam, leading the user to malicious sites where they were deceived into signing transactions that resulted in the theft of funds.
Phishing Attempts: There were complaints about the presence of scammers in the forums who responded to users' queries with deceptive intentions, aiming to manipulate them into unsafe actions.
Airdrop Scam: A specific incident involved a user who believed they were claiming a token drop, which led to their funds being stolen.
Section 6: Risk Management
This section will summarize the findings of the report by highlighting the most significant risk factors in each of the three risk categories: Market Risk, Technology Risk, and Counterparty Risk.
6.1.1 Market Risk
LIQUIDITY: Does the LSD have a liquid market that can facilitate liquidations in all foreseeable market events?
57% of all osETH tokens are deposited into EigenLayer, a portion so significant that any event specific to EigenLayer could directly impact osETH's liquidity. Although the osETH peg relative to ETH has been relatively stable so far, so much liquidity stuck in EigenLayer could adversely impact the peg on secondary markets, and this despite active liquidity incentives effort from the StakeWise team.
It is clear StakeWise attempts to distribute liquidity across several venues where it is paired with different assets. This, along with its relatively stable liquidity profile in recent months, does create additional confidence in its resiliency in various market scenarios, including platform specific issues.
VOLATILITY: Has the LSD had any significant depeg event?
Minor volatility has been witnessed at the beginning of V3. Lately, there has been a minor but constant positive depeg, indicating a relatively high demand for osETH on secondary markets which is outside StakeWise's control. An effort was made to prioritize users while maintaining the osETH peg on secondary markets by having the modal automatically switch between protocol withdrawals and secondary market swaps.
The 10% buffer of overcollateralized ETH protects osETH holders from underperforming or slashed validators operated on their behalf. It is bigger than what is commonly observed in other liquid staking protocols, and can tolerate small to moderate slashing penalties. The soft peg of osETH to ETH has been successfully maintained through redemptions, while no liquidation has been witnessed so far. We note that this system hasn't been live for long, and its efficacy remains to be proven on the longer term under more adverse conditions.
6.1.2 Technology Risk
SMART CONTRACTS: Does the analysis of the audits and development activity suggest any cause for concern?
Three audits were conducted on the V3 codebase, and many more on previous versions of the protocol — we believe this previous experience provided engineers with valuable insights for creating V3. Audits revealed few issues that were fixed by the team, most of them related to migrating V2 to V3.
The codebase is public, well documented and modular, and repository activity is indicative of professional development practices. A bug bounty is available on Immunefi, although the maximum payout is relatively small compared to industry standards. The protocol has not suffered from any breach of security so far, nor was anyone able to claim an Immunefi bounty.
DEPENDENCIES: Does the analysis of dependencies (e.g., oracles) suggest any cause for concern?
The StakeWise V3 protocol depends on two offchain services — the Operator and the Oracle. Although both are important, the Oracle is not open source, which represents a gray area of the protocol. That being said, it is operated by a decentralized network of known entities over which the StakeWise has no direct control, which helps to alleviate centralization concerns. Moreover, manipulation of reported validator balances and rewards or validator exit credentials is prevented by smart contract checks.
The RedStone pricefeed, which is based on the median of three well funded liquidity pools that are incentivized by StakeWise and used by protocols such as Morpho and Gravita, is the available oracle option. However, RedStone is relatively centralized and secures substantially lower values than the incumbent oracle provider Chainlink, and thus we consider it more suitable for isolated lending markets than collateralized stablecoin protocols.
6.1.3 Counterparty Risk
CENTRALIZATION: Are there any significant centralization vectors that could rug users?
The StakeWise V3 protocol is fairly decentralized and permissionless, with limited control from the StakeWise team over deployed contracts, and no control over vault contracts. Those are controlled by vault admins, and there is no obvious ways one could get hold of the users' funds inside of them.
A 4/7 multisig is the owner of all but the vault contracts. Signers are known public entities that StakeWise has no direct control over. The network of offchain Oracles are also operated by a set of publicly known entities separated from StakeWise. We regret however that the code for the Oracle remains private, as its role in the protocol is central. The execution client diversity remains unknown, especially the share of validators depending on Geth, which is a cause for concern as currently a bug in Geth could put users' funds at risk.
LEGAL: Does the legal analysis of the Protocol suggest any cause for concern?
StakeWise is incorporated in a free zone of the UAE, which provides a lot of flexibility from a business administration standpoint, yet the ownership structure often remains opaque. VARA, the regulatory authority in the UAE, has not yet extended its oversight to include non-custodial staking which suggests a degree of regulatory latitude for Stakewise, provided that the protocol refrains from engaging in illicit activities. The terms governing user interactions are meticulously detailed, distinguishing clearly between interactions with the protocol itself and the usage of the osETH token. Emphasis is placed on limiting liability and disclaiming any warranties concerning osETH and the use of the protocol.
6.1.4 Risk Rating
Based on the risks identified for each category, the following chart summarizes a risk rating for osETH as collateral. The rating for each category is ranked from excellent, good, ok, and poor.
We rank osETH as ok on liquidity because, despite it being mostly deposited into EigenLayer, it still displays acceptable liquidity venues thanks to its liquidity incentive program.
We rank osETH as good on volatility because the mechanisms in place successfully managed to preserve its soft peg to ETH so far, although the reduced liquidity could adversely impact it eventually.
We rank osETH as excellent on smart contract because it has undergone three audits with few small findings, and analysis of the open source code displays professional development practices.
We rank osETH as ok on dependencies because there is a RedStone price feed available, although we are not prepared to endorse its usage in the Prisma protocol.
We rank osETH as good on decentralization because there are no significant centralization vectors, although a more advanced access control system could further strengthen the protocol and allow the team to better intervene in case of a security breach.
We rank osETH as good on legal because its legal structure is created with a compliance-oriented mindset. Responsibilities are clearly outlined in their user agreements, such that users can interact with the protocol in full awareness of the risks involved.
StakeWise succeeded in creating not just a liquid staking protocol, but a full-fledged liquid staking infrastructure that anyone can use in a way to suit their needs — be it a staker, a minter, a vault admin, or a node operator.
Our overall assessment is that osETH performs uniformly well over the risk spectrum, although it faces limitations that prevent immediate consideration for onboarding. Most notably, we recommend securing a Chainlink price feed before onboarding to Prisma. Liquidity remains the principal venue for improvement, with most of the supply being stuck in EigenLayer. More advanced access control capabilities and a special consideration for securing the protocol under adverse conditions — namely fine-tuned pausing capabilities — are some of the improvements we would like to see.
We believe that osETH is a well-rounded liquid staking token that is mature enough to be onboarded as collateral, pending the availability of a Chainlink price feed. StakeWise has indicated their communication with Chainlink and intention to introduce a feed for osETH, although the time frame for this development is unknown. We therefore recommend to await this development and consequently to consider osETH as a collateral type on Prisma.
StakeWise succeeded in creating not just a liquid staking protocol, but a full-fledged liquid staking infrastructure that anyone can use in a way to suit their needs — be it a staker, a minter, a vault admin, or a node operator.
Our overall assessment is that osETH performs uniformly well over the risk spectrum, although it faces limitations that prevent immediate consideration for onboarding. Most notably, we recommend securing a Chainlink price feed before onboarding to Prisma. Liquidity remains the principal venue for improvement, with most of the supply being stuck in EigenLayer. More advanced access control capabilities and a special consideration for securing the protocol under adverse conditions — namely fine-tuned pausing capabilities — are some of the improvements we would like to see.
We believe that osETH is a well-rounded liquid staking token that is mature enough to be onboarded as collateral, pending the availability of a Chainlink price feed. StakeWise has indicated their communication with Chainlink and intention to introduce a feed for osETH, although the time frame for this development is unknown. We therefore recommend to await this development and consequently to consider osETH as a collateral type on Prisma.
© 2023 Llama Risk. All rights reserved.