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:

• Curve osETH/rETH

• Balancer osETH/WETH

• UniswapV3 USDC/osETH

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:

• Curve osETH/rETH

• Balancer osETH/WETH

• UniswapV3 USDC/osETH

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:

• StakeWise V1/V2 smart contracts

• StakeWise V3 smart contracts

• StakeWise V3 Operator off-chain service

• StakeWise Subgraph

• StakeWise SDK

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:

• Chorus.one

• StakeFish

• Deutsche Telekom

• Finoa

• Bitfly (operator of beaconcha.in)

• SenseiNode

• Gateway.fm

• Gnosis Chain team

• P2P

• DSRV

• 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 /validators to retrieve available validators to be registered.

• POST /validators will be used to submit exit signatures for validators identified using the previous endpoint.

• GET /metrics for 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.

• Oracle validates the request and returns the signed payload if it is valid.

• The Operator submits 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:

• Uniswap V3 (osETH/USDC)

• Balancer (osETH/WETH)

• Curve (osETH/rETH)

This pricefeed is used by the following protocols:

• Gearbox

• MorphoBlue

• GravitaProtocol

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:

1. Creation of a SnapShot proposal, where each outcome contains an array of multisend transactions (can be empty as well).

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

3. If one wishes to change the outcome, a bond that is twice the size of the previous one must be provided.

4. Once an outcome finalizes, the questionCooldown period starts. This allows the protocol multisig to censor the proposal if deemed invalid or malicious.

5. 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:

• Cryptomanufaktur

• Deutsche Telekom

• Finoa

• StakeWise Labs

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.