Many thanks to Anders Elowsson for initial discussions prompting these series of posts and for his many helpful comments on the text. Thanks also to Caspar Schwarz-Schilling, Julian Ma, Thomas Thiery, Davide Crapis, Mike Neuder, Drew Van der Werff, Kydo and many others for discussions and comments on the text.Cover photo by @pawel_czerwinski?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">Pawel Czerwinski on Unsplash.

Staking, re-staking, liquid staking, liquid re-staking, re-staked liquid staking tokens, node operators and capital providers… We’ve observed since the launch of the Beacon Chain back in December 2020 an increasingly varied collection of mechanisms and constructions, starting from the protocol’s own staking mechanism.

In discussions within our team, we felt the need for a precise language allowing us to eliminate ambiguities regarding the architecture of these mechanisms. We hope to emphasise the existence of control points and incentive misalignments through the use of notation and balance sheets, since nuances matter a lot in surfacing properly the opportunities and risks. The exercise was mostly done for our own understanding, but while going through it, we felt it provided a helpful way of aggregating a collection of disparate facts and discussions into one coherent, systematic approach.

In this post and the next two, we present these constructions along with case studies. We do not aim for an exhaustive review of all the material produced by all the brilliant teams working on these mechanisms, and we mean for our semantics to be updated as needed whenever new facts reveal gaps or errors in our models.

1. Part 1: Liquefaction
2. Part 2: Re-staking
3. Part 3: Advanced construction sets for ages 16+

The current series of posts also does not draw conclusions regarding the optimality or the use of these constructions, beyond providing definitions and context for their existence. Future posts will address these questions and offer properties of these mechanisms, such as their usefulness to various classes of stakers and their economics in a larger context.

Let’s get into it!

Asset

The most basic “type” of our semantics is that of an asset. An asset may be native tokens of a decentralised blockchain, such as ETH, tokens rooted on some blockchain such as ERC-20s or NFTs, or assets constructed from other assets, as derivatives are.

Balance sheets

In the following, we illustrate our constructions with balance sheets showing the creation and transfer of assets between multiple involved parties. We always provide the balance sheets in the same format:

1. The first row represents the “pre-state”, denoting which assets are currently owned by each party.
2. The last row represents the “post-state”, denoting which assets are owned by each party after all operations have concluded.
3. The rows in between represent operations, with a new row simply denoting a new set of operations, divided from the others for the purpose of exposition.

We use two basic operations repeatedly, which are worth detailing here:

1. Asset transfer: Party A simply transfers some Asset to Party B.

1. Receipt minting: We often represent situations where Party A receives a claim from Party B, allowing Party A to redeem some assets from Party B. The receipt is then a liability for Party B, and an asset for Party A. In the following example, Party A transfers Asset to Party B, and receives a Claim from Party B.

We do not use balance sheets in a very orthodox manner, being more inspired from the Economics of Money and Banking course as well as Daniel H. Neilson’s Soon Parted newsletter (while stating for the record that we are probably not as rigorous as either of them are). However, we believe this minimal set of operations is sufficient to provide the intuition necessary.

Protocol staking

Solo staker

The first basic operation consists of placing ETH at stake in the Ethereum Proof-of-Stake protocol. In the simplest case, an ETH holder places their ETH directly in the protocol, receiving a “virtual” balance of soETH (the “so” stands for solo operator). We represent the relationship with the following balance sheets, which are read line-by-line across the various parties:

The solo staker is responsible for the operations of their corresponding validator. This means that if the solo staker performs its consensus duties adequately, the Ethereum protocol credits its balance of soETH with newly minted soETH. Conversely, when the solo staker receives penalties or is slashed, the protocol debits its soETH balance. When the solo staker wishes to withdraw their soETH balance and obtain ETH, the withdrawal is processed 1:1, i.e., for x units of soETH on the validator consensus balance, the solo staker receives x ETH in return (in the case of a full withdrawal).

Note that we do not represent “execution layer” rewards, e.g., priority fees and MEV. These rewards are a straightforward addition to the model presented above, and constitute a simple transfer of ETH from parties on the execution layer to the solo staker assuming block producer duties.

Using a Staking Service Provider (SSP)

A more complex relationship is at play when a Staking Service Provider (SSP) intermediates the relationship between the holder who wishes to stake (”delegator”) and the Ethereum protocol. In this case, the ETH holder first provides the SSP with native ETH with the purpose that it should be staked. The SSP stakes the ETH and is granted control over the “soETH” asset running at the validation layer. It confers a virtual noETH asset to the delegator (the “no” stands for node operator), against which their ETH at stake is redeemable.

Our use of the word “redeemable” already introduces some uncertainty here. As we have seen above, the Ethereum protocol allows the solo staker to withdraw their soETH balance against ETH at parity. Is this also true for the staker delegating its ETH to the SSP in exchange for noETH? In general, this is not true. First, 1 noETH could redeem less than 1 soETH, if slashing took place. Second, since most SSPs provide their service against a fee, 1 noETH redeems a fraction of the soETH credited to the SSP’s account in excess of its principal at stake. A more precise balance sheet would separate the principal from the yield, e.g.:

Here, we “unbundle” the soETH asset between the principal pETH and the yield yETH. pETH redeems at most 32 ETH, unless slashing happens. yETH redeems the consensus layer and execution layer rewards obtained by the SSP. The SSP provides corresponding claims to the delegator, no.pETH and no.yETH. The delegator may always receive their principal in full including slashings, such that a 1:1 exchange rate exists between no.pETH and pETH. However, a fee is charged by the SSP, such that the exchange rate between no.yETH and yETH is less than 1 (1 no.yETH redeems less than 1 yETH). Unbundling the asset may be useful in some places, but also introduces additional complexity which is not critical for the following sections, so we keep using soETH and noETH to represent the whole claim instead.

Another consideration is whether the SSP pools the ETH from its depositors or not.

1. No pooling: An SSP opens multiple, parallel pools, one for each depositor. Suppose depositors A and B provide their ETH to the SSP, which opens validators A and B, one for each depositor. Suppose then that validator A is slashed for half of its deposit, while validator B is not. In this case, depositor A may withdraw their ETH at stake at a rate 1:0.5 (1 share of noETH redeems 0.5 shares of ETH at stake), while depositor B may withdraw their ETH at a rate 1:1 (modulo fees). It is then incorrect to speak of a single noETH, as in practice there exists noETH-A and noETH-B which represent different claims.
2. Pooling: The Ethereum protocol requires units of 32 ETH to be placed at stake, which means that were depositors A and B keen to stake only 16 ETH each, they would not be able to do so with the construction detailed in the previous point. In this case, they would pool their ETH under some SSP, who would then socialise their rewards and losses, inducing the same withdrawal rate for both depositors. It is then well-formed to speak of a single noETH, since the value of the claim is shared by both depositors, proportional to the amount they deposited.

Liquefaction

Our depositors now hold a virtual asset we have called noETH. This virtual asset is a claim which represent shares of the current amount staked by the SSP under the Ethereum protocol. While this already sounds like a liquid version of the ETH position at stake, we wish to emphasise that an additional step is necessary to get there: liquefaction through the issuance of a token representing the claim to the noETH assets. The noETH position is rendered liquid, a.k.a., fungible and transferable. We write this operation with the operand L., so that the asset L.noETH is an abstraction for e.g., stETH or cbETH, or any other asset known as a Liquid Staking Token “LST”.

To make this apparent, we unbundle the functions of the SSP as protocol gathering stake from delegators, and the node operators providing the validation services for the SSP. We then obtain the following balance sheets:

When the SSP is simply a wrapper between some node operators and the delegator, the step of obtaining L.noETH from noETH is almost invisible given the nature of blockchains, where the “accounting asset” noETH, written out as a ledger entry, turns out to be the liquid asset L.noETH itself, programmable and ready to be composed. In other words, if we already have a token representing some noETH as a blockchain entry, noETH and L.noETH are indistinguishable. We wish to stress the difference anyways, since there exists cases where delegators do not have access to a liquid representation (from the blockchain’s point of view) of their asset at stake. For instance, in the past, depositors who staked their ETH with Coinbase did not receive from Coinbase the liquid cbETH asset. In this case, depositors were entitled to a virtual claim representing some line in the internal ledger entries of the Coinbase database, which were not written out on a blockchain.

Roles of the SSP

In many cases though, the SSP, seen as protocol, isn’t a simple wrapper, an on-chain contract receiving ETH and printing L.noETH in exchange. The SSP’s core function is to intermediate the relationship between a principal (the delegator) and agents (node operators). If the principal has no trust that the agents will provide them with adequate yield while protecting the assets of the principal, the principal will not delegate their assets to the node operators to stake on their behalf. How do SSPs provide good guarantees?

1. The first component is to incentivise good performance for node operators. Node operators receive more rewards from the Ethereum protocol the better they perform their validation services. Incentives are easily aligned by allowing node operators to share in the profits that they create for their delegators, via fees.
2. The second component is to discourage malicious parties from becoming node operators. We could assume that in the worst case, these malicious parties are intrinsically motivated to attack the Ethereum protocol and cause a large slashing event at minimum cost to themselves. Two approaches exist here. We could require operators to put something at stake, such that these attacks are as costly as possible to the operators. We could also constrain the node operators, preventing them from unilaterally performing slashable actions.

Pools such as Lido deal with the second issue by curating a set of node operators, such that the performance is guaranteed by the Lido protocol and DAO. Their operators have no ETH at stake, but @mikeneuder/magnitude-and-direction">external systems of enforcement (from soft ones such as “reputation-at-stake” to harder ones such as execution layer-triggered withdrawals as discussed in the second post) are intended to ensure their good behaviour.

Something-at-stake to discourage malicious operators

Meanwhile, constructions such as Rocket Pool incentivise honest validation by node operators who are neither verified nor employed by some organisation, contributing permissionlessly. The node operator opens a Minipool, first contributing their own stake, either 8 or 16 ETH. The protocol then tops up the node operator’s own stake with stake received from delegators. As a corollary, the Minipool operator’s yield on their own stake increases with their performance.

Note that the operator must also collateralise some amount of RPL, Rocket Pool’s token, proportional to how much stake they had to borrow from the pool of delegated ETH to top up their own Minipool. We do not show this in the following balance sheets, and we highlight some assets of the same type with different colours, to illustrate their provenance (green ETH belongs to the delegator, purple ETH belongs to the operator).

The lower the collateral posted by the operator, the greater the leveraged attack risk becomes, where the operator requires a small amount of funds to control a much larger amount of stake on the Ethereum Proof-of-Stake (PoS) network. For Lido, the leveraged attack risk is infinite considering purely on-chain assets put at stake by the operators, but obviously less than infinite considering their reputation, contracts, and expected future cash flows from honest validation. For Rocket Pool operators, e.g., those opening 8 ETH-collateralised Minipools, the leverage factor is 4x, as 8 ETH allows them to control 32 ETH of stake on the Ethereum PoS protocol. Can we require lower collateral from operators?

Constraining node operators

One way to reduce the risks of malicious validation further is to credibly commit the node operators to specific actions, e.g., commit them to never produce any slashable messages. Easier said than done!

Here, distributed validator technologies (DVT) may help, by ensuring all operator messages are checked and signed off on by a quorum of nodes before being released on the network with a valid signature. Diva, a staking protocol, integrates DVT to bound an operator’s actions. The operator must put at stake some divETH (Diva’s LST), namely an amount equivalent to 1 ETH to obtain one key share. A set of 16 key shares forms a quorum of DVT nodes, as well as a single virtual validator, as depicted below. We omit the Ethereum protocol, which simply issues the soETH claim in the last step and receives ETH collected from delegators and operators (green ETH belongs to the delegator, while purple and yellow ETH are provided by the operators). We also show only two operators instead of 16.

The calculation of the leverage factor for Diva is not so straightforward. Contributing 1 ETH-equivalent to the virtual validator does not “earn” you control of any amount of ETH currently at stake, since the joint actions of over 2/3rds of the quorum decide the virtual validator’s messages. Note however that the protocol allows the owner of a single ETH to become an operator and receive a noETH claim, redeeming yield obtained from Ethereum PoS validation.

Beyond the leverage factor, another metric is relevant here: the ratio between the amount of LSTs outstanding and the amount of operator stake, or collateral factor. A high ratio implies that a smaller amount of operator stake is collateralised to validate on behalf of a larger amount of delegator stake. For Rocket Pool, 8 ETH Minipools have a collateral factor equal to 3x, as 8 ETH collateralises 24 rETH in total. Meanwhile, the collateral factor of a Diva virtual validator is 1x, since 16 key shares (16 ETH) collateralise 16 divETH. A high collateral factor “makes room” for more stake to be delegated. Diva must then recruit more operator stake per unit of delegated stake to offer its services. On the upside, allowing operators who collateralise a single ETH expands the set of eligible operators to those with lower capital.

Liquid solo validating

From above, we have learned that the holders of an LST require the operators validating on their behalf to do a good job. This guaranty is either provided by external contracting in the case of Lido-type protocols, or by having the operator put their own capital at stake along with the capital of their delegators. The latter requires a sound game-theoretical model to ensure that the capital at stake by the operator isn’t so low as to enable cheap attacks and ultimately destroy the value of the LST for their holders.

We now ask a distinct question. The delegator obtains L.noETH from pooling stake and mediating the claims via a protocol issuing a liquid representation of the amount delegated, modulo rewards, penalties and fees. Can a delegator obtain L.soETH? In other words, could a single solo staker issue a liquid position from their validating position?

The issue here is that holders of the L.soETH asset must be confident that the value of their claim won’t be destroyed by a malicious action of the solo staker, e.g., getting slashed. We’ve already seen one approach, via DVTs, to restrict the operator’s actions during validation.

A different approach to DVT consists in binding the solo staker’s actions such that their own slashing risk is lowered by hardware construction. “Liquid solo validating” by Justin Drake employs SGX to ensure that the validator’s signing key never signs a slashable message. SGX allows pre-committed software to run free of tampering, though there are the usual caveats around its security, which are outside the scope of this piece. The solo staker provides the entire capital (32 ETH), yet is able to mint an LST representing their own validation and “freeing” their capital from the Ethereum protocol, to be used again, e.g., as collateral to other applications.

Line-by-line details:

1. The SGX device generates a private key, a public key, and an attestation proving commitment to a piece of code preventing the solo staker from performing slashable actions with their private signing key.
2. The attestation and public keys are provided to the solo staker.
3. The solo staker registers these with the LST contract deployed on-chain, which is responsible for minting the liquid solo validating asset. The solo staker also provides the contract with ETH, their stake.
4. The ETH is forwarded from the LST contract to the deposit contract, and a staking asset soETH is returned to the LST contract, who now filters the exit of the validator from the PoS protocol. The LST contract mints the L.soETH asset, which is a liquid representation of the ETH at stake from the staker.

The L.soETH asset is fungible with those minted by other solo stakers using the same procedure. By construction, the liquid solo staker is only able to mint 31 L.soETH out of their 32 ETH at stake. The extra 1 ETH is used as collateral to repay parties who permissionlessly liquidate the position when the solo staker’s balance goes under 32 ETH, and account for the frozen collateral while the validator sits in the queue after an exit. This ensures 1 L.soETH is always backed by 1 ETH.

What are the uses of the L.soETH asset?

1. The solo staker issuing L.soETH could use this L.soETH asset as collateral to other services. These services could consider that this is “good collateral”, since the only way for the solo staker to degrade its quality is to go offline and incur penalties (not slashing). By construction, the solo staker is however exited as soon as their soETH balance deviates by even a hundredth of an ETH from the 32 ETH starting balance.
2. The solo staker could also sell the L.soETH asset to other holders, receiving the proceeds. The L.soETH asset would need to be a productive asset itself, as described by Justin in the “Productive vs non-productive sETH” section of his post, where the L.soETH asset becomes a claim not only to the principal at stake but also to the rewards earned on the stake, e.g., consensus rewards and MEV (there are difficulties to internalise the MEV in a trust-minimised fashion).
   1. Note that selling the L.soETH asset does not give the solo staker extra leverage to launch an attack on Ethereum. Leverage is obtained by putting a small amount of funds at stake and controlling a larger amount in the PoS protocol. The SGX device however prevents the staker from performing slashable actions.

Conclusion of liquefaction

The following table summarises the 4 case studies discussed above:

Liquefaction is one way for a staker to extract “more juice” out of their collateral at stake. In the following post, we will discuss re-staking as a related alternative to create more assets out of one’s stake.

Disclaimer：

1. This article is reprinted from [mirror], All copyrights belong to the original author [The price of agency]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.