TLDR: Redistribution of slashed assets can be implemented by creating a 1:1 token wrapper ERC20 that overloads “Transfer to 0x00…00e16e4” with “unwrap to [any other address].”
Eigenlayer Slashing:
Slashing in EigenLayer is currently handled in protocol and provides no mechanism to redistribute the slashed funds to harmed parties. All funds slashed are burned to the address 0x00…00e16e4. This takes place in the following process:
- An AVS submits a slashing event. This step is entirely internal to EigenLayer. The slashing AVS provides the operator, strategies to slash, and % of the operator’s funds that they intend to slash. The internal shares of all associated stakers are reduced by % of slashable stake designated, making it impossible for them to withdraw the slashed funds. The “slashed amount” is emitted as an event.
- Any address submits a request to burn funds. This transfers the ERC20 from the strategy to the burn address (0x00…00e16e4).
The goal of this exercise is to create a vault that utilizes the above process to instead redistribute slashed assets to a specified address.
Step 1: Deposit into the Vault
For the sake of this example we will use [wETH] as the token that we intend to redistribute. Upon depositing [wETH] the Vault issues [rewETH] at a 1:1 ratio with the deposited asset. [rewETH] can be redeemed 1:1 for [wETH] at any time. There can never be any change in the share price of this asset.
Importantly the [rewETH] ERC20 token contains special logic specifically to allow for redistribution upon burning by Eigenlayer. The needs of this logic will be described later.
Step 2: Deposit into EigenLayer
Eigenlayer allows for the permissionless creation of token strategies to handle the deposits of any ERC20 token. This is deployed for the [rewETH] token. EigenLayer will always see [rewETH] as a separate token from [wETH], allowing AVSs to independently decide whether they value it as security for their services. Like all strategies, shares of the [rewETH] strategy cannot be slashed until they are delegated to an operator and then allocated as slashable to an AVS.
Step 3: Slashing Occurs
Slashing of [rewETH] is handled by EigenLayer in the same way as any other token. Internal shares of the strategy are removed from stakers, rendering them irretrievable. This emits an on-chain event that can be referenced later. Slashing occurs entirely in-protocol, so no [rewETH] logic can be evoked at this time.
Step 4: Burn the Token
When anyone permissionlessly calls the function to burn [rewETH] from the strategy, our custom ERC20 logic comes into play. When the Vault detects that any amount of [rewETH] is transferred to the address 0x00…00e16e4, is instead withdrawn by a predetermined address. This burns the [rewETH] and transfers the same amount of [wETH] from the vault to that predetermined address. This does not affect the share price, which remains 1:1 for [rewETH]:[wETH]. Any users slashed have access to proportionally less [rewETH], which is still redeemable for [wETH].
Step 5: Redistribute
Slashed [wETH] is now in the custody of the burn address established by the Vault, and redistribution can be handled in any way the vault creator wishes.
Discussion
This constitutes the MVP of a redistribution vault utilizing the existing slashing features of EigenLayer. It can be implemented at any time for any standard ERC20* asset and features staker opt-in to redistribution, AVS valuation of the redistribution independent from the underlying asset, redistribution according to any parameters set by the vault creator, and is completely independent from EigenLayer.
- Vaults created for non-Standard ERC20 assets must include logic to handle all non-standard functionality. E.G. rebasing tokens would require vault logic to also rebase the wrapper.
The design can be readily extended by redistributing assets to a smart contract.
- Assets can be burned to a vault-defined “redistribution council” that decides how they should be handled.
- For single AVS redistribution, the funds can be transferred directly into AVS logic for the compensation of injured parties.
- To allow redistribution to multiple AVS, the smart contract could utilize a proof system to release funds to AVSs that prove they executed the slashing event.
- This could be facilitated by executing slashing through an immutable smart contract that stores the slasher and nominal amount slashed in each event.
- Could be hardened by removing upgradability, provided EigenLayer commits to only ever burn to 0x00…00e16e4.
Regarding Native ETH:
This vault mechanism is reliant on the ability to 1:1 wrap deposited assets. Because natively staked ETH can be slashed on the beaconchain, a deficit in vault assets could be created that would have to be tracked or socialized.
- Implementing this method directly would result in a vault holding ETH that is not natively staked, and would miss a significant degree of uplift as a result.
- Tracking and attributing beaconchain slashing to the correct staker would require the creation of a system similar in complexity to existing EigenPods.
- Socializing beaconchain slashings is identical to implementing an LST.
- Implementing a wrapper for ETH that is already staked in an existing EigenPod is an LRT.
- Restaked LRTs, while possible, are likely to be regarded as low quality collateral.
In addition, ETH staked to the beaconchain is inherently illiquid, adding additional barriers to its use in systems that require the rapid redistribution of slashed collateral. In contrast, ERC20’s can be made immediately available to further redistribution logic within the AVS.