> For the complete documentation index, see [llms.txt](https://docs.satlayer.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.satlayer.xyz/slashing.md). # Slashing In addition to periodically distributing [rewards](/depositors/partner-rewards.md), 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 {% stepper %} {% step %} #### 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 {% hint style="warning" %} Note: This stage does **not** determine the validity of the slashing accusation.\ It only acts as the entry point for submitting a slash. {% endhint %} This is essentially a mechanism to report or raise suspicion about a potentially malicious or faulty operator. {% endstep %} {% step %} #### 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. {% endstep %} {% step %} #### 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. {% endstep %} {% endstepper %} ### Slashing Architecture {% hint style="warning" %} **WIP. Social slashing** will not be live until the end of [Phase II](broken://pages/SbyZID1YzxTepynVSNL7) and **fully programmatic slashing** will not be implemented until the end of [Phase III](broken://pages/SbyZID1YzxTepynVSNL7) {% endhint %}

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.** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.satlayer.xyz/slashing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.