The Mechanics of Allocating and Slashing Unique Stake

Protocol Research
1

Brett Palatiello & Gautham Anant

Hey everyone! Please see Brandon’s introduction for more context on how these posts should be interpreted and we actively encourage the community to engage with them.

Intro

In our post introducing the new security model we abstracted how Operators allocate Unique Stake. We explained that Operators directly assign percentages of their stake. In reality, the process is more nuanced. This post explains the mechanics of allocating and slashing Unique Stake for Operators.

Initialization

Magnitudes represent the proportion of an Operator’s Total Stake allocated as Unique Stake across various Operator Sets and as non-slashable stake. For each Strategy (stake token), an Operator starts with a Total Magnitude of 1 \times 10^{18}. However, for legibility, we will assume a Total Magnitude of 10,000.

Let’s consider an Operator who has been delegated 100 EIGEN but has not yet allocated any magnitude or registered with an Operator Set. Thus, all their EIGEN is non-slashable.

Magnitude Proportion EIGEN
Non-slashable 10,000 100% 100
Total 10,000 100% 100

Allocation

Operators set an allocation delay, which defines the time it takes to move non-slashable magnitude to an Operator Set. This feature allows Operators to accommodate stakers who may want to withdraw from their Operator before new allocations take effect. Of course, for this to be possible, the allocation delay must be longer than the withdrawal delay. If an Operator wants to change their allocation delay it takes 17.5 days to take effect, but this duration is still being debated.

Suppose the Operator sets an allocation delay of 5 days and allocates 2,000 magnitude to \texttt{EigenDA_EIGEN} (an Operator Set where the AVS name is to the left of the underscore and the Strategy to the right). The allocation is considered pending during this 5-day period, meaning it is not yet slashable by \texttt{EigenDA_EIGEN} and cannot be allocated elsewhere.

Magnitude Proportion EIGEN
\texttt{EigenDA_EIGEN} (pending allocation) 2,000 20% 20
Non-slashable 8,000 80% 80
Total 10,000 100% 100

Allocations automatically take effect after the allocation delay. Allocations can only be queued from non-slashable magnitude, not from pending allocations or magnitudes already allocated to an Operator Set.

Magnitude Proportion EIGEN
\texttt{EigenDA_EIGEN} 2,000 20% 20
Non-slashable 8,000 80% 80
Total 10,000 100% 100

After the allocation delay, the operator can register for \texttt{EigenDA_EIGEN}, and only upon registration does their EIGEN become slashable by the Operator Set. Therefore, the Operator has 100 EIGEN in Total Stake, with 20 EIGEN in Unique Stake allocated to \texttt{EigenDA_EIGEN}. Now, \texttt{EigenDA_EIGEN} can exclusively slash the Operator for up to 20 EIGEN.

Let’s assume that the Operator also allocates 2500 and and 3000 magnitude to \texttt{Eoracle_EIGEN} and \texttt{Lagrange_EIGEN}, respectively.

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 3,000 30% 30
\texttt{Eoracle_EIGEN} 2,500 25% 25
\texttt{EigenDA_EIGEN} 2,000 20% 20
Non-slashable 2,500 25% 25
Total 10,000 100% 100

Deallocation

To reduce an allocation, Operators queue a deallocation which moves magnitude from an existing OperatorSet allocation to its non-slashable magnitude. While the duration is still up for debate, the deallocation process takes 17.5 days (420 hours), during which the deallocation is marked as pending. This period allows AVSs to update their view of Unique and Total Stake to reflect the Operator’s reduced allocation and to leave a reasonable amount of time for all tasks created before the deallocation to be slashed for, if necessary. We plan to allow Operator Sets to customize this duration based on their specific needs in a future release.

Let’s say the Operator deallocates 1,000 magnitude from \texttt{Lagrange_EIGEN}. While the deallocation is pending it remains slashable and cannot be cancelled. For example, \texttt{Lagrange_EIGEN} can still slash the Operator for up to 30 EIGEN.

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 2,000 20% 20
\texttt{Lagrange_EIGEN} (pending deallocation) 1,000 10% 10
\texttt{Eoracle_EIGEN} 2,500 25% 25
\texttt{EigenDA_EIGEN} 2,000 20% 20
Non-slashable 2,500 25% 25
Total 10,000 100% 100

After 17.5 days, the pending deallocation takes effect automatically and the magnitude becomes non-slashable, allowing it to be reallocated if desired.

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 2,000 20% 20
\texttt{Eoracle_EIGEN} 2,500 25% 25
\texttt{EigenDA_EIGEN} 2,000 20% 20
Non-slashable 3,500 35% 35
Total 10,000 100% 100

Note, for UX purposes, a restriction of the protocol is that an (operator, strategy) pair can only have 1 pending allocation to or deallocation from an Operator Set at a time. They cannot have 1 of both, they can only have 1 or 0 of either.

Deposits and Withdrawals

Deposits and withdrawals do not affect magnitudes but scale the Total and Unique Stake of the Operator. Deposits take effect immediately, making the newly deposited EIGEN slashable by any Operator Set the Operator has allocated to. For example, if a staker deposits 100 more EIGEN into EigenLayer, and thus increasing the Operator’s delegated EIGEN to 200, it would result in the following:

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 2,000 20% 40
\texttt{Eoracle_EIGEN} 2,500 25% 50
\texttt{EigenDA_EIGEN} 2,000 20% 40
Non-slashable 3,500 35% 70
Total 10,000 100% 200

Withdrawals, like deallocations, must be queued and can be completed after 17.5 days (duration still being debated). During this time, the withdrawal remains slashable. The withdrawal can be completed in a separate transaction to redeem tokens after the withdrawal delay. Withdrawals are not exposed to slashing that occurs after the withdrawal delay but before the withdrawal was completed.

Slashing

When an Operator Set decides to slash an Operator, it specifies a slashing proportion. The magnitude, and thus the EIGEN, allocated to that Operator Set by that Operator is decreased by that proportion.

Building off our previous example with 200 EIGEN, if \texttt{Lagrange_EIGEN} slashes the Operator by 50%, it would result in the following:

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 1,000 11% 20
\texttt{Eoracle_EIGEN} 2,500 28% 50
\texttt{EigenDA_EIGEN} 2,000 22% 40
Non-slashable 3,500 39% 70
Total 9,000 100% 180

Note, slashing by one Operator Set does not affect the magnitudes or EIGEN allocated to other Operator Sets. This is the definition of Unique Stake.

Slashing with a pending deallocation

Another common case is when an Operator has a pending deallocation and they are slashed. Let’s assume instead that the Operator has a pending deallocation of 500 magnitude from \texttt{Lagrange_EIGEN}:

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 1,500 15% 30
\texttt{Lagrange_EIGEN} (pending deallocation) 500 5% 10
\texttt{Eoracle_EIGEN} 2,500 28% 50
\texttt{EigenDA_EIGEN} 2,000 22% 40
Non-slashable 3,500 39% 70
Total 10,000 100% 200

If Lagrange slashes the Operator by 50%, then both the current allocation and pending deallocation are slashed by that proportion, resulting in:

Magnitude Proportion EIGEN
\texttt{Lagrange_EIGEN} 750 7% 15
\texttt{Lagrange_EIGEN} (pending deallocation) 250 3% 5
\texttt{Eoracle_EIGEN} 2,500 28% 50
\texttt{EigenDA_EIGEN} 2,000 22% 40
Non-slashable 3,500 39% 70
Total 9,000 100% 180

Future Posts

We will shortly put out posts to discuss and request feedback on important ideas and open issues that will impact what we have described in this article, such as the “Allocator” role and the time delay for slashing.

Conclusion

Understanding the detailed mechanics of allocating and slashing Unique Stake is crucial for Operators. By managing magnitudes, allocation delays, and being aware of the slashing mechanisms, Operators can more effectively control their delegated stake and exposure to potential penalties.

Disclaimer

The Eigen Labs Research Team uses the Forum as a space to share research on the protocol, to preview elements and ideas that may or may not become part of upcoming releases, and to explore ways of using, analyzing, and thinking about the EigenLayer protocol and ecosystem. Unlike our blog posts and social media announcements, which focus on formal updates and decisions, the Forum will be more interactive and experimental, allowing us to exchange ideas and gather feedback from a wider group.

4 Likes
2

Is there a typo here? Did you mean to say a total of 100 and not 10k?

1 Like
3

I think the maths in the tables are incorrect. This article needs to be reviewed for all arithematic errors and updated with the changes.

1 Like
4

Thanks @bmpalatiello! Two questions:

  1. Can magnitude ever increase? I see operators can decrease magnitude when slashed. A too low magnitude can lead to loss of precision in allocating stake. Do you see a “reset” where total magnitude goes back to 100?
  2. If not, can total magnitude be used to measure an operator’s safety against slashing? For example, an operator with total magnitude of 1 \times 10^{18} is safer than an operator with less total magnitude.
1 Like
5

There’s no typo. The Total Magnitude is 10,000 and Total EIGEN is 100.

2 Likes
6

All the math in the tables are correct.

2 Likes
7

Nice post on the allocation and deallocation methods. Looking forward to more details on the new security model.

I have some questions.

  1. Allocation delay mismatch

(Assuming an operator can start participating once they allocate.)

Issue: The allocation delay introduces a period during which the operator’s stake is not slashable by the new Operator Set, even though they may start participating in its activities. This could be exploited by malicious operators to perform misbehavior without the risk of being slashed.

Possible solutions:

A. Synchronize participation and slashing.

B. Immediate slashability upon participation

  1. Concurrent allocations and pending status

The protocol restricts operators from having both a pending allocation and a pending deallocation for the same Operator Set simultaneously.

Issue: The inability to immediately reverse an allocation may inconvenience operators but doesn’t necessarily introduce a security vulnerability. However, it could be exploited by malicious AVSs to trap operators in unwanted allocations.

  1. Slashing during pending deallocation

Issue: Operators remain slashable during the deallocation delay, which could expose them to increased slashing risk, especially if malicious actors trigger slashing events during this period. Malicious parties could coordinate to slash operators who are deallocating, maximizing the operators’ losses during the deallocation window.

  1. Pending deallocation and low liquidity

Issue: Operators could face liquidity issues during deallocation delays, especially in volatile markets, increasing their financial risk if slashing occurs. Sudden market downturns could reduce the value of staked assets, and operators might be unable to cover slashing penalties, leading to cascading failures.

  1. Incomplete slashing coverage

Issue: Since Unique stake is only slashable by the Operator Set it is allocated to, operators might allocate minimal stake to high-risk services, reducing their potential slashing penalty while still causing significant harm. Operators may game the system by allocating minimal stake to risky Operator Sets, knowing that their maximum loss is limited.

  1. Coordination of slashing across sets

Issue: Lack of coordination between Operator Sets can lead to inconsistent slashing, allowing operators to escape full accountability for actions that affect multiple sets. Operators could exploit differences in slashing response times to minimize total penalties.

  1. Cascading slashing impact on total stake

Issue: Slashing in one Operator Set reduces an operator’s Total stake, which proportionally reduces the stake allocated to other Operator Sets. This can weaken the security of other AVSs that rely on the operator’s stake. If multiple AVSs simultaneously slash an operator, the operator’s Total Stake could diminish rapidly, impacting all Operator Sets the operator participates in, even if no misbehavior occurred in those sets.

  1. Insufficient(?) deallocation delay

Issue: An operator commits a subtle infraction that is difficult to detect immediately. By the time the AVS identifies the misbehavior, the operator’s deallocation has completed, and the stake is no longer slashable.

  1. Misaligned incentives due to stake redistribution

Issue: The current model does not specify redistribution of slashed stake, which could affect operator incentives. Without redistribution, operators might not be sufficiently deterred from misbehavior if they perceive the slashing penalty as an acceptable risk compared to potential rewards.

  1. Operator overcommitment

Issue: An operator allocates 90% of their stake to three different Operator Sets. If two AVSs simultaneously slash the operator by 50%, the operator’s Total Stake becomes negative, leading to unexpected loss.

  1. Allocation and deallocation timing games:

Issue: Operators might time their allocations and deallocations to minimize exposure to slashing and maximize their staking rewards. By frequently reallocating stake or setting minimal allocation delays, operators could avoid penalties while still benefiting from rewards. For example, an operator allocates stake to an Operator Set shortly before rewards are distributed and deallocates immediately after, minimizing the window during which they can be slashed. So, this results in reduced slashing exposure, maximized rewards and risk to Operator Set security.

2 Likes
8
  1. Right now, magnitudes cannot increase. There’s no reset at this point. Each (Operator, Strategy) is initialized with 1x10^18 Total Magnitude which means, assuming a .75 slashing proportion, to get down to a Total Magnitude of, say, 100, would mean the Operator’s Total Magnitude has been slashed 27 times. So, we assume the Total Magnitude wouldn’t get that low. That said, it is an edge case and we are thinking about how to handle it.
  2. It can be, yes!
2 Likes
9

Hey guys - appreciate you creating a public space for research & discourse around the design choices you’re considering!

A few open questions from our end:

Why exactly would an operator want to set an allocation delay? Are they still receiving rewards during this time period? Also, would it be up to the operator to communicate with stakers via social channels, etc when they initiate their stake allocation?

Re Deallocation: Is there any specific reason 17.5 days was chosen as the standard process time (aside from the # of hours, kek)

During this time period, since the stake is still slashable, does that means rewards are still being accrued until the deallocation time queue is completed?

Also, looking forward for customizable duration times per operator sets, what parameters will go into the customizability? I would assume most would want to opt in for the minimum amount of time possible to maximize optionality, but why would that perhaps not be the case?

Are you considering allowing shorter deallocation for operator sets that have better uptime and less historical slashing events?

3 Likes
10

Why exactly would an operator want to set an allocation delay? Are they still receiving rewards during this time period? Also, would it be up to the operator to communicate with stakers via social channels, etc when they initiate their stake allocation?

An Operator wouldn’t want to set an Allocation Delay (e.g. we anticipate LRTs will set it to 0 since they are their own staker), it’s that “conservative” delegators may want it which can force the hand of an Operator. If an Operator has an existing allocation, they would be receiving rewards on that, not on the portion that is pending allocation. Yes, we imagine the Operator communicating changes in allocations or someone directly, or through a third party, monitoring their Operator’s allocation changes.

Re Deallocation: Is there any specific reason 17.5 days was chosen as the standard process time (aside from the # of hours, kek)

Yes, so the 17.5 days is not set in stone. We’re going to come out with a forum piece within the next few weeks discussing that number and its relationship to “slashable windows” which we don’t think AVSs are thinking enough about. So, stay tuned for that, we’d love your input!

Also, believe it or not, 420 hours was a remarkable coincidence.

During this time period, since the stake is still slashable, does that means rewards are still being accrued until the deallocation time queue is completed?

That’s up to the AVS whether they want to continue rewarding stake that is pending deallocation, though we think most AVSs will not.

Also, looking forward for customizable duration times per operator sets, what parameters will go into the customizability? I would assume most would want to opt in for the minimum amount of time possible to maximize optionality, but why would that perhaps not be the case?

Very much TBD and options are wide open.

Are you considering allowing shorter deallocation for operator sets that have better uptime and less historical slashing events?

This is also wide open. I’d imagine customization would happen at the AVS/Operator Set level since it’s largely a function of how much time is needed identify a slashable event and, ultimately, slash the Operator for a given task. This will obviously vary based on the nature of the task, governance, etc…

2 Likes
11

awesome - thanks for fielding all those sir

looking forward to collaborating further here alongside the rest of the community!

3 Likes
12

Thank you for your article.
Are strategy and quorum synonymous here?

2 Likes
13

Just to clarify, are you asking if my usage of the word Strategy in this article is synonymous with “quorum” in the other article?

1 Like
14

Is “Unique Stake” standard?
Or is this some particular parameter?
The current operators need to migrate to a Unique Stake model or how will this go?

15

Yes, indeed that is my question your usage of Strategy is synonymous with what the AVS book refers to quorum. To me, it seems that it is

16

Love the draft design, the detailed tables are especially helpful.

Can you share more background, history on the decision to use the term “magnitude” for an Operator? Eg if we managed Allocation and Slashing only via Proportion and Token Amount (without Magnitudes), do we lose some clarity in accounting and communication?

1 Like