Skip to main content

Minimizing Risk to Validators

· 3 min read

Inspired by conversations with: Drew Patel

Minimizing Risk to Validator Operators

  • If you're a validator operator, understand your risks in opting in to our network are exactly the same as opting into a Karak DSS / Eigenlayer AVS.
  • Slashing is governed by Karak DSS / Eigenlayer AVS. Today, slashing on the restaking networks is 'social slashing' similar to Solana, where misbehaving validators will get their delegated stake removed and be kicked out of the network. No validator collateral is at risk.

Most major validator operators participate in a restaking network and understand the risks associated. Our slashing is managed entirely through the Karak DSS / EigenLayer AVS system, with our system imposing no additional slashing risk.

Restaking networks provide the collateral which backs the claims of a preconfer; it is a 'bond' that will be taken if the validator reneges on the preconfirmation agreement.

Our system delegates the responsibility of managing slashing to restaking providers. Designing slashing mechanisms is challenging, as even Eigenlayer hasn’t activated slashing on mainnet yet. We are asking 20%-90% of Ethereum network validators to participate in offering a preconfer, and they will likely feel more secure if a reputable restaking team manages the slashing conditions. An incorrect slashing condition could result in a large portion of Ethereum network validators being slashed simultaneously, posing a significant technical risk introduced by the preconfirmation registry contract, which is why it makes the most sense to delegate this role.

Centralization Concerns

The core idea behind restaking networks is that large-scale slashing should be managed in one centralized location, rather than across many. However, requiring nearly every Ethereum validator to opt in, while holding their ETH and enforcing slashing, creates a significant centralization risk within Ethereum, driven by the slashing contract itself. This burden should instead fall on a restaking network.

We can reduce the centralization risk of restaking by enshrining restaking into the Ethereum protocol or by developing more decentralized restaking protocols (we'll put out a post detailing this).

For the strongest insurance protection, we anticipate enabling slashing in the long term. However, this will only happen after the system has undergone extensive production testing to prove its stability.

Penalty Conditions

Solana, Karak, Eigenlayer are examples of teams that have implemented 'social slashing' backed services, with the technical risk of being slashed on any of these networks at 0.

We kick off the penalty condition, and the adjudication for a penalty condition to the restaking network the validator has opted into, with the veto committee of a restaking network deciding the correctness of the slash condition. The risk of opting in to be a preconfer is the same as being opting into a DSS on Karak or an AVS on Eigenlayer.

References