EIP-1559 introduced a new fee market in August 2021, where a user is able to set two parameters with their transactions:

• maxFeePerGas, denoting their highest willingness to pay per unit of gas.

• maxPriorityFeePerGas, denoting a “tip” accruing to the producer of the block.

EIP-1559 is also characterised by the introduction of a baseFeePerGas, a minimum price per unit of gas which the transaction must incur to be included. The baseFeePerGas is updated dynamically, according to the demand for inclusion, as measured by block fullness.

According to the analysis by Tim Roughgarden, in most cases when the chain is not congested and there is enough room to include all transactions that pay at least the base fee, a user should set their maxPriorityFeePerGas to some value μ which compensates the block producer for the cost of including an extra unit of gas to their block.

Gas opportunity cost in Proof-of-Work

In Proof-of-Work, a block producer indeed incurred such a cost. Adding an extra unit of gas translates to extra block size (in bytes) and thus longer propagation time over the network. This longer propagation time meant that a miner who solves the PoW puzzle could be “front-run” by another successful miner with a lighter block. Thus a miner ought to require at least the opportunity cost of adding extra weight to their block.

This opportunity cost was estimated in this note among others. The calculation gets a bit tricky accounting for possible MEV in the block (more on this in the following), but lands at roughly 1 Gwei as a good value that the block producer should demand to compensate for the extra orphaning risk (assuming no MEV).

In practice, clients such as Geth would set a “minimum priority fee” parameter, and would not include transactions which pay them a lower (effective) priority fee than this minimum.

Transaction opportunity cost in Proof-of-Stake

The move to Proof-of-Stake proceeded in September 2022, a year after EIP-1559 was deployed. In PoS, the block production schedule is quite different. Instead of multiple miners competing at the same time to find a PoW puzzle solution that will allow them to produce the next block, a single validator is given a window of time to produce their block, at t = 0 seconds at the start of a 12-second slot. Attesters ensure the timeliness. Attesters will wait for 4 seconds to receive a block, after which they will vote as if the block was missing. In other words, the validator has now 4 seconds to propagate their block on their network, without fear of anyone front-running them.

In this case, what does the priority fee pay for, when there is no congestion to enter the block? It is quite unclear, since there is no reason for the validator to not include an extra transaction as long as it pays them something. A validator could set their minimum priority fee to any value they desire of course, but could find themselves in situations where they drop transactions from their produced block for no good reason, as the following example shows:

Suppose Alice the block producer sets her minimum priority fee to 1 Gwei, the default value under Proof-of-Work. If Bob the user sent a transaction paying Alice 0.5 Gwei priority fee, Alice would not include it, even when including it would not hurt her chances of landing her block in time. Alice simply foregoes 0.5 Gwei per gas which Bob’s transaction uses. This is an argument for Alice to set her minimum priority fee as low as possible, as long as she can ensure to be timely, which the 4 seconds in principle give her plenty of time to be.

The same dynamics were observed by Péter here:

Péter Szilágyi

@peter_szilagyi

The #Ethereum ecosystem seems to be gravitating towards 0 miner tips.

Geth fixing it's minimum tip enforcement to 1 gwei caused some outrage; blobs do not tip miners at all; and multi-dimentional gas might also not.

I'm worried this again favours MEV.

github.com

Execution Layer Meeting 188 · Issue #1043 · ethereum/pm

Meeting Info May 23, 2024, 14:00-15:30 UTC Stream: https://youtube.com/live/jO-BbmSsT_0 Zoom: shared on #allcoredevs Discord channel shortly before the call Ethereum Protocol Calls Calendar subscri...

118

7:18 AM • May 15, 2024

MEV, PBS and timing games

But yep, things are never so simple of course, and with the emergence of timing games (paper), we’ve observed that block producers would rather not be early in sending their blocks to the network, instead waiting as late as possible in these 4 seconds to accumulate more transactions and publish a more valuable block. Further, the intermediation of block proposing and building with MEV-Boost adds another layer to this game, which we describe below.

In MEV-Boost, a validator is able to receive offers from builders, who take care of sequencing the execution payload against a fee paid to the validator (known here as “proposer”). In this setting, the builder is the “block producer”, and thus is the entity who is responsible for deciding whether a transaction should be included or not.

Is the “minimum priority fee” relevant for a builder? The builder is assumed to be a fairly sophisticated entity, an “active block producer” in the language of “Transaction Fee Mechanism Design in a Post-MEV World” (Bahrani et al., 2024), which chooses to include transactions based on their capacity to offer them MEV. We may readily consider priority fees offered by users through their maxPriorityFeePerGas parameter as MEV, as it is indeed value received by the “miner”. But again, should a builder set some kind of minimum priority fee to filter which transactions to include in their block?

I argue that it is unnecessary. A builder may wish to include a transaction paying 0 maxPriorityFeePerGas, if the builder is able to extract value from this transaction. The builder, as a sophisticated entity, would be perfectly able to decide which transactions are meaningful to them to include.

While this argument may hold, this does not tell us what a user should set their priority fee to. Should it be zero? This is where timing games come into play. If a block proposer wishes to play timing games, the transaction must compensate the proposer for the extra propagation time which the block will require, and which would force the proposer to forego extra MEV from delaying their proposal a little longer and play the timing game. In other words, if x dollars of includable MEV accumulate per unit of time, and adding some transaction forces the proposer to propose t units of time earlier in order to make the 4-second deadline, then the proposer should expect at least t * x dollars from the transaction as priority fees to compensate for the extra delay which the transaction imposes. All of this however is on the user to set, and not relevant to the minimum priority fee parameter.

Suppose a validator does not connect to MEV-Boost, and builds their block locally instead. There are now two cases:

• The validator does not play timing games: This is then the case described in the section above, where the validator ought to set their minimum priority fee parameter low enough to not reject transactions for no reason.

• The validator plays timing games: In this case, the validator will wish to demand more fees from transactions to compensate them for the extra propagation time which prevents them from playing the timing game further. Mediating this demand with the minimum priority fee is however tricky, as the minimum priority fee ought to be dynamic and estimate x, i.e., the ambient measure of how much MEV accumulates per unit of time. I don’t believe Geth developers or other EL clients need to consider this case, as a validator playing timing games on their own may be considered sophisticated enough to be able to set their minimum priority fee themselves.

Wat do

In my opinion, clients should set their minimum priority fee parameter to a residual value, possibly 0. The priority fee pays for priority when the chain is congested, in which case the minimum priority fee is not relevant. When the chain is not congested, the minimum priority fee ought to compensate for some cost which the block producer incurs for including a transaction in their block. In Proof-of-Work, this cost was well-founded, and induced by the race to publish one’s block first when successful. In Proof-of-Stake, the minimum priority fee may be relevant in the context of timing games, but not so in the context of builders who decide which transactions to include.

I would also argue that 0 miner tips do not “favor MEV”. They are a natural consequence of market forces pushing them down, as the example above showed. These minimum fees were reasonable in Proof-of-Work, where the miner incurred a real opportunity cost from including an extra transaction due to orphan risk. They may be reasonable in the context of timing games again, where a block producer must be compensated for forfeiting potentially more value than they could obtain by delaying a bit longer. But it is not reasonable to “pay miners for their service”, if this cost does not represent any tangible, economic phenomenon, as is the case in Proof-of-Stake without timing games. In fact, for the block proposer to demand a minimum fee where this minimum fee is not required for proper network functioning is MEV, i.e., a rent which the proposer obtains at the expense of the user or the network more generally. It is therefore reasonable to deprecate the minimum priority fee if it does not help convey a real cost which the proposer must be compensated for.

The protocol had aims, wanted to achieve lots. But first, it had to recruit disciples who would execute its vision.

The protocol created rights and assigned them to earthly entities, such that these “validators” could propose blocks and attest to them.

In this piece, we are not concerned with attesting (for now), and we’ll narrow our attention to proposing rights.

The proposing rights allow a validator, once selected, to create and propose a block. The block contains both consensus data (e.g., attestations), as well as an execution payload (a list of user transactions). When the validator receives the proposing right, it receives implicitly the right to decide the contents of both attributes, consensus data and execution payload.

MEV-Boost enters

Validators soon figured out that the ability to decide on the contents of the execution payload had value. They could remain the proposers, but create building rights to be allocated to builders, who would offer them a well-sequenced payload against payment.

The allocation of building rights is performed today with MEV-Boost, an out-of-protocol side-car allowing validators to passively listen to offers from builders for their building rights, and strike a deal with builders. The deal is mediated by relays, entities trusted by both sides of the deal.

Block-auction ePBS

What the protocol cannot see, it cannot control, so the community soon got to work on getting some of that infrastructure back into the fold of their protocol. This direction is known as “enshrined Proposer-Builder Separation”, and would allow proposers (validators) to strike deals with builders without the assistance of the relay as a trusted entity. In particular, the aims of ePBS are three-fold:

1. Possibility of unconditional payment: If the proposer commits to a builder bid in time (the commitment is attested to by the attesters, becomes canonical and does not get re-orged), then the proposer receives payment from the builder whether the builder delivers their part or not.

2. Possibility of trust-minimised proposer/builder interaction: The protocol offers a path, secured by its set of attesters and the fork choice rules of the protocol, for proposers and builders to strike deals without the aid of a relay.

3. Consensus/execution separation: Decoupling the consensus data from the execution payload in two distinct objects recognised by the protocol allows consensus data to be written on-chain even in the event of a delivery failure of the execution payload.

I present above “Block-auction ePBS”, the ePBS version which most directly maps to MEV-Boost. The “block-auction” refers to the requirement for the beacon proposer (the validator, who proposes the partial block containing consensus data) to commit to the contents of the execution payload when they commit to a builder. In other words, the proposer receives builder protocol-bids, which take the form of PB = { value, builderID, txroot } (note that we omit signatures from these messages, but these and more which will be introduced below are all assumed to be signed by the right parties).

When the beacon block is produced and contains PB, the fork choice will only accept an execution payload whose contents hash to PB.txroot. In this sense, the beacon proposer remains the true execution proposer (“beacon-exec proposer”), who earns the rewards received from the builder and who ultimately signs off on the the contents which are to be appended to the chain. The protocol-bids are objects legible to the Ethereum protocol, and commit a builder to deliver the block which the beacon-exec proposer has commissioned. You can read more about design constraints and implementation concerns in the rich literature from the Prysm boyz Potuz and Terence (ePBS specification notes, ePBS Forkchoice annotated spec, Block-auction ePBS versus Execution Tickets).

This version of ePBS satisfies points 1. to 3. Yet, importantly, point 2. must not be understood as making relays obsolete somehow. It remains entirely possible for beacon-exec proposers to participate in the trusted MEV-Boost market in the following way:

• Listen to MEV-Boost-bids from builders through the MEV-Boost channel.

• Choose a bid MB = { value, builderID, txroot }.

• Commit to the protocol bid PB = { 0, MB.builderID, MB.txroot }

• Receive MB.value as part of the execution payload, the way it is done today under MEV-Boost, with relays ensuring that the builder does include a valid payment for MB.value in the payload they sequence.

• The builder MB.builderID then delivers the execution payload hashing to MB.txroot. If they fail to do so, the beacon proposer does not receive payment.

We thus stress here that points 1. and 2. of ePBS only embody possibilities of transacting in a trust-minimised fashion with builders, rather than requirements. The natural question is then to understand when would proposers choose to use the trusted, out-of-protocol MEV-Boost interaction. One reason to keep using MEV-Boost instead of the honest ePBS behaviour: Builders are not required to commit to a payment upfront in MEV-Boost, compared to ePBS, meaning that builders may pay the beacon proposer from the gains they realise within the payload they sequence. See also Terence’s “ePBS: Bypassing Relayer” post for more thoughts on the topic.

A final point on block-auction ePBS: Timing games. Timing games occur when a proposer delays as much as possible the proposing of their block in order to obtain more value for it. In block-auction ePBS, as the execution payloads are determined at the release of the beacon block, the timing games will be played by validators who will attempt to delay the release of the beacon block as much as possible to commit to bids of higher value. This clues us in to the fact that we’ve not decoupled the consensus and the execution as much as we could, so let’s investigate a different design.

Slot-auction ePBS

Slot-auction ePBS makes a subtle design change, with big consequences. Beacon proposers may now commit to protocol-bids taking the shape of SPB = { value, exectutionProposerID }, so no longer committing to the contents of the execution payload, but committing to a specific execution proposer instead. The contents of the block released in the second step may be determined just in-time by the execution proposer, who is sovereign in their step. The execution proposer is even able to offer building rights to a distinct entity from themselves, a builder commissioned to deliver a block whose commitment is selected by the execution proposer.

The execution proposer will likely wish to wait until the last possible moment to propose the execution payload, so we assume timing games will be played in the execution step.

It is less clear what will happen during the beacon step. To understand, we introduce SA-MEV-Boost, a slot-auction-friendly version of MEV-Boost which offers to the beacon proposer off-band bids SMB = { value, executionProposerID }. The beacon proposer running SA-MEV-Boost may select some bid SMB, and commit to the protocol bid SPB = { 0, executionProposerID }. The execution proposer executionProposerID is then trusted to produce an execution payload that pays out SMB.value to the beacon proposer, yet, unlike MEV-Boost, there is no relay at this point vouching for the payment existing. The relationship between the beacon proposer and the execution proposer under SA-MEV-Boost may thus be mediated in a similar fashion to optimistic relays in ePBS: Someone, e.g., an escrow-relay, may guarantee the availability of funds to pay the beacon proposer SMB.value is any outcome, but the escrow-relay is not responsible for the delivery of the execution payload once available.

Once the execution proposer executionProposerID is selected, this proposer may use the classic MEV-Boost infrastructure to allocate building rights to an outside builder. The relays on this side function as relays do in the current version of ePBS, i.e., combine the functions of escrow-relay (if optimistic) and delivery of the payload. When both SA-MEV-Boost and MEV-Boost were summoned, the delivered payload should contain a payment from the builder to the execution proposer, as well as a separate payment from the execution proposer to the beacon proposer.

The beacon proposer is faced with the following decision tree:

Listen to bids (protocol or SA-MEV-Boost) and either:

1. Commit to themselves as execution proposer. Listen to (MEV-Boost) builder bids and

   1. Select the highest MEV-Boost-bid they receive, or

   2. Build locally.

2. Commit to someone else as execution proposer. Receive the value either from the unconditional payment protocol facility or from SA-MEV-Boost guarantees.

It appears to me that the expected value for the beacon proposer is maximised by choosing to commit to themselves first, and then running MEV-Boost to obtain the best offer from an outside builder. The auction for execution rights offers a valuable good: The knowledge that one is in control of proposing the execution payload, which may be leveraged by preconfirmation systems. However, between the settlement of the auction allocating execution proposing rights and the expected delivery of the execution payload, more transactions may trickle in and increase the value which a builder may extract from sequencing. By committing to themselves, the beacon proposer may become the “preconfirmation leader”, to whom tips are paid for the service of preconfirming. The preconfirmed transactions may then be sequenced according to the commitments offered by the beacon proposer, using e.g., PEPC-Boost (“relay-enforced proposer commitments”, see also the bonus section at the end) to ensure that the builder delivers an execution payload satisfying the preconfirmations entered into by the beacon proposer.

Still, the discussion above makes it quite clear that we expect quite a lot of involvement from the beacon proposer into the make-up of the execution payload, and if it is indeed a dominant strategy for the beacon proposer to commit to themselves and run MEV-Boost in the last-mile to allocate building rights, we haven’t gained much either in terms of diminishing the system’s reliance on relays. Yet slot-auction ePBS may function as an intermediate step towards total decoupling. We need another intermediate step before getting there, so let’s introduce it next.

Slot-auction+32 ePBS

We suggest now to let the beacon proposer of slot N determine the execution proposer of slot N+32, i.e., run a Slot-auction+32 ePBS. While this may seem like a strange construction, we intend here to decouple further the ties between the beacon proposer and the execution proposer of a given slot. In particular, this construction allows spot inclusion lists, created by the beacon proposer of slot N and binding the execution proposer of slot N (the latter being decided by the beacon proposer of slot N-32).

Despite this, we may very well still be in a scenario where it is a dominant strategy for the beacon proposer of slot N to commit to themselves as execution proposer for slot N+32, so we’re not done with our decoupling. In particular, the beacon proposers still receive all of the value to be obtained from being in control of the allocation of execution proposing rights. The thrust behind Execution Tickets (ETs) is indeed to completely remove this dependency, and while the design we arrive at isn’t exactly ETs, we will argue that it achieves this goal too. Let’s move on to this construction.

Execution Auctions (f.k.a. APS-Burn)

We suggest now a construction similar to MEV-Burn, except applied to the beacon proposer of slot N deciding which bid to commit to, where the bids are made for the execution proposing rights of slot N+32. This construction, Execution Auction, implements the concept of “Attester-Proposer Separation”, introduced by Justin Drake at Columbia Cryptoeconomics 2023. As argued in my previous post Reconsidering the market structure of PBS, APS may be understood as the market structure decoupling the roles of attesting/validating and proposing execution blocks, with ETs embodying a specific allocation mechanism realising this market structure. Execution Auction is an allocation mechanism too, a separate proposal from Execution Tickets which may offer some advantages as discussed below.

Attesters of slot N observe the bids made to purchase the execution proposing rights of slot N+32. The beacon proposer is expected to commit to the highest bid they have seen, while attesters vote for the beacon block only if the committed bid is consistent with the highest bids observed by the attesters.

MEV-Burn as presented in the past, where the beacon proposer of slot N commits to a bid for the allocation of the execution proposing rights of slot N, had in my sense two fairly fatal issues:

1. The value-in-flight issue: Beacon proposers and attesters were aiming to come to consensus over the value of an object whose value was drastically varying while the consensus was attempted. Indeed, transactions to be included in the execution payload of slot N trickle in during the auction, and prices on CEXes also vary at the same time, leading to a high variance of the value which the auction is trying to elicit. The design relying on slot auctions run 32 slots in advance ensures that a very small amount of information is relevant at the time of the auction to estimate the value which the execution payload may eventually return, so it looks more like a bet on the average.

2. The long-lived preconfirmation issue: Forcing the beacon proposer to select the highest bid offered for the execution proposing rights of the same slot also means that it is impossible to offer long-lived preconfirmations, which are committed to before slot N. If same-slot MEV-Burn was offered as a slot auction instead of a block auction, it would remain possible for the winning execution proposer to offer short-lived preconfirmations, committed to between the settlement of the allocation of the execution proposing rights and the ultimate delivery of the execution payload. With Execution Auctions, the winner of the execution proposing rights has 32 slots before their turn comes to propose the execution payload, and may offer long-lived preconfirmations in the meantime.

Execution Auctions offer an alternative allocation mechanism to ETs for the market structure of validator-proposer separation. In my sense, this shape of the allocation mechanism may make more sense than the format offered by ETs, but let’s quickly (re-)introduce ETs first before making that case.

Execution Tickets (ETs)

Suggested by Justin Drake and Mike Neuder, ETs allow execution proposers to go to a market where they purchase “tickets” redeeming execution proposing rights at some indeterminate time into the future.

Another way to put it is the protocol endowing some new, abstract module referred to as “ET market” with the execution proposing rights. These rights are purchased from the ET market by execution proposers. However, questions remain on how exactly should these rights be purchased. In particular, it is not clear to me whether beacon proposers should be responsible for including ET market-related transactions on-chain, or whether execution proposers should have this responsibility. One may imagine the inclusion of ET market-related transactions to possibly induce MEV, whether these transactions are included in the beacon block or in the execution payload. This risk appears to be mitigated by Execution Auctions.

Another possible benefit of Execution Auctions is the deterministic redemption period, e.g., 32 slots. ETs redeem at some random time in the future, which helps with mixing in case a single execution proposer is able to capture a set of tickets sequentially, but creates more variance for the ticket holder, likely to be reflected in the ticket price which the protocol captures. It would be possible to make ETs redeem at some deterministic time into the future though, but then one may want to think about designing for the case where an execution proposer is able to acquire many consecutive tickets. Meanwhile, Execution Auctions enforce a new competition for every slot.

In either case, ET or Execution Auctions, I believe measures should be considered to prevent toxic multi-block MEV from perturbing the liveness of the chain, when a single execution proposer is in control of several consecutive slots. Toxic multi-block MEV appears to mostly come from the proposer “freezing” the state for one slot (including no or very few transactions) and reaping the MEV in the subsequent slot.

Two measures appear to help: Inclusion lists and missed slot penalties. Inclusion lists ensure that the execution proposer must include some minimum amount of transactions supplied by the beacon proposer, so that the execution payload cannot be empty. However, an execution proposer can defeat inclusion lists by going offline for one slot, and miss proposing the execution payload. In this case, missed slot penalties would create economic pressure for the execution proposer to propose something, and something non-trivial by the property of inclusion lists.

A final note: A third mechanism recently proposed by Conor McMenamin, “Appointed Execution Proposers”, also performs the allocation for the Attester-Proposer Separation market structure, with a separate shape than either Execution Auctions or ETs. I hope to discuss some of the ideas in this post in the future, tying it back to rainbow staking among other topics.

Wat do?

I think we need to understand better the conditions required for something like Execution Auctions or ETs to make sense.

• From a consensus perspective, it may well be the case that Single Slot Finality or two-step PBS is a requirement for Slot-auction+32 ePBS and beyond, as the execution proposer delivery guarantees are weaker when the beacon proposer of the current slot N did not select the execution proposer for the same slot N.

• The pipeline [block-auction ePBS → slot-auction ePBS → slot-auction+32 ePBS → Execution Auctions] offers an iterative approach to offering a true validator-proposer separation, including the ability to capture MEV. However, the question of MEV-Burn applied to the slot-auction+32 mechanism remains: Does this clearly separate MEV rewards from beacon proposers, which is one of the goals of validator-proposer separation? If residual MEV exists due to the imprecision of the MEV-Burn mechanism, timing games in the beacon proposer step may persist. A chaotic idea would consist in endowing execution proposers with the execution proposing rights, such that the MEV-Burn gadget is applied to the execution proposer of slot N instead of to the beacon proposer of slot N, in order to allocate the execution proposing rights of slot N+32.

• The pipeline [block-auction ePBS (→ slot-auction ePBS (→ slot-auction+32 ePBS)) → ETs] is also possible (with SA-ePBS and SA+32-ePBS both optional intermediate steps in-between), yet the jump to an ET world appears more daunting. The main question on my mind is how bad is the MEV created by ETs, i.e., how to design their integrations as new “native assets” offered by the Ethereum protocol.

Bonus: Et tu, PEPC?

Proposer commitments have seen more interest with preconfirmations recently, so it might be worth wondering where PEPC (Protocol-Enforced Proposer Commitments) fits in all this, and how one might think about it given the framework of proposing and building rights.

Essentially, PEPC is a solution for the execution proposer to sell programmable building rights. In PEPC’s design, a proposer could add programmable validity conditions (proposer commitments) on the block they propose, such that the block could not be included in the canonical Ethereum chain if it it did not satisfy the proposer commitments registered by the proposer. In other words, the execution proposer creates the specs, or the template, by which the resulting block must be created, and the builders engaged by the proposer are tasked with delivering the block according to its specifications.

As an example:

1. Proposer Alice could commit to include a transaction with hash 0xabc at index 0 of the block. The commitment is registered on-chain, in Ethereum, either before Alice’s slot or when she proposes her beacon block containing proposer commitments in step 1. pictured above.

2. Proposer Alice offers to sell her building rights, listening to offers from a set of builders.

3. Builder Bob offers Alice 10 ETH for the building rights. Alice accepts by signing Bob’s offer, including it in her commitments.

4. Bob is aware of Alice’s commitment (it is on-chain, hence common knowledge to all participants building on Alice’s branch). Bob makes a block containing 0xabc at index 0. If Bob made any other block, e.g., including transaction 0xdef at index 0, the block would be ruled out as invalid by validators of the chain, but Alice would still get paid 10 ETH since Bob’s commitment was written on-chain as a protocol-bid.

Note that Bob accounts for Alice’s commitment in the bid amount he offers, e.g., Alice’s commitment may have reduced the value which Bob could extract from the block, as otherwise Bob could have made use of the first spot in the block, a very valuable position to be in. But the ability for Alice to make these commitments may have value to herself beyond what Bob could have done with it, e.g., Alice may collect preconfirmation tips from offering the commitment, or, using proposed PEPC features, she could have segmented blockspace such that partial builders each build a specific part of the block, or even sold the building rights of the block in advance (“blockspace future”, though perhaps the latter is less important if the execution proposing rights themselves are sold in advance too).

How does PEPC architecturally fit with the previous designs, where the beacon proposer and execution proposer are decoupled? If Alice is known to be the execution proposer of slot N say, 32 slots in advance, then Alice may register commitments in advance. The question is whether these commitments would be registered as either EVM transactions, in which case they should be included by execution proposers in their transaction payloads; or as special consensus-layer transactions, in which case they should be included by beacon proposers in their beacon blocks.

• If execution proposers register commitments, Alice has up to slot N-1’s execution proposal (inclusive) to register her commitments.

• If beacon proposers register commitments, Alice has up to slot N's beacon proposal (inclusive) to register her commitments.

In either case though, Alice depends upon proposers other than herself for the registration of her commitments. She is also unable to register commitments “just-in-time”, as she is about to sell her building rights to builders. PEPC was originally proposed as an overlay to the “two-slot PBS” design, as presented above with “Block-auction PEPC”.

We could go further to obtain all the properties we care about:

• Decouple the beacon proposer from the execution proposer fully.

• Let the execution proposer make just-in-time commitments, i.e., offer the execution proposer the ability to create the block template right before the delivery of the block by committed builders.

To get there, we need a three-step PBS construction, depicted here:

Opinions my own, reviews are not endorsements: I benefited greatly from conversations with Potuz and Terence, the RIG team + Mike + Fradamt + Ansgar, the ephema crew, Drew, Conor, a discussion with Taiko folks, and many others. It takes a village…

ePBS is back

Recent proposals towards enshrining Proposer-Builder Separation (PBS) (Potuz, Terence) seek protocol support for the market relationship currently known as MEV-Boost, re-opening the box of “PBS, wat do?”

To frame the following discussion, I’ll use a distinction I made in the past, between two components of PBS:

1. The market structure: The parties engaged in the market, and their conditions for engaging. Today, it is the idea that we’d unbundle the role of a validator between proposer and builder, and operate a fair exchange between the two unbundled parties, which Potuz’s design constraints seek to satisfy.

2. The allocation mechanism: The space of contracts which the parties may enter into. Today, with MEV-Boost, proposers give up entire rights to their execution payloads after listening to open bids in a “just-in-time” permissionless auction.

My line of arguments with PEPC was that enshrining a specific allocation mechanism such as ePBS could be dangerous, and that we could instead enshrine the ability for the validator to perform programmable fair exchanges instead, allowing maximum latitude for the validator to enter into commitments in their role as proposer. In this note, I go further and question the market structure of validator-as-proposer given recent proposals such as Execution Tickets. ePBS, as proposed recently, enshrines both a specific market structure and an allocation mechanism mostly inherited from MEV-Boost. The market structure determines the space of possible allocation mechanisms, and I argue that some of MEV-Boost’s limitations in inducing a “healthy” builder market may be inherent to the market structure involving validators-as-proposers.

*In the following, I use the term “payload” rather than “block” to limit the discussion to the execution payload only, and not talk about the delivery of the beacon block, which remains the duty of validators.

The pains of being proposer as validator

At its core, the idea of MEV-Boost is: A validator is given proposing rights allowing them to propose an execution payload once their turn is up, and receive proceeds from the use of these rights. Yet the validator wishes to contract out building rights to let someone else (a builder, or builders) decide the contents of the block on their behalf. MEV-Boost allows for this sale to happen, while making it happen wholesale, and spot. Proposers sell off their whole payloads, and builders commit to payload contents at the time of the bid. This is a specific allocation mechanism, and other designs exist, such as slot or hybrid auctions where the commitment is made to use a payload from a specific builder, but without committing in advance to the specific content of the payload.

At this point, more than anything, it feels like a protocol limitation that the validator has to remain the payload proposer, that they have to sign off on a process with which they have nothing to do in terms of its construction. In this sense, the signature of the proposer feels almost purely cosmetic, a technical necessity almost. Meanwhile, this technical necessity still requires the complex mechanics of the fair exchange at the heart of MEV-Boost. The exchange in question is that of a builder’s promised output (a block), against the signature of the validator, who assigns building rights while retaining proposing rights for themselves.

The complexity of operating this exchange cannot be removed, only displaced, allowing certain trust assumptions to change depending on whether the complexity exists out-of-protocol or in-protocol. The protocol taking on this complexity may be worth it, if we felt it was indeed the right idea for the protocol to organise and secure the allocation of building rights. By enshrining this exchange, the protocols continues to make the validator a proposer of the execution payload by default, and the protocol offers the ability to perform the exchange with a specific allocation mechanism, such as “spot, wholesale PBS”, or, as in a recent proposal by Potuz, “0-slot early, wholesale PBS”, a.k.a, slot auctions.

So now comes the question of deciding whether to enshrine a protocol mechanism for validators-as-proposers and builders to enter into mutually binding agreements with one another, i.e., for validators-as-proposers to have trustless option allowing them the sale of their building rights. An argument made during the recent (e)PBS breakout call was that the presence of this mechanism would sanitise the supply side of this market, i.e., relays and builders. For relays, the argument goes that since a protocol-approved mechanism exists, we can now take off our plate the responsibility of figuring out sustainable relay economics. For builders, the idea is that we now level the playing field to enter into service, since there exists a trustless, in-protocol way of doing so.

My issue is that neither assumption really questions whether it is the allocation mechanism or the market structure themselves which have created a market we consider too centralised. Relays today exist specifically to perform the fair exchange between validators-as-proposers and builders, and there is no indication that they would exist under the same shape or with the same economics given a different structure, or indeed exist at all. Builders may also very well be subject to centralising forces due to the wholesale and spot nature of the allocation mechanism. As a result, enshrinement of ePBS could enshrine the very things which cause the problems we seek to solve. So while ePBS does improve upon the status quo of MEV-Boost by increasing the action set of all market participants, could it also cement the existence of a market which is fundamentally unadapted? Are the improvements worth the cost of development, and are they the right boundary to set for the protocol?

Are validators good proposers?

We first question the market structure: Why should the right to propose an execution payload be given by default to the validator in the first place?

Christopher Goes

@cwgoes

yes, but the block producers are not analogous to the PoS validators - the checkpointers are analogous to the PoS validators, and they have very public reputation! e.g. CEXs. anonymous block production is always good, I'd say, but not the same as anon validation

1

12:05 PM • Nov 21, 2023

re: this tweet. Note that the original design of PoS on Ethereum was doing FFG as an overlay on top of good ole PoW chain. Would we be talking about timing games in that world? Checkmate.

Let’s try and think about reasons why validators ought to be the default payload proposers. Censorship-resistance may be a reason to keep validators active in the construction of execution payloads. We want the decentralisation of our validator set, a key tool to realise the maximum breadth of preferences possible, to be exercised during payload construction. Yet validators forego this ability entirely today when they use MEV-Boost, or could forego it entirely tomorrow when they would use ePBS. Proposals such as inclusion lists or derivatives (e.g., Multiplicity) exist to remedy this situation, allowing validators to impose binding but non-efficiency-decreasing [1] constraints on payload construction. These proposals are however somewhat orthogonal to the question of allocating proposing rights, in that they bind whomever happens to own this right, whether that is another validator or some other party.

The answer to why we care for validators to be attributed proposing rights by default may also be: We care for validators who are self-building to impose their favourite ordering or make the payload contents as they please, i.e., we want them to retain building rights along with proposing rights. Indeed, it may be seen as a feature that a decentralised set of participants (the validators) gets their turn one at a time to make a payload as suits them. Alice might like her payloads to be ordered fairly, where the definition of fairness is Alice’s prerogative and may be wildly distinct from Bob’s. In this case, removing the property right of building execution payloads from validators would be an issue: We would no longer guarantee that validators get the option to build execution payloads as they please. I do not personally see that as a major issue. First, the market has revealed the preference of most validators to not exercise this building right themselves, delegating the construction to other parties. Second, while validator agency over payload contents via self-building may be good, the validator has not in my opinion more reason than anyone else to make a “well-ordered payload” (separating out the question of censorship-resistance which was addressed in the previous section). Note that earlier designs such as MEV-Burn preserve the default allocation of proposing rights to the validators, while forcing them to give up their building rights.

Validator-proposer separation (a.k.a., attester-proposer separation, a.k.a., execution tickets)

So what if the protocol decided to no longer attribute by default the property right of proposing and building the execution payload to validators, but instead allocated it by some mechanism to parties possibly distinct from validators? If validators are simple “pass-through” intermediaries to a group of third-party entities constructing payloads, wouldn’t it make sense for the protocol to be concerned only with the allocation of proposing rights?

This is the gist of execution tickets (ETs), where a permissionless market allows buyers to purchase the right to propose execution payloads. These rights confer the ticket holder with a random allocation, where the holder learns a few moments ahead of time (how long exactly is a parameter to determine) when their ticket will allow them the opportunity to propose an execution payload.

The protocol may then no longer be concerned with the fair exchange of building rights between a protocol-legible validator-as-proposer and a protocol-illegible builder. The ticket-holder-as-proposer is still legible to the protocol, though the ticket holder may not be staked. In particular, the protocol may no longer be responsible for the fair exchange, if any, between the ticket-holder-as-proposer and builders: The protocol has performed its allocation function when selling the ticket.

Many questions remain over the viability of execution tickets as allocation mechanisms for the market structure which separates validators from proposers. My personal opinion is that convincing us of the correctness of the market structure would convince us that some mechanism exists to perform the allocation properly, ETs or otherwise, if ETs were indeed not the right mechanism.

The most potent line of argument I’ve seen questioning the market structure of validator-proposer-separation comes from Quintus Kilbourn and Conor McMenamin in their excellent post “When To Sell Your Blocks”. Here, they distinguish between passive monopolists and active monopolists. In the validator-as-proposer model, one may consider the validator to be a passive monopolist, who simply listens to bids made by builders for the right to build the payload. In the validator-proposer-separation model, as performed by ETs for instance, the ticket holder would become an active monopolist, who according to Quintus and Conor “cannot be circumvented and is thus able to do things like establish minimum tips that transactions have to pay to be included in their block(s) (monopoly pricing) and frontrun time-sensitive flow with little concern for recourse.”

Quintus and Conor further note:

[T]he distinction between active and passive monopolists doesn’t hold in a rational model. This distinction is derived moreso from observed behaviour from validators. It may be that in the long run, validators approach the rational behaviour of being active monopolists anyway. On the other hand, exogenous reputation concerns may prevent this.

In other words, if validators tend towards rationality in the long run, the difference between validators-as-proposers and ticket-holders-as-proposers may not remain very large. The accelerationist argument for this trend towards rationality has been established in practice, but might there be fundamental attributes which validators possess that would prevent them from ever fully becoming active monopolists? This remains an open question in my sense, one that my recent attempts at further unbundling the roles of a validator under the rainbow staking framework gets at. If there is no complementarity between the different roles that a validator may embody (as attester, as censorship-resistance producer, as payload producer), then there is a stronger argument for why nothing in the essence of validators prevents them from trending toward active monopoly, and why unbundling these roles may be a good idea.

Conclusion

There is almost a fractal construction at play when, in a validator–proposer separation world, the proposer recruited by the protocol could once again delegate the role of construction to another entity, the builder (or builders if the proposer used a different allocation mechanism for the builder rights such as partial block auctions). So overall, when we talk about market structure or allocation mechanism, we need to precise which market we’re interested in: the market allocating proposing rights, or the market allocating building rights?

I believe the implementation of ePBS should be considered holistically, in comparison with other choices such as execution tickets and validator–proposer separation more broadly. ePBS does improve upon certain aspects of the current MEV-Boost market, such as providing access to a trustless path and giving us the ability to enshrine different mechanisms like slot auctions. Yet, ePBS is concerned with the allocation of building rights, primarily, and perhaps this is not a problem the protocol should concern itself with. It may be enough indeed to allocate proposing rights, and relinquish control and observability past that point.

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!

• Part 1: Liquefaction

• Part 2: Re-staking

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

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

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:

• The solo staker could re-use the L.soETH to collateralise DeFi applications.

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

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.

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.

• Part 1: Liquefaction

• Part 2: Re-staking

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

• The first row represents the “pre-state”, denoting which assets are currently owned by each party.

• The last row represents the “post-state”, denoting which assets are owned by each party after all operations have concluded.

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

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

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

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

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

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

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

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

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

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