Without safeguards or certain assumptions, redistribution increases the incentive to compromise AVSs and Operators because it enables an attacker to steal slashed or slashable stake. Two key attack vectors illustrate the potential vulnerabilities with enabling a specific implementation of redistribution in protocol.
Note: “Staker” can be used synonymously with “Delegate.” There are more attacks that aren’t mentioned, but the two provided are intended to be all encompassing. Also, this is not a suggestion for how redistribution should actually be implemented in-protocol, if at all.
Setup
Let’s assume there is 1 Staker, 1 Operator, 1 Operator Set, and 1 AVS. We assume that when a fault has been observed, a party submits a fraud proof and sends a corresponding slashing request to the AVS. There is at least one honest party that is incentivized to submit fraud proofs which we assume are confirmed instantly. Then AVS governance has 3.5 days to forward the slashing request to EigenLayer for execution. If it is not forwarded, it is effectively canceled. AVS governance makes a decision with some unspecified mechanism and has the unilateral ability to slash anyone by submitting a slashing request directly to EigenLayer. It is assumed that when an AVS registers it has the option of overriding the address that slashed funds are sent to, which is the EigenLayer designated burn address by default. If they override this address, we consider them as opted into “redistribution,” otherwise they are opted into “burning.” We begin with the assumption that an AVS can change this address at any time and it is instantly effective.
Attack 1 (Corrupt AVS)
A malicious actor submits a fraud proof alleging misbehavior by the Operators that is untrue and sends a slashing request to the AVS. There is a bug in the fraud proof and it generates a false positive. The malicious actor somehow compromises AVS governance, either technically or economically, and does not cancel the slashing request. The funds are slashed from the Operators and distributed to the AVS’s address which the attacker immediately sends to themselves and then somehow drains all value secured by the AVS.
Implications
- If we assume a perfectly functioning fraud proof system (e.g. no bugs or exploits) and that AVS governance is honest, there is no additional risk premium required by Stakers.
- If we assume a faulty fraud proof system and that AVS governance is honest, there is no additional risk premium required by Stakers as AVS governance will just cancel the slashing request.
- If we assume a faulty fraud proof system and that AVS governance is dishonest there is no stake or activity on the AVS.
- If we assume a faulty fraud proof system and that AVS governance is compromisable with some probability, there is an additional risk premium required by Stakers proportional to that probability. The mere ability to redistribute funds requires an additional risk premium by increasing the incentive to compromise AVS governance. But this risk is not because there is a faulty fraud proof system, it is due to the fact that AVS governance is compromisable and has the ability to unilaterally slash Operators. However, the fraud proof system would matter if a positive fraud proof was somehow a necessary condition for slashing as the AVS would not be able to unilaterally slash anyone without proof of misbehavior. To continue, any action that inhibits AVS governance to unilaterally slash stake obviously decreases the risk to Stakers.
Regardless of whether an AVS is currently utilizing burning or slashing, the risk to the Staker is the same since an AVS can inform EigenLayer of a change in the slashed funds address and that is effective instantly. Thus, if AVS governance is compromised, slashable stake allocated to the AVS can be immediately slashed and stolen from Operators and Stakers.
A potential mitigation is EigenLayer can enforce a delay to changing the slashed stake address which, in order to be effective, would need to be greater than the withdrawal and deallocation delays so that Stakers and Operators can observe that a change has been made and respond appropriately. There are nuances, however. If the AVS is currently opted in to redistribution with an address controlled by AVS governance, a Staker will still require a risk premium because if AVS governance is compromised then the attacker will simply send the slashed funds from the AVS governance address to their own. However, if the AVS currently sends slashed funds to the burn address, a malicious actor can’t get access to the slashable stake because all Stakers and Operators would withdraw or deallocate before the address is effectively changed, thus no risk premium needed.
There are a few assumptions needed to make this mitigation work. We need to assume that Stakers and Operators have perfect, timely information. Also, we need to assume Stakers and Operators are attentive, which we can define as an entity that checks the necessary information at least once every withdrawal/deallocation delay - slashed stake address delay days. To emphasize, these are very strong assumptions as the amount of information needed to make decisions could be impractically large.
If the AVS is currently opted into redistribution, the revenue-to-attack is the sum of the amount secured by the AVS, various token shorts, and total slashable stake. However, if AVS is opted into burning, an attacker can only earn the amount secured by the AVS and various token shorts. The cost-to-attack in both scenarios is the cost of compromising the AVS governance mechanism.
To simplify, assume an attacker can’t make anything from token shorting. The standard definition for being “cryptoeconomically safe” is that the cost-to-attack is greater than or equal to the revenue-to-attack. Typically, it is assumed that the amount of stake an attacker can get slashed is greater than the value that can be extracted from what the AVS is securing, e.g. consumer funds. In the ideal case, this holds, and if the attack is successful, then consumers can redistribute the slashed funds, making them whole. However, if there are no appropriate delays, our assumptions don’t hold, and if the AVS is currently opted in to redistribution, the attacker can earn the amount that is secured and the corresponding amount that is securing it.
Consumers assess if the amount they expect to lose from the additional risk of redistribution, including the risk premium paid to Stakers, is greater than the amount they expect to earn from redistribution. Regarding the premium, it is unclear how much of the cost will be borne by the AVS versus the Consumer or whether they’d be willing to pay a premium at all.
Attack 2 (Corrupt Operator)
An Operator creates a dummy AVS, opts all of their delegated non-slashable stake into it, slashes themself and then steals the funds.
Implications
- If we assume that an Operator is honest and has perfect security then there is no risk premium required by the Staker.
- If we assume that an Operator is dishonest and has imperfect security then the Operator receives no delegations.
- If we assume that an Operator is honest and has imperfect security then the answer is nuanced. Assume an Operator has not allocated slashable stake to any AVS. An attacker would allocate all delegated stake to its own AVS that it can slash and steal the funds. If the allocation delay is less than the withdrawal delay then an attacker can steal the funds without any ability for the Staker to withdraw. If the allocation delay is greater than the withdrawal delay then an attentive Staker has allocation delay minus withdrawal delay days to observe the allocation and submit a withdrawal and they would not require a risk premium on their non-slashable stake. An inattentive Staker would require a risk premium on their non-slashable stake. These results hold even if all the Operator’s delegated stake are currently slashable by some other AVSs.
- Without redistribution, the worst case scenario for a Staker was that their delegated funds were destroyed, and therefore represented nothing that could be earned by an attacker. On a standalone basis, the attacker can only lose the amount it cost them to compromise the Operator.
Other issues
We provide guarantees as to the “minimum” amount of stake that might be slashable for a given Operator. But when slashing happens, the AVS provides the operator and the percentage of their stake to slash. The amount that actually gets slashed, and thus redistributed, may be higher than the estimate.
Potential mitigations in this specific design
There are four delays: allocation delay, deallocation delay, slashed stake address change delay, and withdrawal delay. The following four inequalities offer some form of mitigation making some assumptions about attentiveness:
- withdrawal delay < allocation delay
- deallocation delay < slashed stake address change delay
- withdrawal delay < slashed stake address change delay
- allocation delay + deallocation delay < slashed stake address change delay
We could also enshrine opting in to slashing or redistribution at the Strategy level. For example, create a non-slashable ETH Strategy, a slashable with burning ETH Strategy, and a slashable with redistribution ETH Strategy. The last option somehow allows the AVS to override the default burn address. Such a system would allow either Stakers or Operators to express their preferences and protocol enforced guarantees about the usage of stake. This could also assist in the slashing go-to-market. The issues are complexity and fragmentation.
For completeness, AVSs can send their slashed stake to a third party that provides redistribution-as-a-service. Obviously you’d need to trust the service but it could enable some novel solutions.
Conclusion
There are non-trivial risks to this in-protocol redistribution design. For a different implementation, see Matt’s post here.