Slash Immunity

Overload's many-to-many restaking model implements slash immunity. In other words, you cannot be slashed for your stake on Overload.

We achieve this by utilizing onchain consensus, where we are able to circumvent the slashable offences that Proof-of-Stake consensus' usually have.

Slashable offences in Ethereum

In e.g. Ethereum and Cosmos consensus, there are a couple different penalties that exist. In Cosmos, a slashable offense is called an infraction.

1. By proposing and signing two different blocks for the same slot
2. By changing history with surround voting
3. By "double voting" by attesting to two candidates for the same block
4. Inactivity leaks

On Overload, many of these offences will be a non-issue, explained more in detail below.

Onchain Consensus and Jailing

On Overload, we are able to circumvent many of the possible offences by moving the consensus logic onchain. For example, one would not need to consider double voting/attestations as the EVM contracts would disallow it. A validator would be able to attest once, and the second attestation would simply revert if it was tried in a transaction.

The only issue left would then be the inactivity problem. As the consensus contract is built by outside developers, we generally recommend to implement a simple "kick and jail" mechanism for inactive validators. We recommend that the inactive validators be kicked (but not slashed) from the validator set, as well as being timelocked inside a jailed state until a timestamp is passed. The validator then loses out on all potential rewards and cannot move their assets, which implies forfeiting all types of yield during that time period.

In summary, you cannot slash someone's stake on Overload, and instead we urge developers to build jailing mechanisms with more strict liveness requirements to deter inactivity among validators. To read more about the rationale behind no slashing/slash immunity, we refer the reader to the Models section.