Slashing

Slashing is how a Network penalizes operators for provable misbehavior. A Network’s middleware sends a slashing request to the vault; the vault’s Slasher module checks timing and amount constraints; if the request is valid, the vault reduces the operator’s effective stake and forwards the penalized collateral to a Burner, which applies the vault’s policy (burn, redistribute, route, etc.). The goal is for penalties to be executable, bounded, and auditable.

Slasher module

The Slasher is the vault module that enforces penalties. It does not detect faults itself. Instead it:

• reads stake data from the Delegator (how much stake an operator had in a subnetwork at a given time)
• reads its own internal record of previous slashes for the same snapshot
• validates a new request against those guarantees
• if valid, updates its internal records, informs the Delegator if needed, and calls the vault/Burner to handle the tokens

A vault can be deployed with one of three slashing modes:

• No slashing — slasher address is zero; the vault can never be slashed
• Slasher — instant execution as soon as a valid request arrives
• VetoSlasher — a request plus a short veto window, then execution if no veto occurs

Once chosen at deployment, the slashing model for a vault is fixed.

The shared flag isBurnerHook controls whether the Burner must be invoked on each slashing event (for example, to unwrap derivatives or forward to another contract).

Capture timestamp and guarantees

Networks do not slash against arbitrary state. They first capture stake at a particular time, then slash against that snapshot.

When a Network fetches stake at some point in time (the capture timestamp), it receives a guarantee that the captured amount of collateral will remain slashable for one vault epoch after that timestamp. When the Slasher later executes a request, it checks:

1. The capture timestamp is not older than one epoch. If it is, the request is considered stale and rejected.
2. The requested amount does not exceed the remaining guarantee for that capture after accounting for any earlier slashes that used the same snapshot.

This is what makes slashes bounded: you cannot request more than the guarantee tied to that capture.

In restaking setups, a slash on one Network can reduce the guarantee left for others, because they share collateral. That is a property of restaking, not a bug in the Slasher. The capture bound still applies: across all Networks together, you cannot take more than was guaranteed at that snapshot.

Execution flow

Every penalty follows the same basic flow, regardless of Slasher type.

1. Submit

   Network middleware calls the Slasher with a slashing request that includes the subnetwork, operator, amount, and capture timestamp.

2. Check

   The Slasher pulls stake data for that capture from the Delegator, aggregates previous slashes for the same snapshot from its own storage, and verifies:

   • freshness (capture within one epoch), and
   • bounds (requested amount ≤ remaining guarantee).
3. Optional veto (VetoSlasher only)

   If the vault uses VetoSlasher, the request enters a veto period. For vetoDuration seconds after creation, any configured resolver can veto the request. A resolverSetEpochsDelay parameter controls how long it takes for newly set resolvers to become active, measured in vault epochs.

4. Apply

   If the request passes checks (and veto, if applicable), the Slasher:

   • records the penalty so future requests against the same capture see reduced remaining guarantee
   • triggers any Delegator hook if configured
   • calls the vault/Burner to actually process the penalized collateral

Slasher types

A straightforward module: validate and execute in a single step. There is no on-chain dispute window. This is appropriate when fault conditions and evidence are clear and mature, and the Network is comfortable with immediate penalties.

Adds an on-chain review window. The flow is “request → veto window → execution”:

• Request: middleware submits and VetoSlasher validates.
• Veto: resolvers have vetoDuration seconds to veto.
• Execution: if no veto is recorded, the Network calls execute and the penalty is applied.

resolverSetEpochsDelay enforces that new resolvers only become active after a minimum number of vault epochs, giving users a chance to exit before a change in the dispute set takes effect.

Slasher is set to address(0). The vault cannot be slashed at all. This degrades the economic security guarantees for Networks and should be an explicit design choice.

Burner

Once a slash is approved, the Slasher delegates the token handling to the Burner. The Burner defines what happens to penalized collateral. Typical patterns include:

• unwrapping derivative collateral and burning the underlying
• redistributing all or part of the penalty to stakers or well-behaving operators
• sending funds to a treasury or insurance pool
• locking tokens or routing them to another contract for protocol-specific logic

The Burner is configured per vault at deployment and is not automatically changed by slashing events. Burning is optional; redistribution is a valid outcome if it matches the vault’s policy.

Participation and isolation

A slashing request only applies if, at the capture timestamp:

• the operator had opted into both the vault and the Network (including the relevant subnetwork), and
• the Delegator reports positive effective stake for that operator in that subnetwork.

If either condition fails, the request is rejected. This ensures Networks cannot accidentally penalize non-participants.

Whether a slash affects only one Network or multiple depends on the vault’s delegation model:

• Single-Network / single-operator vaults give strong isolation: a penalty for one Network does not spill over to others because the collateral is not reused.
• Multi-Network restaking vaults share collateral across Networks. A penalty in one Network reduces what remains for others, but each individual penalty is still capped by its capture-time guarantee and checked by the Slasher.

Timing constraints

To keep slashing executable, the following must fit inside the vault epoch:

• the Network’s own epoch and finality / detection delay
• any off-chain time to build and submit a slashing request
• the veto period (vetoDuration), if using VetoSlasher
• the time to send and finalize the execution transaction

If downstream systems (for example, a dispute layer) require longer resolution, the vault’s epochDuration should be set high enough so that valid slashes can still be committed and executed before the guarantee expires.