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.Photo by Robert Katzki on Unsplash.

Following our last post on liquid staking constructions, we are now talking about re-staking. We introduce re-staking with the use case of re-staking one’s own validating position, before generalising to re-staking any asset, which we’ll use in the third post of this series.

• Part 1: Liquefaction

• Part 2: Re-staking

• Part 3: Advanced construction sets for ages 16+

Let’s dive in!

Re-staking basics

Given some asset X, we denote by [X] the re-staked asset, i.e., an asset “boxing” X such that part or all of X may be captured by some party given some arbitrary condition.

The basic example introduced by EigenLayer is that of a solo staker re-staking their current ETH at stake. To do so, the solo staker updates their withdrawal address to the address of an EigenLayer pod. EigenPods are smart contracts that track which services the solo staker has signed up for to secure with their stake. The EigenPod ultimately becomes the owner of the soETH asset, while it credits the solo staker with a re-staked representation of their staked ETH.

Ownership of the soETH asset in our framework denotes “first right” over the ETH withdrawn from the Ethereum protocol, i.e., owns a more senior claim than any other participant in the chain. When the solo staker decides to withdraw their ETH from the Ethereum protocol, the withdrawn ETH is filtered through the EigenPod contract, checking whether the solo staker is allowed to redeem the whole amount of soETH or not (we’ll see later when this might not be the case). With our balance sheets:

We make each step explicit in the following:

1. The solo staker deposits their ETH to the Ethereum protocol, receiving a virtual soETH position from the Ethereum protocol.

2. The solo staker virtually deposits their soETH to EigenLayer by setting their withdrawal address to the EigenLayer pod’s address. In exchange, the solo staker receives a virtual position [soETH] from EigenLayer, which allows them to eventually run the order of operations backwards.

Balance imbalances

We can already make some interesting observations from the balance sheets above. The first is that the Ethereum protocol has no conception whatsoever of [soETH], since this is not appearing on its own balance sheet. This issue was discussed in “Unbundling PBS: Towards protocol-enforced proposer commitments (PEPC)”: A validator slashed by EigenLayer still has a full staking balance on the Ethereum protocol’s balance sheet, which may induce moral hazard and reward imbalances (an actually half-staked validator still earns full rewards from the Ethereum protocol). We detail the slashing scenario in the following balance sheets, giving arbitrary numbers to illustrate the issue:

This issue is fixed as soon as EigenLayer faithfully reports the EigenLayer-slashing of a validator to the Ethereum protocol, re-balancing the sheets. This is possible with EIP-7002: Execution layer triggerable exits, albeit at a coarse level, since the binary trigger simply exits the validator, but EigenLayer middleware or the EigenPod is still required to trigger the signal to the Ethereum PoS protocol. This action is in EigenLayer’s interests because proper accounting benefits the services that are secured via EigenLayer and also ultimately increases operators’ and re-stakers’ confidence in the faithful execution of the platform.

A finer trigger could force a partial withdrawal of the validator balance from the Ethereum consensus, without exiting the validator entirely. This is desirable for EigenLayer services who wish to penalise validators partially, without triggering an exit. Note that neither EIP-7002 nor execution layer-triggered partial withdrawals are available on Ethereum mainnet today. Note also that MaxEB (removing the 32 ETH cap on a single validator’s principal at stake) would combine nicely with partial withdrawals, removing an additional incentive for validators to stay dis-aggregated (running many 32 ETH-validators instead of a single 2048 ETH-validator for instance).

Lacking this partial withdrawal feature, there is an additional incentive to keep the EigenLayer accounting separate from the Ethereum protocol accounting, which as we noted above may introduce misalignments. In the following, we depict a validator slashed for 8 ETH by EigenLayer, which does not exit the validator from its consensus duties (the ejection balance is 16 ETH):

AVS claims

One may wonder where the 8 [soETH] go in the previous example. This decision is left up to the EigenLayer-powered Actively Validated Services (AVS). An AVS is a service demanding some stake as collateral. The presence of stake allows the service to make a credible commitment to some performance, as the stake may be slashed if the service is not performed properly.

The re-staking validator enrolls into AVSs via their EigenPod. When they do so, the EigenPod mints new claims which are offered to the AVSs, representing the collateral currently held under the EigenPod. We must now make the distinction between two types of claims:

• AVS claims: We use [soETH] to denote these claims, emphasising that they are derived from the value of the asset in brackets [ ].

• Re-staker claim: We will now use [soETH]* to emphasise the special quality of this claim, which is redeemed by the re-staker only after all AVS claims are settled. In other words, the re-staker’s claim has the lowest seniority, redeeming the assets remaining once all other AVS claims are settled.

1. The solo staker re-stakes.

   1. soETH is placed under control of the EigenPod.

   2. [soETH]* is received by the solo re-staker, a claim for their re-staked assets.

2. The solo staker mints a new claim, [soETH] from their EigenPod.

3. The claim is given as collateral to the AVS.

   1. [soETH] is transferred to the AVS.

   2. The re-staker is given the receipt avs.[soETH].

Once the validator acts contrary to the aims of the AVS (e.g., triggering a slashing condition of the AVS), the AVS may decide for instance to burn the validator’s claim for its ETH at stake, or to keep the stake as revenue to the AVS. We illustrate this second option in the following, by assuming that the Ethereum protocol simply credits 8 ETH to the EigenPod as a partial withdrawal following the EigenLayer-slashing report, after which EigenLayer transfers it to the AVS:

1. The AVS slashes the solo re-staker’s collateral.

   1. The AVS’s collateral consists of 32 [soETH]. Once the slashing is reported, the AVS removes 8 [soETH] from the collateral, and reports the slashing to the EigenPod, which also decreases its liabilities by 8 [soETH].

   2. The AVS no longer credits 32 avs.[soETH] to the solo re-staker, decreasing this claim by 8 avs.[soETH].

   3. Having been slashed by the AVS, the EigenPod decreases the claim of the solo re-staker by 8 [soETH]*.

2. The EigenPod reports the slashing to the Ethereum protocol, triggering the withdrawal of 8 ETH.

   1. The claim for assets at stake in the Ethereum protocol goes down to 24 soETH.

   2. A partial withdrawal for 8 ETH is processed, and the EigenPod receives the 8 ETH previously locked in the Ethereum protocol.

3. The EigenPod forwards the 8 ETH penalty to the AVS, which is free to dispose of it as it pleases.

Re-re-re-re-…-staking

The feature (and risk) offered by EigenLayer is the ability for a re-staker to keep entering new commitments which they promise to honour. In other words, after the stake is re-staked, the re-staked stake can be re-staked again, and again, and again… More practically, the re-staker enters new commitments by signing up to more services via their EigenPod.

To achieve full generality, and in anticipation of following sections where assets other than soETH are re-staked, we denote by $X$ the asset that is re-staked by the re-staker. Let’s see how re-staking multiple times works out:

We denote by $[X]^p$ the asset $X$ re-staked $p$ times. For now this is a simple definition, but we’ll hint at some of the properties of these assets after detailing the steps of these balance sheets. The EigenPod is able to print these liabilities at-will, forging new assets whenever the re-staker commits themselves to new AVSs.

1. The re-staker puts asset X under control of the EigenPod. This act is a commitment from the re-staker that should they fail to provide the services they sign up for, part or all of asset X may be taken from them. The claim [X]* is received to represent this commitment.

2. We detail here the re-staker committing to secure chain Y.

   1. The re-staker obtains a first re-staked asset [X]¹ by entering into the AVS “Securing chain Y”.

   2. The re-staker stakes [X]¹ under chain Y, receiving soY.[X]¹ (a claim for their stake + rewards - penalties). Chain Y must “understand” that a re-staked asset currently secures its protocol, i.e., it must be confident that there is something at stake for someone.

3. We detail here the re-staker committing to secure chain Z.

   1. The re-staker obtains a re-staked asset [X]² by entering into the AVS “Securing chain Z”.

   2. The re-staker stakes [X]² under chain Z, receiving soZ.[X]² (a claim for their stake + rewards - penalties). Chain Z must “understand” that a re-staked asset currently secures its protocol, i.e., it must be confident that there is something at stake for someone.

Based on the balance sheets above, we now address some questions. We observe that chain Y receives [X]¹, while chain Z receives [X]². Are these assets of the same type, and could we just say that they both receive assets of type [X]?

The answer would be no if there was a hierarchy of AVS claims. Imagine a scenario where the re-staker performs slashable offences on both chains at the same time, and both chains wish to slash the entire collateral. We can then think of two cases:

• Case 1: The AVSs, here chains Y and Z’s consensus mechanisms, simply burn the tokens that are slashed, which is what most PoS protocols do. When the tokens are burned, then the hierarchy of claims doesn’t really matter: If both chains Y and Z wanted to slash the re-staker for 32 ETH, all they accomplish is burn the same collateral twice.

  • Note: Anders calls this “spree-staking”, re-staking multiple times without claim hierarchy 😊

• Case 2: The AVSs want to receive the tokens that are at stake, to e.g., compensate some party that was wronged. An example here is MEV-Boost+, the AVS operator is the block proposer, who commits to not messing around with block contents received in the clear, and if they do, they commit to compensating the builder and the relay for the mess. In this case, suppose multiple AVSs redeem their claims at the same time following parallel deviations by the same re-staker, and there isn’t enough at stake to cover all the claims. Then the question of claim seniority or distribution of the payouts becomes relevant.

Unbundling AVSs

In the previous section, we’ve introduced AVSs, which are services the re-staking validator commits to providing. The commitment is secured via EigenLayer, which takes ownership of the validating re-staker’s stake and settles claims made by AVSs.

But what is an AVS exactly? Much like we have separated above the LST protocols and the LST operators, it makes sense here to discuss these two functional roles separately, and assign them different assets and claims.

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:

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

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

In the sections above, we have identified the validating re-staker as both the capital provider (their own stake is re-staked) and the AVS operator (they are themselves expected to provide some service). We can however consider a different construction, where the validating re-staker does not operate the AVS themselves, instead delegating this function to some operator. This could enable solo stakers to compete on yield with integrated Staking Service Providers (SSPs)/operators. The following example introduces a situation where a single AVS operator validates on some chains Y and Z, on behalf of a re-staker. We make the assumption that all AVS claims are of the same type [X] (no claim hierarchy).

1. The re-staker puts asset X under control of the EigenPod. This act is a commitment from the re-staker that should they fail to provide the services they sign up for, part or all of asset X may be taken from them. The claim [X]* is received to represent this commitment.

2. We detail here the re-staker committing to secure chain Y, delegating the validation duties to the AVS operator.

   1. The re-staker obtains a re-staked asset [X] by entering into the AVS “Securing chain Y”.

   2. The re-staker gives the re-staked asset [X] to an AVS operator, obtaining the “receipt” noY.[X].

   3. AVS operator stakes [X] under chain Y, receiving soY.[X] (a claim for their stake + rewards - penalties). Chain Y must “understand” that a re-staked asset currently secures its protocol, i.e., it must be confident that there is something at stake for someone.

3. We detail here the re-staker committing to secure chain Z, delegating the validation duties to the AVS operator.

   1. The re-staker obtains a re-staked asset [X] by entering into the AVS “Securing chain Y”.

   2. The re-staker gives the re-staked asset [X] to an AVS operator, obtaining the “receipt” noZ.[X].

   3. AVS operator stakes [X] under chain Z, receiving soZ.[X] (a claim for their stake + rewards - penalties). Chain Z must “understand” that a re-staked asset currently secures its protocol, i.e., it must be confident that there is something at stake for someone.

In this paradigm, we recover familiar constructions. An no asset is received by the re-staker, already hinting at the possibility of liquefying such positions. We will discuss these advanced constructions in the next post, but before doing so, let us mention ongoing research on “PBS for AVS” as an approach to reduce operator centralisation.

Under the Optimistic Delegation Framework (ODF) proposed by Drew Van der Werff (see also 0xKydo’s recent Columbia Cryptoeconomics workshop talk), a re-staker is able to contract the operation of the AVSs it signs up for in an open market of “co-processors”. Co-processors can be identified with the “builder” role of PBS, a specialised entity able to run potentially intensive operations, which are inaccessible to unsophisticated or compute-limited entities such as solo stakers. Co-processors submit bids to re-stakers, in a procurement auction-style mechanism, allowing the re-staker to determine the most profitable operator. To further guarantee performance, co-processors are bonded participants, opening themselves to losing their bond if they submit a provably invalid piece of work during the course of their operations.