Slashing

Operators have stake assigned to them in each network they serve. Every network defines rules for correct behavior, such as producing valid blocks, signing messages only once per slot, or executing a strategy within specified limits. If an operator fails to perform these services according to the rules, the network middleware can raise a slashing request against them. On Ethereum, for example, this includes faults like double signing. The Slasher module is an optional component of the Vault structure that handles the enforcement of slashing penalties. It doesn't perform slashings by itself but processes the requests received from the network middlewares.

How it Works

In general, when a network fetches the stakes at some point in time, called the "capture timestamp", it receives the guarantee that the received amounts of collateral will be slashable during one epoch after it. Hence, the Slasher module always checks that the capture timestamp is not older than one epoch when executing the slashing.

In case of restaking, the guarantee might not be valid because of other networks' slashing. There is nothing to do about it because it's the nature of restaking itself.

Like the Delegator module, the Slasher module also has a types mechanic, where different Slasher types may be used for various purposes. Currently, there are two types (position indexes in the list below correspond to the on-chain types):

0. Slasher

This type performs an instant execution of the slashing request when received and validated. It is a simple and easy-to-understand implementation. However, it has too low flexibility compared with the next Slasher type.

1. VetoSlasher

VetoSlasher is a more complex type whose goal is to provide an in-house mechanism to handle a smooth transition for both networks and stakers from the just deployed versions of the networks to the battle-tested ones without additional development risks.

Its flow consists of three stages:

1. Request of the slashing, which is performed by the network middleware and validated by the VetoSlasher contract
2. Veto phase, whose duration is set during the vault's deployment, when the resolver (if set by the network) can veto the request
3. Execution of the slashing, which can be performed only by the network middleware if the veto was not issued

Burner

Once slashing is approved and enforced, the actual processing of the affected stake is delegated to a configurable Burner contract. This contract determines what happens to the slashed tokens – whether they are unwrapped (e.g., from LSTs), burned, or even redistributed. For the example Burner, see the wstETH unwrap / burn implementation.