Staking on Ethereum: an analysis of options, the current market, and protocol and network risks

# Staking on Ethereum: an analysis of options, the current market, and protocol and network risks ## Background There has been heated discussion in the Ethereum staking community regarding the possible risks that large staking solutions pose to the Ethereum network due to the size of stake that may flow through any one solution, and I wanted to collect my personal thoughts on this in one place. The point of this document is not to necessarily argue one way or another (although by the time you get through it I think my opinion will be clear), but to provide nuance and clarity on a topic that desperately requires it. The debate has now been put to [discussion on Lido's forums](https://research.lido.fi/t/should-lido-on-ethereum-be-limited-to-some-fixed-of-stake/2225), and I hope that this analysis will help inform people's opinions. Ultimately I aim to repurpose this content into a series of more approachable and easily digestible articles, and I welcome comments, feedback, corrections, and suggestions in furtherance of this. _Disclaimer: I am a Lido contributor. Lido is a DAO and makes decisions collectively, and these opinions are my own and not official Lido positions, and it's possible/likely that some of my fellow contributors disagree with me on some of the below._ *Originally published May 27, 2022.* ### The landscape of staking solutions To properly delve into this subject, let's first broadly lay out the current landscape. These are the current ways that one can stake on Ethereum. The recently updated [Staking section](https://ethereum.org/en/staking/) on Ethereum.org is also also a good resource to start with. In order to operate an Ethereum validator someone must run the following software: * An Execution Layer (we used to call this "eth 1 .0") client * A Consensus Layer beacon node client (Ethereum's PoS consensus layer is the Beacon Chain) * A Consensus Layer validator client (most clients offer "bundled" beacon nodes and validator clients, but it's not necessary to do so) and ensure that it's in good working order once the validator has been activated. Additionally, someone must: * generate a private/public validator key pair * have withdrawal credentials ready * deposit 32 ETH into the Execution Layer ["Eth2 deposit contract"](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa) and provide the above (public validator key, withdrawal credentials) as parameters The cool thing is that the above responsibilities and actions do not all need to be performed by the same person/entity, which has generated a host of options for stakers to choose from, so let's look at the broad categories of staking solutions available. |Method|Description|Notes| |-|-|-| |Solo Staking|A user deposits 32 of their own ETH into a validator that they spin up themselves, which is can be run locally (e.g. in their home), on a hosting provider, on the cloud, etc. All of the technical and operational burden (with the exception of maintaining the machine(s) in some cases) falls on the user.|32ETH (currently at ~2K USD)/validator is a higher barrier to entry for most users, and although there are now easy guides to follow and even few-click-installers for setting up your own validator, the real risk here is when something goes wrong or if a user hasn't fully understood risks around slashing etc. when creating their setup. | |Staking as a Service|A user deposits 32 of their own ETH into a validator, but the hardware and software is operated by a third party. In order for the third party to run the infrastructure, a user must also provide the validator private key somehow to the provider. |There is a strong element of trust here as the validator key is entered into systems which are managed by the provider, so it's possible that the validator key may be compromised without the staker's knowledge. In some cases, the provider also manages/creates the withdrawal keys for the user, which is an additional risk.| |Staking Pools/Protocols|Staking protocols or pools gather stake deposits from many different users (the minimum stake may differ per protocol), aggregate them together, and then set up and run validators, by themselves and/or via 3rd party node operators, potentially allocating stake in different ways across these operators. Some staking pools/protocols are custodial (i.e. they control user funds once they have been deposited), and others are non-custodial (i.e. the pool and the operators cannot access user funds). Non-custodialness is achieved via smart-contracts.|These staking offerings have the largest characteristic variability between them, since essentially they are on-Ethereum "application-layer" solutions to the delegated stake problem. Solutions can range from somewhat trusted to mostly trustless, and from semi-permissioned to permissionless. Decentralization is trickier to assess, because it has many facets which do not receive the consideration they should. Some staking pools also offer liquid staking tokens which represent staked ETH and respective rewards, which can be used in DeFi (more on this below).| |Staking on Centralized Exchanges|Centralized exchanges allow users to deposit any amout of ETH (the minimum varies per exchange) and the centralized exchange (or node operators it contracts with) aggregates deposits across multiple users and spins up validators. The process is custodial from start to finish.|In most cases these exchanges are running their own validators (i.e. they have direct control over both the funds and the hardware+software that is being used to validate). Sometimes they outsource validators to 3rd parties, or even employ a hybrid model. Centralized exchanges can also offer things like liquid staking tokens, which may be useable only internally (within the CEX) or both internally and externally.| ## On staking rewards and withdrawals It is currently not possible to stop ("exit") a validator on Ethereum _and_ withdraw the rewards back to the Execution Layer. Withdrawal operations are planned to be enabled in the first Consensus Layer (Beacon Chain) hard fork after the Merge, dubbed ["Capella"](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/beacon-chain.md) (["Shanghai"](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) is the Execution Layer hardfork that will happen at the same time). It is planned that withdrawal operations will include the ability for partial withdrawals -- the ability to "skim" any accrued rewards over the 32 ETH minimum that a validator requires to be fully functioning and active -- so that rewards may be returned to the Execution Layer without having to fully exit the validator. Only balances up to 32 ETH on each validator accrue staking rewards, so already accrued rewards (i.e. anything above 32 ETH) do not also accrue rewards. Because of this, true compounding of staking rewards is not possible (until partial withdrawals are introduced). Until withdrawal operations are enabled on the Beacon Chain, protocols which advertise that they are compounding staking rewards are misleading users (more on this later). When any user stakes on Ethereum, their stake and rewards are locked until the relevant validator is exited, and rewards can be withdrawn. Currently, whoever controls the validator private keys determines when a validator can be (voluntarily) exited, although there have been [mechanisms](https://ethresear.ch/t/0x03-withdrawal-credentials-simple-eth1-triggerable-withdrawals/10021/) [proposed ](https://ethresear.ch/t/withdrawal-credentials-exits-based-on-a-generalized-message-bus/12516)to allow those who control withdrawal credentials to also trigger validator exit and/or (partial) withdrawals. ### Liquid staking Liquid staking is a solution whereby a user's staking deposit (and relevant accrue rewards) is represented by a token. This allows users to both participate in staking (i.e. securing the network), as well as use this capital that would otherwise be locked to perform on-chain activities (e.g. lending, yield farming, trading, etc.). Liquid staking tokens accrue value through mechanisms by which the value of staked ETH + rewards is retrieved from the Consensus Layer (Beacon Chain), and reflected in tokens which reside on the Execution Layer. There are two main types of liquid staking token models: single-token models, and dual-token models. #### Single token models The most common model for liquid staking tokens is the "single token" model, whereby both the deposit and the accrued rewards are bundled together. The tokens may increase in value either via a rebasing mechanism, where the amount of the token grows, (e.g. Lido's [stETH](https://blog.lido.fi/steth-the-mechanics-of-steth/)), or via value-accrual, where the value of the token relative to ETH increases (e.g. Lido's wrapped version of stETH [wstETH](https://help.lido.fi/en/articles/5231836-what-is-wrapped-steth-wsteth), Rocketpool's [rETH](https://medium.com/rocket-pool/rocket-pool-stakers-guide-2c5c324b1749), or Binance's [bETH](https://academy.binance.com/en/articles/what-is-beth-and-how-to-use-it)). #### Dual token models Other protocols use dual-token models, whereby one token represents only the deposited ETH (which in theory could only decrease, e.g. in the case of validator slashing and/or extended inactivity), and another token represents the accrued rewards (e.g. Stakewise's [sETH2/rETH2](https://docs.stakewise.io/tokens)). ### Staking rewards |Method|Description|Notes| |-|-|-| |Solo Staking|Rewards are accrued on the validator and are locked. The validator must be exited in order for rewards to be retrieved, or (as per Capella specs, once they're implemented) the staker may elect to withdraw accrued rewards during times when their validator has been selected as a block proposer.|If a user loses their validator private key, they cannot exit the validator and cannot retrieve their ETH and rewards. Validator operation costs are born by the user.| |Staking as a Service|Same as for solo staking.|Same as for solo staking, except validator operation costs are born by the Service Provider (which are baked into the flat fee or % commission on rewards that the Service Provider charges). Extra complexity may be present if withdrawals are not sent directly to user-control withdrawal credentials.| |Staking Pools/Protocols|Rewards are accrued on the validator and are locked, but many staking pools/protocols offer liquid staking. Some staking protocols offer non-custodial solutions without a liquid staking token, such as [stakefish](https://stake.fish/en/ethereum/). Liquid staking allows for users to have access to a market-priced (see below) token which can be used in DeFi. This allows users to not only make decisions about their "locked" stake (e.g. the ability to sell or trade (portions of) it when otherwise it would be locked, but to also use it for things like collateral, providing liquidity, etc.).|Most staking pools/protocols charge stakers a flat % commission on staking rewards. It's theoretically possible for users to also be charge during deposit / withdrawal. Apart from Execution Layer rewards in the form of the liquid token, liquid staking also exposes users (i.e. there are both pros and cons) to things like socialized rewards/losses, rewards smoothing, market externalities, etc. Things like socialized rewards/losses, rewards smoothing, etc. may also be offered by staking pools/protocols that do not have a liquid staking token.| |Staking on Centralized Exchanges|Rewards are accrued on the validator and are locked. Stake deposits and rewards will not be withdrawable until after withdrawal operators are enabled on the Consensus Layer. The larger exchanges have expressed plans in the past to offer liquid staking, but so far only Binance is offering a token (which can be used internally on the exchange and on Binance Smartchain).|Centralized exchanges can be quite varied in terms of staking rewards and fees, as there are incentives for them to maximize customer LTV, so it may even make sense to offer zero-fee staking (e.g. Binance). That said, most of the large exchanges currently offer flat % commission on staking rewards.| ## Market pricing of liquid staking tokens A liquid staking token is basically a claim to either staked ETH + accrued rewards on the Beacon Chain (single-token model), or is just a claim to staked ETH or accrued rewards (dual-token model). Let's assume the single-token model below and stETH as the token for simplicity, but this explanation basically applies to all liquid staking solutions. ### Liquid staking token markets, exchange rates, and arbitrage Calling the stETH/ETH relationship a "peg" is incorrect, and we should stop doing it. There's no implicit or explicit need for stETH/ETH to trade at parity, it's simply the expected (by some) long-term risk-adjusted outcome in the markets if everything is going well. Arguably, it should perpetually trade at a slight discount due to various factors (smart contract and governance risk, the fact that withdrawals take time, etc), but markets are short-sighted like that -- so what you get is a very optimistic exchange rate during fair weather and a volatile rate during adverse conditions. [The primary market](https://twitter.com/hasufl/status/1524717773959700481) is simply the staking of ETH and unstaking of stETH for staked ETH + accrued rewards, via Lido smart contracts. The primary market cannot work fully until withdrawals have been implemented on the Consensus Layer. There are three main things that affect the value of stETH in this market: * How well Lido's node operators are performing (i.e. the net effect of validator rewards and losses) * The size of, and rate at which, withdrawals can be processed * Impact from risks related to the staking protocol itself (i.e. smart contract risk, governance risk, etc.) The secondary market is stETH's usage outside of the Lido smart contracts. This can be anything from on-chain DEXes and DeFi protocols, to off-chain centralized exchanges. The crux here though is that the primary market directly affects the price of stETH on the secondary market, but the secondary market cannot affect the price of stETH on the primary market. This allows for a "natural arbitrage" in market conditions where the stETH/ETH exchange rate is > 1:1. However, because withdrawals are currently not enabled on the Beacon Chain, there is no way for arbitrageurs to unstake stETH, redeem it 1:1 for (staked ETH+accrued rewards), after waiting for the withdrawal period, and then use that to profit from balancing the exchange rate between the two markets. Hence, when stETH/ETH rises, stETH trades at a discount due to negative carry and needs sufficient time and support from external mechanisms to find its way back towards 1:1. Let's examine the reverse as well. Why does stETH/ETH rarely trade < 1? If we think about it a little bit, this would actually be expected! Why? Because stETH rebases (increases in quantity, daily) to reflect accrued rewards on the Beacon Chain. To use simple numbers, and assuming a stETH/ETH rate of 1:1 on Curve, if I staked 100,000 ETH today with Lido tomorrow I would have `1000*(NET_APR/365), NET_APR is ~3.6%` stETH, so ~100,009 stETH. I could then go to Curve and purchase 100,009 ETH (probably a little bit less, because there is price impact+slippage and also gas fees to consider). This will create an imbalance in the pool, which means that the rate will then go > 1:1, and that trade is no longer profitable. At that point, if a user wants more stETH, it makes more sense to buy it from the secondary market. However, if the rate is ever < 1:1, what I can do is get 1 stETH for depositing 1 ETH through the Lido smart contract! The natural arbitrage mechanism to "cap" the exchange rate at 1:1 already exists, and it's the vanilla stake/deposit mechanism. #### Compounding of staking rewards Earlier I discussed that true compounding is not possible until after withdrawals -- so why do some staking solutions (and/or liquid staking integrations) say that they Ethereum compound staking rewards? In actuality what they do is sell liquid staking rewards on the Execution Layer side for ETH, and then re-stake that ETH; this creates price impact in the token/ETH pair on secondary markets, which may not necessarily be recovered. Especially if done with large volumes, this can create significant sell pressure for the token/ETH exchange rate on the secondary market, and protocols / integrations should be much more forthcoming about this. #### Not all liquid tokens are the same Why do some liquid staking tokens have a strong secondary market exchange rate to ETH, but other liquid staking tokens do not? The first difficulty we face when comparing these is to "normalize" how we denominate the exchange rates, since some tokens are rebasing and some are value-accruing (i.e. it's possible for value-accruing tokens to be > 1:1 when compared to ETH, but in fact be "below actual value"). Once we do that, we can examine the mechanisms that support these exchange rates. Apart from the expected reasons for why one protocol's liquid token may trade better in relation to ETH than others (e.g. reputation, performance, history of attacks to protocol etc.), there are also mechanisms that protocols can employ to support the token/ETH exchange rate while withdrawals are not yet enabled. ##### Liquidity incentivization The most effective such mechanism is liquidity provision incentives (e.g. Stakewise, Lido engage in this, amongst others). As Hasu [explains](https://twitter.com/hasufl/status/1525427077394141186?s=20&t=CTFId6mTSGVMcphi_3QTFg), staking protocols that engage in this are going above and beyond to offer an optional service to give stakers liquidity+optionality in the pre-withdrawals era, and are doing that by offering governance token rewards to users who provide liquidity. Incentives are effective because they not only offer users incentives right now, but also because liquidity begets liquidity. Different liquid staking protocols utilize different DEXes/AMMs in order to promote liquidity. stETH, which is a rebasing token, works well in an stETH:ETH pair on Curve where pairs that are relatively stable excel. wstETH, rETH, and rETH2 utilize concentrated ranges in AMMs like Uniswap v3, since those are better suited for non-rebasing tokens. Interestingly, some protocols/communities leverage pre-existing strong stETH/ETH liquidity in Curve in order to create liquidity for their own liquid staking tokens by pairing against stETH instead of ETH (e.g. the Curve [rETH/wstETH pool](https://curve.fi/factory/89/deposit)), although lack of liquidity through a direct-to-ETH pair can result in undesired arbitrage effects in adverse conditions (e.g. the rocketpool deposit pool may be drained by arbitrage bots as a means to purchase cheaper wstETH via the Curve pair). ##### "Exit" pools Some protocols may have a mechanism whereby a pool exists to satisfy (some limited number) of demand for "early-exit" (pre-withdrawals). This is usually done by keeping some ETH available in a pool only for redemptions, or dual-purposing the deposit pool as an exit buffer. In rocketpool, for example, the protocol has the built in ability for users to ["unstake early"](https://docs.rocketpool.net/overview/faq/#how-can-i-access-my-deposit-and-rewards-before-eth2-phase-2), utilizing the protocol's deposit pool (currently up to 2,000 ETH). The [deposit pool](https://docs.rocketpool.net/overview/glossary.html#deposit-pool) is a limited size (parameter controlled by the Guardian (if bootstrap enabled) / Oracle DAO) buffer where user deposits sit until they can be matched with minipools created by node operators. This mechanism can support the rETH/ETH exchange rate on the secondary market and works well in that it has a steady "over-time" effect (especially if that ETH is otherwise unused due to supply-constrained node operators), but the effect is in general minimal and not very impactful during adverse scenarios. The effectiveness of this mechanism for token/ETH exchange rate support is related to: * the size of the pool in absolute terms * the size of the pool / protocol TVL (a proxy for how much demand for exit can be serviced) * the replenishment rate of the pool (i.e. rate of inflows) * the rate at which minipools are being created by node operators (i.e. rate of outflows) Once a protocol is sufficiently large, this mechanism doesn't really work for the above purpose, because of the following reasons (need to be considered in concert): * ETH that is sitting in the pool is basically dilutive to the protocol's (and thus stakers') APR * The pool would need to be very large to effectively support the token/ETH exchange rate * Having a large on-chain stagnant balance is basically a honeypot * In adverse scenarios that pool will be snatched up by arbers/bots, and will do very little for individual stakers There is an additional complication added when using exit pools for "unstaking" (either dedicated ones or dual-use deposit pools) -- in cases where outflows (stake redemptions) outweigh inflows (stake deposits), a protocol may have periods where it doesn't add net new stake to the protocol, despite stake deposits being made. In certain scenarios, one might imagine that these requests for redemption may even surmount ETH that is freed up from "cycling" validators (partially/fully withdrawing from them in order to compound rewards or create redemption liquidity). Given the difficulty (current impossibility) of rebalancing stake across operators, this basically makes it much harder for a protocol to manage attributes of their validator set (e.g. client diversity, infra diversification targets). For example, imagine a scenario where a subset of current node operators/validators are under-performing or are offline and irrecoverable -- it is both more effective and efficient to get "new" stake allocated to new validators, rather than having to wait to "cycle" the deposited ETH out and back in, especially if your "ETH-to-be-staked" pool is constantly getting zapped by redemptions (which is likely if a pool is under-performing, as users will want to rotate out). ## Assessing characteristics of staking solutions ### Custody, Trustlessness, and Permissionlessness Custody, trustlessness, and permissionlessness are words often mentioned when discussing staking solutions, but they're usually neither well defined nor nuanced in their use, so let's try to improve on that a little bit. Most importantly, these terms should not be treated as binary, but rather as spectrums. **Custody** is a spectrum from custodial to non-custodial. Custodialness is the degree to which user (staker) funds which have been deposited, or rewards which have been accrued or received related to said deposit, are under direct control by any of the parties related to the execution of the staking solution. In a theoretical sense, it could be argued that smart-contracts (especially upgradeable ones) are not enough to fully achieve non-custodialness, which is why it is important to determine and assess who can upgrade smart contracts and in what conditions. **Trustlessness** is a spectrum from trusted to trustless. Trustlessness is the degree to which a user (staker) must trust, either explicitly or implicitly, that their assets, private information (e.g. validator private keys where applicable), and the proper operation of the staking solution are dependent upon specific intermediaries (or disintermediation mechanisms). My personal view (although slightly unorthodox) is that there is no such thing as complete trustlessness (so no such thing as a completely trustless solution). In theory, even the proper operation of a non-upgradeable smart contract is to some extent dependant upon things like the proper and continued operation of the EVM, for instance. However, it is fine to refer to solutions as trustless if for all _practical_ intents and purposes they function trustlessly. **Permissionlessness** is a spectrum from permissioned to permissionless. Permissionlessness is the degree to which an actor is allowed to freely partake in the execution of an activity. I believe that there is no such thing as fully permissionless, because every action has a cost or requirements (e.g. energy, time, effort, capital, vicinity/closeness etc.). However, in practical terms, the permissionlessness of staking solutions can be thought of as the extent to which a staking solution prevents someone from participating, or increases / decreases these costs and/or requirements for an actor to partake in an activity. From a staking solution perspective, there's two separate facets of permissionlessness -- one for users (stakers), and one for those who run validators (node operators) (*n.b.* in some cases the same user may be both the staker and the operator, or a staker *and* an operator, independently). Additionally, since in some ways node operators may need to be somewhat trusted to execute things on behalf of stakers (e.g. validator withdrawals), this also begets a permissioned element (i.e. you need to trust that they will allow it to happen). ###### Staking Solution Comparison |Method|Trustlessness|Permissionlessness (user)|Permissionlessness (operator)| |-|-|-|-| |Solo Staking|Practically trustless, provided the user can trust whatever mechanism the they are using to store their validator private key and withdrawal credentials.|In solo staking the user is also the operator. The cost to run a validator and run it well is actually relatively high (32 ETH, understanding staking, running relatively high uptime infrastructure but in a way that doesn't get you slashed, operationally much more complex than just running an Execution Layer node, etc.). That said, practically permissionless in the sense that if someone wants to *and can* do this, nothing stops them from doing so.|See user.| |Staking as a Service|Quite trusted. In staking as a service, the user may also be operator (depending on how much control they have over the software stack). Users/stakers must either enter their private key directly into some sort of vault mechanism that they do not control, or into a machine which they only control because someone else allows them to.|Permissioned in the sense that the staking service provider needs to continue to function in order for the user to validate, and it's up to the staking service provider to provide the staker with an "escape hatch" if the staking solution they are helping the user execute is complex.|See user.| |Staking Pools/Protocols|Depends on the specific solution.|Depends on the specific solution.|Depends on the specific solution.| |Staking on Centralized Exchanges|Trusted basically from start to end.|Clearly permissioned in that CEXes have the ability and right to resitrct, deny, or cease service to users for a variety of reasons (e.g. sanctions, violation of ToU, geographic availability, etc.).|CEXes either run their own validators or they choose which node operators they work with off-chain, so permissioned.| OK so let's examine some specific staking protocols (ordered based on current share of overall Ethereum staking as of 15/5/2022). Please bear in mind that below I use the terminology as defined above, not based on what ethereum.org or some article might say; the purpose here is to uncover the nuance in these solutions and their mechanisms. ###### Staking Protocol Comparison |Staking protocol|Custody & Trustlessness|Permissionlessness (user)|Permissionlessness (operator)| |-|-|-|-| |[Lido on Ethereum](https://lido.fi/ethereum)|Slightly-trusted. Lido does not custody funds in any way and its node operators do not have access to user funds, but Lido smart contracts are upgradeable (by the open DAO). Withdrawals are dependent on Lido node operators voluntarily exiting validators. Node operators control the private validator key(s) (no central management). A small and decreasing share of all Lido validators has withdrawal credentials controlled by a 6/11 [threshold signature](https://blog.lido.fi/withdrawal-credentials-in-lido/). Since July validators point to 0x01 smart contract withdrawal credentials and post-Capella the threshold-signature validators will be rotated to the same withdrawal smart contract.|Practically permissionless; anyone with >0 ETH can stake.|Permissioned; currently operators are curated by the Lido DAO, until such a time that permissionless elements can be added to the operator set in a way that minimizes risk to the protocol.| |[Stakefish "staking as a service"](https://stake.fish/en/ethereum)|Slightly-trusted (most trustless of those compared in this table). Stakefish does not custody funds in any way, but post-withdrawals they have to voluntarily/manually exit validators in order for user stake and rewards to be made available on the Execution Layer, at which point users will be able to claim their share from the withdrawal smart contract. Stakefish controls the private validator key(s).|Practically permissionless, anyone with multiples of 32 ETH can stake; the user is responsible for safeguarding their withdrawal credentials.|N/A, stakefish operates all of the validators for this service| |[Stakefish "Ethereum Shared"](https://stake.fish/en/ethereum-shared/)|Slightly-trusted. Stakefish does not custody funds in any way, but post-withdrawals they have to voluntarily/manually exit validators in order for user stake and rewards to be made available on the Execution Layer, at which point users will be able to claim their share from the immutable withdrawal smart contract. Stakefish controls the private validator keys. A separate contract is created for the deposits related to each validator which is neat, and the contracts are immutable.|Practically permissionless, anyone with > 0.1 ETH can stake.|N/A, stakefish operates all of the validators for this service| |[Rocketpool](https://rocketpool.net/)|Slightly-trusted. Rocketpool does not custody funds in any way and its node operators do not have access to user funds, but Rocketpool smart contracts are upgradeable (upgrades are made available by the Guardian while bootstrap mode is still enabled or the closed Oracle DAO, and voluntarily pulled by the Node Operator). Withdrawals are dependent on Rocketpool node operators voluntarily exiting validators. Node operators control the relevant private validator keys (no central management). Separate contracts are created for each minipool (rocketpool validator).|Practically permissionless; anyone with >0.01 ETH can stake unless the deposit pool is full. User (staker) ETH is aggregated and matched to Node Operator ETH in order to constitute the two halves (16+16) of a full validator deposit.|Practically permissionless, any operator with the capital for the necessary bond (16ETH/validator) or the ability to obtain the capital from 3rd parties may become an operator.| |[Stakewise Pool](https://stakewise.io/)|Slightly-trusted. Stakewise does not custody funds in any way and its node operators do not have access to user funds, but Stakewise smart contracts are upgradeable (by the open DAO). Withdrawals are dependent on Stakewise node operators voluntarily exiting validators. Node operators control the private validator key(s) and submit x/5 key shares to a [committee responsible for ensuring validator compliance](https://docs.stakewise.io/node-operator/generate-deposit-data#4.-send-encrypted-key-shares). A small and decreasing share of all Stakewise validators has withdrawal credentials controlled by an x/7 [horcrux](https://docs.stakewise.io/stakewise-pool#the-horcrux).|Practically permissionless; anyone with >0 ETH can stake.|Permissioned; currently operators are curated by the Stakewise DAO.| ### Decentralization Decentralization, like trustlessness and permissionlessness, is actually also a spectrum, and also multi-faceted. Permissionlessness is often conflated with decentralization. This conflation is both misleading as well as dangerous. A permissionless protocol does not guarantee decentralization -- it only allows for it theoretically (i.e. anyone being allowed to join a club doesn't mean that you end up with a well-distributed membership pool with members who have relatively similar sway). In fact, permissionlessness can actively harm decentralization if the barriers to entry (or "requirements to participate" as I called them above) disenfranchise certain of actors and give an edge to others. When examining staking solutions, here are a set of characteristics to consider to assess decentralization: * Who are the owners of the solution (e.g. smart contracts, legal entities) and what control do they have over the protocol? * Does the solution depend on specific people executing specific tasks, or are those tasks executable by others if the original executors were to suddenly stop executing them? * What is the cost / what are the requirements of participation in the solution's activities (is it really "permissionless")? * Are relevant smart contracts immutable or upgradable? If upgradable, by whom, in which circumstances, and how resilient is the upgrade process to governance attack and capture? * How much and what kind of influence/power do the "owners" or "controllers" of the solution have over its constituent parts and the actors who execute pieces of the solution? * Are there enough validators (nodes) running such that an attack against a specific (sub)set of validators is not enough to harm the protocol? * Are there enough distinct node operators running these validators such that an attack against a specific (sub)set of operators, or a malicious operator, is not enough to harm the protocol? * Is the relative power that each operator has over the network (through the protocol) taken into account? * Is the relative power of node operators well-distributed geographically and jurisdictionally? * Are nodes run in a diversified way so that single points of failure and correlated risk are sufficiently minimized? As Lido discussed in the [Next Chapter](https://blog.lido.fi/the-next-chapter-for-lido/) article, staking solutions are basically proxies for validator sets (and the node operators that run them). These validators sets (which networks depend on to function well) should be considered a public good with the ultimate purpose of minimizing risks to the network, namely: * operator compromise * network connectivity issues * operator misconfiguration * regulatory capture * infrastructure (software) bugs/malfunction Considering the above, as well as the characteristics of decentralized validator sets, Lido put forth an [Operator Set Strategy](https://research.lido.fi/t/lido-operator-set-strategy/2139) for public comment. Importantly, when considering the overall decentralizing (or not) effect of staking solutions on a network, the solutions must be considered as a part of the greater whole and not in isolation. *Ceteris paribus* assumptions are great for analyzing independent structures, but when considering the effect of limiting staking solutions in any way one needs to consider what happens in the rest of the system. To do that we'll first need to understand concerns around centralization of stake in Ethereum PoS. ## Concerns around centralization of stake ### Self-limiting doesn't do what you think it does Well-meaning decentralization proponents within the Ethereum community have recently written about the need to limit staking solution/entity/protocol "power" over the network based on flat percentages. The concern isn't without merit (I'll cover it below), but *prescribing solutions to theoretically limit stake centralization based on overall stake that conflate different types of staking solutions, ascribe to them the same level of actual risk without nuance for internal workings, and ignore the fact that the most dangerous vector of risk is direct node control -- not indirect staking protocol control -- are misguided and ultimately deleterious to the health of the network.* Let's take this line of argumentation where staking solutions would [self-cap at 22%](https://twitter.com/superphiz/status/1525218193756807169) to its logical conclusion. According to this thinking, these four possible scenarios for stake share in Ethereum are considered better than the status quo: #### Example A (leading staking pools self-cap, CEXes catch up shortly thereafter and self-cap) |Staking Solution|Type of solution|Share| |-|-|-| |Staking Pool A|Staking protocol with indirect control over node operators|22%| |Staking Pool B|Staking protocol with indirect control over node operators|22%| |CEX A|CEX with direct control over nodes|22%| |CEX B|CEX with direct control over nodes|22%| |Other|Smaller solutions, single-operators, other CEXes, solo stakers|12%| #### Example B (staking pools end up withering due to not being able to compete with CEXes on margin, CEXes self-cap) |Staking Solution|Type of solution|Share| |-|-|-| |Staking Pool A|Staking protocol with indirect control over node operators|12%| |Staking Pool A|Staking protocol with indirect control over node operators|8%| |CEX A|CEX with direct control over nodes|19%| |CEX B|CEX with direct control over nodes|19%| |CEX C|CEX with direct control over nodes|19%| |CEX D|CEX with direct control over nodes|19%| |Other|Smaller solutions, single-operators, other CEXes, solo stakers|4%| #### Example C (where CEXes don't actually agree to self-cap, which is the most likely outcome, but one staking pool still holds a decent share) |Staking Solution|Type of solution|Share| |-|-|-| |Staking Pool A|Staking protocol with indirect control over node operators|22%| |CEX A|CEX with direct control over nodes|30%| |CEX B|CEX with direct control over nodes|20%| |CEX C|CEX with direct control over nodes|15%| |Other|Smaller solutions, single-operators, other CEXes, solo stakers|13%| #### Example D (let's be charitable and assume that not only do CEXes agree to self-cap, but even to self-cap as a group) |Staking Solution|Type of solution|Share| |-|-|-| |Staking Pool A|Staking protocol with indirect control over node operators|22%| |Staking Pool B|Staking protocol with indirect control over node operators|22%| |Staking Pool C|Staking protocol with indirect control over node operators|22%| |CEXes|CEX with direct control over nodes|22%| |Other|Smaller solutions, single-operators, solo stakers|12%| My personal prediction is that likeliest outcome of on-chain staking solutions self-capping is a worse version of Example C -- CEXes will not follow suit and the last resort for the protocol will be some sort of social consensus hard fork which will irreparably damage the network's integrity. Let's examine Example B and compare it to the current status quo, where Lido (21 (and growing) independent node operators under the same banner who cannot directly be coerced into doing anything by LDO-holders) has ~32% share of all stake. In Example B, in order to attack the network, all it would take is collusion between 2-3 CEXes or regulatory attack on these CEXes (2 countries), vs ~19 operators all colluding in concert, or the regulatory bodies of the 8+ countries where these operators are operating from coordinating together. This dispersion of power across operators is a part of Lido's validator set strategy and not by mistake, and can only be accomplished when a staking pool can afford to be opinionated about the node operators that it works with and how it works with them. This is a clear argument for why on-chain staking protocols are preferable to CEXes -- stake for stake -- and it is important to understand that properly implemented governance is not analogous to central control. Much like the Ethereum protocol is maturing, so too will on-chain staking solutions. In the long-term, a single large staking pool (a federation of independent node operators) is better positioned to enforce what "good" looks like than a grouping of smaller and relatively weaker players who are forced to compete both with each other but also more centralized actors. Let's set aside how bad outcomes B and C obviously are (and even A, in my opinion), let's examine Example D which I think a lot of people believe is a "good outcome". The reality is that it won't be as nice as it looks on the surface. This is for a very simple reason: there is currently inadequate supply of quality node operators who can scale in order to meet the demand for staked ETH. This situation will not ameliorate until DVT is "solved", battle-tested, and augmented with other solutions to enable protection against sybil attacks etc. so we're talking ~2 years out. So if we go with the capping mechanism, and you were to take a look under the hood of Example D, you would find a small (< 20) common set of node operators who are actually running the nodes for staking pools A, B, and C (and potentially even for CEXes). What this proposal does is effectively reduce the (already meager) leverage that staking solutions would have over their constituent node operators. That may sound like a good thing (and arguably is if the pool is not Ethereum-aligned), but it's important to understand that a little bit of influence goes a long way when nudging operators to do the right thing, and that getting them to do something which is against their long-term interests (i.e. the interests of Ethereum) is exponentially more difficult. *The point of "winning" liquid staking isn't to swim in a Scrooge McDuck pool of ETH -- it's to prevent chain capture by CEXes or staking solutions with direct control, to work to ossify and minimize governance over time, and to turn the staking protocol's liquid token into a slightly better version of WETH. That's it, that's the game.* ### Economies of scale and validator centralization A year ago I wrote about how PoS is more centralizing than PoW [at the stake layer](https://hackmd.io/@Izzy-/Eth2VevStaking), something that will be exacerbated due to MEV. The battles of centralization and censorship resistance will be fought [in the trenches of MEV](https://www.youtube.com/watch?t=8041&v=HYPGD2bOMOo&feature=youtu.be), and the ideal construct to minimize the centralizing effect of MEV on Ethereum is a large federation of validator operators who -- under a common banner -- insulate themselves as much as possible from the complexities and even stronger centralizing effects around block building, and act according to strategies & policies around MEV that are not harmful to the network. A network where a few (5-8) solutions are staking "largish" portions of stake is not necessarily more decentralized than a network where there are 1-2 solutions staking the vast majority of stake. This is because as long as those 1-2 solutions are sufficiently decentralized, robust, and governance-minimized they can do more (i.e. be opinionated) about what good validator sets look like and enforce that opinion. If staking solutions are forced to compete based on price alone, then centralized solutions will always win long term because of economies of scale, reduced costs due to being able to perform complex procedures off-chain, and financial incentives that they can afford to offer users by maximizing for LTV, which decentralized protocols cannot. Moreover, constraining pools but not the underlying operators actually gives more power to the operators vis-a-vis the staking pools that they operate for. #### Mining pools are not staking pools Many proponents of the "large protocols should and will self-limit" argument point to mining pools on PoW chains which also historically self-limited, but ultimately this is a weak argument. From a technical perspective there are crucial differences between mining pools and staking solutions (and decentralized staking pools even more specifically) which render the comparison inapt, but we must also consider that mining pools are not as independent between them as they appear to be on the surface. Firstly, stake is not able to move across staking solutions with the same speed and agility that hashpower can move between mining pools (pre-withdrawals it can't even move at all). Secondly, the actual operator of the validator has a lot more control over block production than miners do in mining pools. Finally, mining pools are not as independent between each other as proponents of this argument make them out to be. Multiple large mining pools can be (and are) owned by the same UBOs (ultimate beneficial owners), and operate in a highly cartelized fashion. ### Market mechanics & liquid staking protocols #### Unconstrained vs supply-constrained staking growth From a staking growth perspective, there are two types of solutions: those that are supply-constrained and those that are not. Centralized Exchanges are de facto unconstrained; as long as users deposit money, the only reason for a CEX to not set up a validator is if the operational costs to run these validators are greater than the increase in user LTV gained by providing the staking service. For on-chain staking solutions the requirement is actually higher! On-chain staking protocols need a way to break even from a cost perspective and cannot afford for staking to be loss-making by offsetting the costs from gains in other areas. In terms of on-chain solutions, there are both constrained and unconstrained variants. Staking as a Service solutions are not constrained if users are putting up the full deposits and the fees/commission are at least somewhat profitable. Staking pools which allow for partial deposits (e.g. Stakefish's Ethereum shared model) may be constrained slightly as there can be gaps when insufficent ETH is available in the pool contract to submit a full validator. Staking solutions like Lido and Stakewise are practically unconstrained as long as there are node operators who know how to deploy validators at scale. Staking solutions like Rocketpool which require a bond in order for node operators to deploy validators are constrained by the ease in which the bond can be procured. Bonds can be procured in two ways: * The "intended" manner: the node operator produces the bond from their own capital. This is a great security mechanism because it basically requires operators to have skin in the game. However, this inevitably leads to a supply shortage as there are not many operators who: * "have sufficient technical skills to operate validators at scale" + * "have sufficient time and willingness to do so" + * "have the capital to do so" * Other people's money: node operators draw capital from 3rd parties in order to fund the bond; there are two general models for this. * Centralized exchanges / Funds can use user/investor money in order to spin up validators. This is actually dangerous because what it does is let them leverage and risk other peoples' money (i.e. their own skin in the game is only brand/reputational/legal in nature) to multiply their power over the network. Consider the example where a CEX has 32,000 ETH worth of user staking deposits. In the "normal" model, they would be able to set up 1,000 validators and thus have 32,000 ETH worth of power over the network. In the "bonded" model, they could use this 32K ETH to fund the NO-bonds for 2,000 validators, and thus have 64K ETH worth of power over the network. * A semi-decentralized (likely some trust involved) on-chain protocol can be set up whereby users/investors deposit money into a pool that can be used by Node Operators in order to fund their bonds. Node Operators could thus partially or fully fund the bond requirement in exchange for sharing a portion of Node Operator fees/commission with these capital providers. From a network risk perspective, it can be potentially less harmful than 1 party (a CEX) having direct control, but the only way to enforce this is to have some sort of permissioning layer in between the node operator and the capital (i.e. a multisig/DAO that controls which node operators are allowed to pull funds from this pool and how many funds). If it is permissionless, it's actually more dangerous than the CEX model. #### Bonded staking solution models, scaling, and centralization Above we explored the possibly pernicious effect of bonding models on decentralization in a permissionless protocol. Unfortunately, when we consider the only options for bond-based models to work, there's additional worrisome risks to consider. When a permissionless staking protocol using the bonding model allows for bonds to be drawn from 3rd parties, then in the long-run it has the potential to end up less decentralized than an opinionated staking protocol like Lido / Stakewise. This is because permissionless participants will be able to scale unconstrained, and with no requirement for skin in the game nor any curation/permissioning mechanism (even if there is, it's likely to be sybil attacked), there will be nothing that can be done to prevent capture of the underlying staking protocol. Eventually, the operators creating validators through this crowdsourced bonding mechanism will run the vast majority of validators on said protocols. This concern around a centralization force is basically also an attack vector. Actors who wish to attack the Ethereum network could basically use the bonding mechanism to achieve direct leverage of assets employed in an attack, effectively using the bond as a multiplier for their attack capital. As explained above, a simplistic formula for this multiplier is `STAKE_MULTIPLIER = MINIMUM_DEPOSIT / BOND_SIZE`; thus, we observe that the multiplier increases as the bond size decreases. For example, assuming a minimum deposit of 32 ETH and a bond of 16 ETH, there is a 2x multiplier for staking power, and for a deposit of 32 ETH and a bond of 6 ETH, we have a ~5.3x multiplier. Lowering bond is the other obvious way for bonding-based staking solutions to unlock scaling. If you reduce the bond, not only do you lower the barrier to entry (i.e. widen your potential operator pool), but you also allow existing operators to run more nodes. However, it is easy to imagine how bonds which are incorrectly sized (e.g. based on historic slashing instead of "what could go wrong) may possibly harm the network (e.g. via an attack, a mass slashing, en masse ransoming, or sustained quadratic leak). If we consider the two scaling mechanisms together (both lowering and crowdsourcing bonds), then we are opening a very easy path not only to rapid centralization of the staking solution, but also for a rogue actor to exploit multiplicative leverage in attacking Ethereum. #### Exogeneity of demand for staked ETH One of the arguments for not limiting a leading protocol is that basically limiting the leading protocol leads to a worse market outcome in the long term rather than letting participants compete in a level playing field (assume the field is level, and the market leader isn't relying on monopolistic tactics to maintain advantage). This argument only really holds if demand for staked ETH is predominantly exogenous -- meaning that it largely or wholly comes from market for the product in general (staked ETH) and not because of the characteristics of the specific protocol that people are staking through. In other words: if Lido were to disappear, would ETH continue to be staked at similar rates? I think the answer to that question is a resounding yes, with one caveat that we need to explore, which is the increase in demand that has occurred as a result of the advent of [leveraged staking](https://twitter.com/euler_mab/status/1525090392466767872) (stake with a protocol, take the liquid token and supply it as collateral, borrow ETH against it, re-stake, re-supply as collateral etc.). However, if we think about this closely, it's not that only Lido can offer leveraged staking (in fact it isn't even Lido that does), it's that leveraged staking is currently only possible with Lido's staking token (for economic reasons, not technical ones). Importantly, this is not because Lido has somehow prevented other staking protocols from creating the necessary conditions for their liquid staking tokens to be able to be supplied as collateral to protocols that enable leveraged staking like Aave, it's that Lido's competitors have simply not met the requirements for their tokens to be able to be supplied as collateral, the chief requirement usually being readily available and deep liquidity. If other staking protocols fail to do even this, and instead of doing the work to create and foster liquidity come up with "clever" ways to rely on stETH/ETH liquidity as a proxy for their own liquid staking token ([example 1](https://mirror.xyz/0x04BEE613690e98A1959F236c38AbAa5f2439B14a/7WkeLUv8rQFeaiYW3ZLlu67c7ZKA_Y09EMVnYuxOYS0), [example 2](https://twitter.com/stakewise_io/status/1509489849023217671)), then how can one seriously support that these protocols are ready to accept staked ETH at scale? Not only does relying on the liquidity of another protocol for your own protocol comingle risk between the assets and increase the likelihood of contagion in market downturns or during adverse events, it explicitly exacerbates arbitrage opportunities between liquid staking tokens (e.g. the rETH deposit pool was drained by bots during the recent stETH/ETH "de-peg", which made bots a lot of money but basically worsened the rETH/ETH exchange rate). ## Network health and risks So, how do we end up with the best validator set possible given the reality of the market, and how do we ensure that the largest staking solutions both passively and actively minimize risk to the underlying blockchain? I think we all agree that the ideal validator set consists of tens of thousands (or more) of individual stakers, each running at least their own validator and potentially participating in running multiple other ones via something like DVT. However, I think we're years away from such a reality, not to speak of the realignment of incentives that would need to occur at the protocol layer to "boost" solo-staking incentivization for that to be possible. In the meantime, we'll have to be a bit more clever about how we minimize risk, and a bit more thoughtful about what decentralization means in practical terms. Due to the complexity of how staking works, we need to analyze risks to the networks at multiple layers. One way set of categories for these layers could be: * Network layer (N) * Smart contract layer (SC) * Staking solution/protocol layer (SS) * Governance layer (G) * Node operator layer (NO) Earlier above I posed a set of questions that we could use to assess the decentralization of a staking solution, so let's try to relate them to these layers: |Decentralization characteristic|Risk Layer| |-|-| |Who are the owners of the solution (e.g. smart contracts, legal entities) and what control do they have over the protocol?|SC, SS, G| |Does the solution depend on specific people executing specific tasks, or are those tasks executable by others if the original executors were to suddenly stop executing them?|SS, G| |What is the cost / what are the requirements of participation in the solution’s activities (is it really “permissionless”)?|SS, G, NO| |Are relevant smart contracts immutable or upgradeable? If upgradable, by whom, in which circumstances, and how resilient is the upgrade process to governance attack and capture?|SC, SS, G| |How much and what kind of influence/power do the “owners” or “controllers” of the solution have over its constituent parts and the actors who execute pieces of the solution?|SS, G| |Are there enough validators (nodes) running such that an attack against a specific (sub)set of validators is not enough to harm the protocol *or the underlying network*?|N, SS, NO| |Are there enough distinct node operators running these validators such that an attack against a specific (sub)set of operators, or a malicious operator, is not enough to harm the protocol *or the underlying network*?|N, SS, NO| |Is the relative power that each operator has over the network (through the protocol) taken into account?|N, NO| |Is the relative power of node operators well-distributed geographically and jurisdictionally?|N, NO| |Are nodes run in a diversified way so that single points of failure and correlated risk are sufficiently minimized?|N, SS, NO| Armed with this mapping between decentralization characteristics and layer(s) of risk, we can now analyze the core risks that staking can pose to the network as a whole, how to estimate the potential effect of something going wrong, and what mitigation mechanisms can be put in place to minimize impact. |Layer|Risk|Likelihood|Impact|Mitigation Mechanisms| |-|-|-|-|-| |NO|Too many validators are directly controlled by a single party or multiple related parties which may be captured by financial interests and act against the network|Since operators have direct control of validators, increases with low dispersion of stake across operators, even if in theory a staking solution has many operators.|From annoying (operators "stealing" MEV from staking pools) to potentially catastrophic (network capture / failure).|Impact is effectively minimized if: - stake is well dispersed across numerous operators within a protocol and the network as a whole, and total per operator (per solution and/or network-wide) is maintained below critical control thresholds), and - large staking protocols are able to effectively and timely punish malicious actors.| |NO|Too many validators are directly controlled by a single party or multiple related parties which may be captured by governments or regulatory authorities and act against the network|Same as above.|Same as above.|Total validators per geographic and jursidictional zones are balanced according to risk-adjusted thresholds| |SC|Smart contract vulnerabilities are exploited|Generally increases with smart contract complexity and upgradability|From minor to potentially economically ruinous (for a protocol and/or for stakers whose deposits and rewards may be stolen).|- Multiple and thorough smart contract audits. - Reduced complexity of "base-layer" contracts. - Eventual smart contract ossification.| |SS|Staking solutions may be captured by financial interests or governments and act against the network|Depends on the legal and operational structure of the staking solution. If the staking solution is a sole legal entity in an high-risk jurisdiction, the likelihood is much higher than a solution that is well distributed and dispersed.|Potentially economically ruinous, and/or catastrophic for the network.|Decentralization is the key mechanism against this risk. The larger the staking solution in question is, and the more decentralized it is, the more robust it is against possible capture (arguably in a non-linear fashion). Smaller solutions are easier to capture, even if they are well decentralized (less power/energy/capital is necessary to capture them).| |G|Network governance may be captured by staking solutions that have large stake share, or staking solutions may be capturable by non-aligned or malicious actors via their own governance|Ethereum doesn't have on-chain governance so this isn't a direct risk from a network perspective. From a staking solution perspective, governance power on NOs and validators depends highly on how direct of an influence the governance mechanisms have over operations.|Potentially economically ruinous, and/or or catastrophic for the network.|Governance-driven mechanisms should incentivize good behavior and be useful in punishing bad behavior (i.e. not aligned with network values), but not allow for coercion. Eventually these mechanisms can be replaced by automated mechanisms to accomplish the same goal, and governance can then be minimized (i.e. its power removed over time) and allow the staking solution to ossify. Stakers should be empowered with tools/mechanisms to potentially override captured or rogue governance.| ### Closing thoughts The most complicated risk layer to reason about is governance risk because the actual effect that "stake dominance" may have on a chain via governance is very difficult to assess. It depends heavily not only on how each staking solution works from the perspective of on-chain mechanism, operations, and actual governance, and critics are right that governance can serve as a way for large on-chain staking protocols to either harm the network or as vectors for malicious attackers to use. However, the largest and clearest threat comes from operators who have direct control over the network either solely or via collusion, and focusing on the protocol/solution level rather than the operator level obfuscates this risk and results it in being under-estimated and under-mitigated. So what might a "winner take most" world look like five years down the line? |Staking Solution|Type of solution|Share| |-|-|-| |Staking Pool A|Staking protocol with indirect control over node operators|65%| |Staking Pool B|Staking protocol with direct control over node operators|15%| |CEXes|CEXes with direct control over nodes|10%| |Other|Smaller solutions, single-operators, solo stakers|10%| Why might something like this be desirable? Well, because it allows Staking Pool A to be able to enforce an opinion about [what a good validator set](https://research.lido.fi/t/lido-operator-set-strategy/2139) looks like. Capital which has strict KYC/AML requirements still has a way to be present on-chain, but its presence does not result in structures that allow adversarial actors to irreparably damage the network. Staking Pool A is sufficiently decentralized, governance-minimized, and ossified such that node operators cannot be coerced to act against the network, and stake is balanced across operators in a way where permissioned and permissionless sub-sets compete on quality but also allow for censorship resistance. There is a lot of work for any Staking Pool including of course Lido to reach such a level, and it's not without risk or hazard. It's possible that Lido fails and another protocol succeeds in its stead. The question at hand is how can we (Ethereans, as a community) foster incentivization mechanisms that make solo stakers an integral part of staking on Ethereum, safeguard the health of the protocol in the face of market conditions and potential adversaries, and effectively navigate the tension between pragmatism and ideology in order to create the best possible staking landscape.