Slashing
Learn more about how SatLayer enables protocols to enable slashing of restaked assets
Last updated
Was this helpful?
Learn more about how SatLayer enables protocols to enable slashing of restaked assets
Last updated
Was this helpful?
In addition to periodically distributing , Bitcoin Validated Services (BVSes) 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.
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.
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.
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.
WIP. Social slashing will not be live until the end of and fully programmatic slashing will not be implemented until the end of
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.