Slashing

Learn more about how SatLayer enables protocols to enable slashing of restaked assets

In addition to periodically distributing rewards, Bitcoin Validated Services (BVSs) must also have a framework for punishing bad behavior. The most straightforward way to do this is to slash the assets which are controlled by the misbehaving party. In most cases, the slashing will be partial, or partially slash the operator's assets. However, full collateral slashing might be appropriate in sufficiently serious cases of misbehavior. SatLayer provides the coordination layer that enables networks to programmably specify the criteria of operator misconduct. This enables bitcoin security to secure arbitrarily flexible network architectures, greatly expanding the potential use cases for the Bitcoin network.

Anatomy of a Slashing Request

1

Initiate the slashing request

The slashing process begins with the initiation stage. Depending on the implementation and slashing strategy, this action may be triggered by:

• The BVS protocol

• Middleware contracts

• The operators themselves

Note: This stage does not determine the validity of the slashing accusation. It only acts as the entry point for submitting a slash.

This is essentially a mechanism to report or raise suspicion about a potentially malicious or faulty operator.

2

Resolve the slashing request

Once a slashing request has been initiated, it enters the resolution phase. The logic and procedures at this stage can vary greatly depending on the network's design and governance model.

Below are a few examples of how the resolution phase can be implemented:

• Social slashing, where other operators in the network can vote on the validity of the accusation

• Automated verification systems, where any system which can determine whether a slashing event is valid or not objectively, such as a resolver contract capable of autonomously validating offenses based on objective criteria. When submitting a slash request, a slashing party might also submit a cryptographic proof of the misbehavior which can be validated by the resolver.

3

Redistribute or burn the slashable assets

If, and only if the resolution concludes that slashing is warranted, the final stage involves redistributing or burning the slashable assets.

We are looking to enable the following options:

• Redistribution pool, where a portion of the slashed assets may be redirected to, which can then be repurposed via governance votes or other mechanisms

• Direct burning, where the slashed assets are permanently burned

This stage ensures there is a tangible penalty, reinforcing the integrity of the network and deterring future misbehavior.

Slashing Architecture

WIP. Social slashing will not be live until the end of Phase II and fully programmatic slashing will not be implemented until the end of Phase III

Slashing message passing workflow

A slashing message first enters SatLayer through the bvs-router, which routes the message to the appropriate bvs-slash-strategy contract. This contract is responsible for sizing the slashing request and formulating the validation request to the resolver. The following information is passed to the bvs-slash-strategy by the initiating party:

• network address

• vault address

• offence - specifying which of the slashable offences that the bvs-slash-strategy can handle is being triggered

• data (optional) - data which can be used to prove that a particular slashable offence occured. Only used for objectively provable offences.

The resolver then processes the validation request from the bvs-slash-strategy and either vetoes it or submits the slash request to the vault.

For example, the resolver could be a bvs-slash-social-vote resolver which only submits slash requests that a majority of the operator set has voted for. In this case, the resolver would only pass the slashing request forward to the vault if the quorom and majority vote thresholds have been hit. If a sufficient amount of time passes before the threshold is set, then the request can be vetoed.