Semantics of Staking 3: Advanced Constructions

*Forward the Original Title：Semantics of Staking 3: Advanced Constructions

Many thanks to Anders Elowsson for initial discussions prompting these series of posts and for his many helpful comments on the text. Thank you also to the many reviewers whom I have bothered too much with this, and who have provided comments on previous posts or parts of the current one. Photo by @william_priess?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash">William Priess on Unsplash.

We have now laid out the pieces which make up our current game of asset Legos. It is time to put them together and see what we can obtain!

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

L.[noETH]: Native SSP re-staking (“LRTs”)

The first construction considers an SSP re-staking the stake currently under its control. In this case, the node operators of the SSP set their withdrawal addresses to some EigenPod, which binds them to commitments entered into with AVS. This leads to the creation of an asset, L.[noETH], representing a claim on a re-staked Ethereum protocol collateral. In the following, we depict the creation of this asset, which we could first call L.avs.[noETH] to emphasise that the asset also embodies a claim for revenues received from some AVS. However, we can shorten the notation to simply L.[noETH] when the AVS (or set of AVS) entered into by the operators is clear.

In the case depicted above, there is a transparent transformation of the L.noETH held by the staker into L.[noETH], under the assumption that the SSP does not keep secret the proceeds received from its re-staking activities for itself. Given that everything is written out on-chain, it would be very easy to detect whether an SSP re-staked the ETH under its custody while keeping the yield received from AVS for itself, as long as the SSP transparently reveals which validators it operates. One may imagine a scenario where the SSP enters an off-chain agreement with some AVS, in which case the sequence depicted above looks more like:

As can now be seen from the balance sheets, [noETH] (restaked node operator stake) essentially now backs L.noETH (liquid node operator stake). From a distributional perspective, it is an issue that staker capital deployed to the SSP earns yield while the stakers themselves are not remunerated for it, but at least L.noETH is fully backed by [noETH] in the ideal case. It is a lot more problematic whenever [noETH] does fully back L.noETH, e.g., if the SSP did something slashable according to some AVS they entered a commitment with, in which case the value of [noETH] no longer matches the (staker-expected) value of L.noETH.

[L.noETH]: “Re-staked” LSTs

From its inception, EigenLayer has allowed an LST holder to deposit their LST and place them at stake under some EigenLayer pod (note that we use LST to denote L.noETH, in an attempt to leverage pre-existing intuition). While this seems equivalent to the construction detailed above, the nuances are revealed by the balance sheet view:

The notation makes it clear that there is a difference between the “re-staked” LST we obtain here, [L.noETH], and the liquid SSP native re-staking position L.[noETH]. But what is this difference exactly? The easiest way to grasp it in our opinion is to unpack how the AVS service is provided, and who is ultimately responsible for the provision of the service.

Let us start with [L.noETH]. A token representing a claim on some liquid staked ETH is once again put at stake (”re-staked”, in quotes because while the ETH underlying the LST is indeed re-staked, the LST itself is staked for the first time around). Staking the LST at EigenLayer does not force the SSP issuing the LST to engage in service provision for AVS chosen by the LST holder. Indeed, see above that the balance sheet of the SSP is virtually unchanged, as it has no idea that its tokens are staked under EigenLayer. So who does the LST staking concern?

We’ve discussed the following in our second post:

In short, the AVS demands collateral to offer a service, e.g., an AVS makes the credible claim that an attack on the AVS will lead to the loss of some fraction of the collateral currently held by the AVS. The AVS is thus seen here as a protocol engaging operators for a service. We then disambiguate two ways that re-stakers may interact with the AVS:

1. Re-stakers as AVS operators: The AVS embodies a protocol which seeks operators to function, and node operators who re-stake their soETH become operators for the AVS protocol themselves.
2. Re-stakers as capital providers for an AVS operator: In this case, an AVS operator accepts (re-)staked assets to perform their operator function on behalf of the delegators providing the capital. The re-staker then delegates their re-staked assets to the AVS operator, who performs some function on behalf of the re-staker.

LST “re-stakers” are likely simple capital providers. Part of the reason for holding the LST in the first place is to access staking yield without doing the costly work of validation for the Ethereum Proof-of-Stake service. An LST holder who stakes their LST to some AVS may not then be expected to run potentially complex operations and be the AVS operator themselves.

Let us represent the relationships in the following balance sheets, omitting the Ethereum protocol and the SSP for lack of space. Upon receiving the LST from the staker, EigenLayer provides the staker with its claim [L.noETH]. The LST is then transferred from EigenLayer to the AVS operator, who stakes it in this example under chain Y.

1. LST “re-staker” places their LST in their EigenPod.
2. LST “re-staker” re-stakes, receiving the [L.noETH] asset. The re-staked asset is delegated to the AVS operator, to operate on the LST “re-staker”’s behalf.
3. AVS operator places the re-staked asset [L.noETH] under chain Y. AVS operator receives the claim for assets locked and received during validation of chain Y, i.e., soY.[L.noETH].
4. AVS operator returns a claim to this re-staked asset, noY.[L.noETH] to the LST “re-staker”.

OK, that name soY.[L.noETH] is a mouthful. By soY, we mean that the asset at stake under Secured Chain Y is in a “solo-staking” relationship with Chain Y, i.e., the AVS operator putting [L.noETH] at stake under Chain Y acts like a solo operator from the perspective of Chain Y. What we observe then is that the asset held by the “re-staking” LST holder, noY.[L.noETH], is a claim on soY.[L.noETH], which may grow in value as Secured Chain Y rewards the validation services of the AVS operator. The AVS operator then passes this yield (minus fees to cover its operating costs) to the holders of noY.[L.noETH].

Notice that the soY asset has changed location between this series of balance sheets and the previous section’s. While the SSP was assuming the role of validator to Secured Chain Y, becoming the AVS operator itself, a new AVS operator is now responsible for the validation services under the “re-staked” LST configuration.

From a cash flow perspective, in a competitive environment with marginal fees, the staker should see no difference between staking their LST with some AVS taking on the validation services, and holding some LST based on collateral re-staked by the SSP. Yet the ownership of the soY asset denotes further centralisation of the SSP role in the second case, who now assumes node operator duties for two domains. The presence of two logically distinct entities in the LST “re-staking” case (the SSP providing the LST, and the AVS performing validation services) may be a greater force for decentralisation (see Anders’ forthcoming post on the subject).

[ETH]: “Re-staked” ETH

This is maybe a simpler case derived from the construction of a “re-staked” LST as detailed in the previous section. Instead of “re-staking” an LST, an ETH holder could simply place their ETH in some EigenPod, and use it as collateral for a variety of services including securing outside domains. In this case:

1. ETH “re-staker” places their ETH in their EigenPod, receiving the [ETH]* asset.
2. ETH “re-staker” re-stakes, receiving the [ETH] asset. The re-staked asset is delegated to the AVS operator, to operate on the ETH “re-staker”’s behalf.
3. AVS operator places the re-staked asset [ETH] under chain Y. AVS operator receives the claim for assets locked and received during validation of chain Y, i.e., soY.[ETH].
4. AVS operator returns a claim to this re-staked asset, noY.[ETH] to the ETH “re-staker”.

Suppose a single re-staked asset [ETH] is minted from the EigenPod, i.e., the ETH is used to secure only a single AVS. Suppose this AVS is the Ethereum protocol itself. Then we observe that the situation described here and the one described in Protocol staking are isomorphic. Indeed, if chain Y was the Ethereum PoS protocol, we would be simply describing here the act of committing one’s ETH assets to securing the Ethereum chain.

L.[soETH]? Liquid solo re-staking

This case appears to be well-formed according to our semantics, yet poses issues similar to the liquid solo staking case of L.soETH. In this construction, a solo staker re-stakes their soETH with some AVS. The AVS then attempts to create a fungible position out of the validating service backed by the solo staker’s re-staked collateral. This fungible position can be offered back to the solo staker, so that identically to the case where the solo staker does not wish to have their stake “locked” in some pool without a liquid representation for it, the solo staker’s [soETH] position may be used as collateral or sold elsewhere under the shape of L.[soETH].

Yet without guarantees on the solo staker’s behaviour, moral hazard will come into play once again, where the solo staker no longer bears the full risk of their actions. In Liquid solo validating, we discussed two use cases for a liquid representation of the solo staker’s position:

1. The solo staker could re-use the L.soETH to collateralise DeFi applications.
2. The solo staker could sell the L.soETH asset.

In either case, it is important for holders of the L.soETH asset to believe that they hold a valuable asset. The value is guaranteed by trusted node operators or incentivised node operators in the respective cases of Lido and Rocket Pool, for instance, and by committing to use an SGX device preventing the solo staker from performing slashable actions in the liquid solo validating case. To get the same guarantee for L.[soETH] assets, a solo staker could commit to use an SGX which prevents the validator from performing slashable actions also on the AVS that they have signed up for. The LST contract which minted the L.soETH asset could also embody the role of the EigenPod, registering the commitments entered into by the staker with AVS.

In the following, the solo staker binds themselves to an SGX device which must be involved whenever the solo staker wishes to produce a signed message for their validating duties on chain Y.

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.
5. The LST contract mints a new re-staked asset [soETH] from the staked ETH it owns, committing it to an AVS securing chain Y. The LST contract then receives the claim soY.[soETH] from chain Y.
6. The LST contract mints the L.soETH asset, which is a liquid representation of the ETH at stake from the staker.

L.[L.noETH]: Liquid basket of AVS

Here, an aggregator receiving LSTs (L.noETH) from various holders makes a fungible position out of all of them after they are “re-staked” into various AVS. This case is quite similar to the one described in the previous section on [L.noETH] assets, and just goes the extra step of making the pooled and “re-staked” LSTs available once again as a token. This is also a similar move as described from the shift between noETH and L.noETH, detailed in Liquefaction.

Denoting this construction with balance sheets, this is indeed similar to the “Re-staked” LSTs, with the additional LST aggregator role intermediating the relationship between EigenLayer and the LST “re-staker”.

1. The LST holder gives their LST to an aggregator, who locks it up in their EigenPod.
2. The aggregator issues a re-staked asset from the LST, [L.noETH], via their EigenPod. The re-staked asset is given to chain Y, where an AVS operator runs validation duties on behalf of the aggregator. The AVS operator receives the staking asset of chain Y, soY.[L.noETH], and issues a receipt for the LST aggregator, noY.[L.noETH].
3. The aggregator issues a liquid position L.noY.[L.noETH] to the LST holder, denoting that this position is a liquid representation of the aggregator securing Y and passing on the yield to the LST holder (minus fees and potential penalties).

Things get dicey when the LST aggregator decides to opt-in to a new AVS, securing chain Z. We then write L.[L.noETH] to indicate that the aggregator has liquefied a position made up of a bundle of re-staking assets, so that L.[L.noETH] = L.noY.[L.noETH] in the special case where the aggregator only liquefied the re-staked asset securing chain Y.

1. The LST holder gives their LST to an aggregator, who locks it up in their EigenPod.
2. The aggregator issues a re-staked asset from the LST, [L.noETH], via their EigenPod. The re-staked asset is given to chain Y, where an AVS operator runs validation duties on behalf of the aggregator. The AVS operator receives the staking asset of chain Y, soY.[L.noETH].
3. The aggregator issues a re-staked asset from the LST, [L.noETH], via their EigenPod. The re-staked asset is given to chain Z, where an AVS operator runs validation duties on behalf of the aggregator. The AVS operator receives the staking asset of chain Z, soZ.[L.noETH].
4. The aggregator receives claims from the operator for the assets at stake on chains Y and Z, noY and noZ.[L.noETH]. Based on these assets, the aggregator issues a liquid position L.[L.noETH] to the LST holder, denoting that this position is a liquid representation of the aggregator’s commitments to various AVS, passing on the total yield to the LST holder (minus fees and potential penalties).

These baskets of AVS constructions may be profitable for re-stakers to enter into, as the risk of managing a portfolio of dynamic commitments to multiple AVS is abstracted away from the re-staker. The diversification of the portfolio may further allow a reduction of systemic risk, as long as the management of the portfolio is done transparently.

Conclusion

It appears then that past a certain point, the operations become isomorphic to one another, so there is no need to keep piling up the asset Legos. The important point is to remain clear on which party ultimately owns control of the assets backing various services including consensus mechanisms. We hope that unpacking the sometimes complex relationships between all parties involved focusses our attention on the right spots.

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.