Bringing Slashing to Solana

Many thanks to 0xIchigo and Ashwin Sekar for reviewing earlier versions of this work.

Introduction

Slashing is a mechanism for enforcing network security by penalizing malicious or negligent validator behavior. Once misconduct is verified, a portion of the delegated stake associated with the offending validator(s) is burned.

This is a distinctive feature of Proof of Stake (PoS) networks like Solana, with no equivalent in Proof of Work (PoW), given that it depends on the protocol’s ability to directly enforce financial penalties by destroying staked assets. In PoW, there is no analogous mechanism, as the blockchain cannot confiscate or destroy the physical mining hardware of dishonest actors.

Slashing provides several key benefits:

• It acts as a direct economic disincentive against malicious activity
• It incentivises stakers to distribute their stake amongst reputable validators, improving decentralization
• It incentivises larger operators to build heterogeneous infrastructures that reduce the risk of shared faults (e.g., splitting their stake between Firedancer and Agave clients).
• It provides another metric for validators to distinguish themselves and accrue reputation through avoiding slashing violations and detecting the malicious activity of other participants.

Solana, throughout its history, has relied upon a manual, community-driven consensus approach, referred to as social slashing. Under this model, if a validator behaves maliciously, for example by compromising network liveness or safety, honest participants can coordinate off-chain to initiate a hard fork, restarting the network and slashing the offender’s stake. While this method enables flexible, case-by-case judgment, it carries significant coordination overhead and is inherently reactive.

To date, no validators on Solana have been slashed. The closest Solana has come to a slashing-like event was in May 2020, two months after mainnet launch, when the Solana Foundation voluntarily burned 11.36 million SOL from its own allocation in response to community concerns about undisclosed token loans to market makers. This reduced the total token supply by 2.3%, from 500 million to 488.64 million SOL. While not a formal slashing event, the burn functioned as a self-imposed penalty aimed at restoring trust and addressing transparency issues raised by the early community.

For several years, there have been calls for Solana to adopt a more formal slashing mechanism, often referred to as programmatic slashing, enforced directly on-chain through an enshrined program. Under this system, if a validator violates specific protocol rules, a cryptographic proof of the infraction can be generated and submitted to a dedicated program, which then automatically triggers the slashing. This model reduces reliance on human coordination and enables enforcement for minor infractions without disrupting network operations, paving the way for scalable, decentralized accountability.

The upcoming feature gate activation of SIMD-0204: Slashable Event Verification marks Solana’s first big, meaningful step toward implementing formal programmatic slashing on mainnet. As we’ll explore later in this report, programmatic slashing events on blockchain networks are thankfully rare, and penalties are usually minor. However, even the mere possibility of a validator’s stake being automatically destroyed by the protocol introduces new risks that all stakeholders must carefully weigh. There are many open questions about the optimal approach for Solana to enforce programmatic slashing. Like all economic changes, the parameters and penalties associated with slashing will require extensive community discussion and must ultimately be approved through a formal governance vote.

Slashing Related SIMDs

Several SIMDs relate to the rollout of programmatic slashing on Solana, with the initial two, SIMD-180 and SIMD-204, scheduled to go live on mainnet in the coming months.

First, is the prerequisite SIMD-0180: Use Vote Account Address to Key Leader Schedule. This SIMD shifts the key used in the leader schedule from the validator’s identity address to its vote account address. This change is essential for accurate slashing attribution, as it creates a direct, unambiguous link between a validator’s block production duties and their delegated stake.

SIMD-0204: Slashable Event Verification outlines a new Slashing Program. This introduces an on-chain mechanism that allows anyone to submit and log evidence of slashable behavior, creating a verifiable, immutable record of validator misbehavior.

Finally, SIMD-0212: Slashing outlines the implementation of slashing within the Solana protocol. It builds on the foundation laid by SIMD-0204 to apply penalties for verified violations. This proposal remains open and is still under active discussion.

Fault Detection and Attribution

The Slashing Program is designed as a purely observational layer. It does not modify stakes or rewards; its sole function is to verify and record infractions. An early prototype is already live on Testnet, with sample submissions (e.g., DuplicateBlockProof transactions) demonstrating how violations can be recorded.

Duplicate Block Production

In its initial rollout, the program will focus on a single type of malicious behavior: detecting instances of duplicate block production. This is when a leader submits two or more different versions of a block for the same slot, which is a clear and objective consensus violation. 

Previously, in September 2022, a network outage was triggered by a validator erroneously producing duplicate blocks at the same block height. This occurred because both the validator’s primary node and its fallback spare node became active simultaneously, using the same node identity but proposing different blocks.

This issue has since been patched, and today, even in cases where an operator is running a hot spare, the validator client includes safeguards to shut down if multiple instances are detected. As such, producing duplicate blocks would be extremely unlikely without deliberate, malicious modification of the validator software.

Duplicate block production is an example of a protocol violation that is challenging to detect in real time but straightforward to verify after the fact. Attempting to coordinate a synchronous response, where the network halts to confirm collective observation of the duplicate, would introduce significant complexity. Instead, handling detection and slashing retroactively is far more practical.

Submitted proofs for duplicate blocks include two conflicting shreds for the same slot, both signed by the same validator. The slashing program verifies the proof by ensuring the shreds form a valid duplicate block proof, confirming they belong to the same slot and are correctly signed by the offending validator. This logic mirrors the approach used in Solana’s gossip protocol for handling duplicate block proofs in the fork choice process.

struct DuplicateBlockProofData {
  shred1_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred1: &[u8]           // `shred1_length` bytes representing a shred,
  shred2_length: u32      // Unaligned four-byte little-endian unsigned integer,
  shred2: &[u8]           // `shred2_length` bytes representing a shred,
}

The reporter constructs a proof and stores it in an on-chain buffer account, then submits a transaction to the slashing program at address `S1ashing11111111111111111111111111111111111` referencing their buffer account. Once a proof is successfully verified, the results are stored in a `report_account` Program Derived Address (PDA) owned by the Slashing program for future reference. This makes it easy to build dashboards that surface slashing-related data by simply running a getProgramAccounts call on the slashing program. Validators can use these to check if they've been reported for violations and take corrective action as needed.

It is expected that Anza will release tooling to enable the observation of these events, creation of proofs, and submission of the proof on-chain. There will likely be multiple implementations, including a version embedded in the validator software. It is only necessary for a single honest participant to report a violation within an epoch, as each unique violator and slot combination can only be reported once. The program verifies whether a report for the same slot and violator already exists. If a matching report is found, the new submission is rejected. Reports can be submitted up to one epoch after the violation occurred, based on the slot where it happened (i.e., up to 432,000 slots later, as tracked by the `Clock` sysvar).

Whistleblower Rewards

A common question in slashing design is whether those who report violations (i.e., whistleblowers) should be rewarded. While rewarding whistleblowers may appear to be a straightforward incentive mechanism, it comes with notable challenges.

On Solana, where leaders control transaction inclusion, a whistleblower reward creates a frontrunning risk. Suppose a validator submits a valid slashing proof to the current block leader. In that case, the leader can simply copy the proof, submit it themselves, and censor the original transaction, claiming the reward without doing the work. This undermines the incentive model and opens the door to abuse.

Ethereum offers a small whistleblower reward: 1/512 of the slashed validator’s effective balance. For a validator with the full 32 ETH, this equals 0.0625 ETH. The reward is minted as new ETH, but is offset by the larger amount burned from the slashed validator’s stake. The low value is intentional as it is meant to promote integrity and honest participation, rather than opportunistic behavior driven by profit.

Voting Violations

Future versions of the Slashing Program are expected to expand support for various types of voting violations, such as lockout violations and switching proof violations.

A lockout violation occurs when a validator votes on two separate forks without waiting for the appropriate amount of time for their tower lockout to expire. Under Solana’s current consensus algorithm, TowerBFT, once a validator votes for a particular fork at a given slot, it becomes "locked out" of voting on competing forks for a certain duration. If this validator later votes for a different fork before their lockout period expires, it violates the lockout rule.

The Votalizer bot, developed by Solana co-founder Michael Vines, currently operates in the Solana Tech Discord, tracking lockout violations as they occur across the network. In practice, it's rare for validators to commit such violations unintentionally, as doing so would typically require deliberate modification of the validator client. Built-in safeguards ensure the client retrieves its most recent on-chain vote and prevents actions that would result in a lockout violation.

While lockout violations are explicitly mentioned in the Slashing SIMD and early documentation as an example of a voting violation that the slashing program may address, the planned Alpenglow consensus update will remove Tower BFT, eliminating the concept of lockouts. For this reason, voting violations are expected to be introduced only after Alpenglow launches.

Newer Alpenglow voting violations, which the slashing program could be designed to detect, may include actions such as submitting conflicting votes for the same slot, for example, casting both a `NotarVote` and a `SkipVote`.

Future Violation Types

Programmatic slashing must be tied to verifiable and unambiguous instances of misbehavior. This, unfortunately, makes enforcement of more subjective or systemic issues, such as deliberate slow production of blocks or harmful forms of MEV extraction, significantly more challenging.

Across peer blockchain networks, the types of behavior that typically result in slashing vary by protocol. Common examples include:

• Double Signing: Producing two conflicting blocks at the same height or slot.
• Downtime: Going offline and failing to participate in consensus.
• Surround Voting: Casting votes that conflict with earlier ones in an attempt to manipulate or destabilize the network.

A novel slashing proposal, put forward last year by Helius’ own 0xIchigo, suggested penalizing validators within the supermajority who fail to participate in formal governance votes, aiming to incentivize greater engagement. While this approach meets the requirement of being objectively verifiable, several commenters raised concerns. Some pointed out that legal constraints may prevent certain validators from voting. Others argued that slashing should be strictly limited to behavior that poses a direct threat to the network’s security or integrity.

Penalty Enforcement

Once Solana has a reliable on-chain mechanism for reporting and verifying slashable offenses, the next priority is the economic enforcement of slashing, defining the precise parameters and penalty formulas for different types of violations.

Guidelines are still being actively discussed, and the content presented in this section reflects current proposals intended to inform, encourage dialogue, and evolve based on community feedback. As these decisions directly affect the economics of operating a Solana validator, any changes will undergo public community debate and must be approved through a formal governance process.

When determining slashing penalties, a key principle is to avoid punishing rare, one-off operator errors too harshly. Ideally, the penalty system should have a buffer of tolerance for minor incidents that do not impact consensus with appropriate safeguards, rather than enforcing severe penalties for honest mistakes.

The current consideration for this buffer is the Nakamoto Coefficient (NC) line, which is set at the stake level of the smallest validator in the superminority (i.e., approximately 1% of stake). 

Under the proposed function, which determines the amount of each delegation slashed per vote account, if the total stake committing a violation is less than the NC line, no stake is slashed. Conversely, if consensus is at risk, meaning over one-third of the total stake is involved in violations, the protocol should respond decisively by slashing 100% of the offending stake.

For cases that fall between these extremes, the current proposal introduces a quadratic penalty function with a slow growth rate. The formula used to calculate the fraction of stake to be slashed for each vote account is as follows:

v = slashable vote account

TSS = Total Slashable Stake

TS = Total Stake

NC line = Nakamoto Coefficient Line

Under this formula, the percentage of stake to be slashed from the offending validator can be calculated as:

• 1.2% when 4.66% stake is in violation (i.e., (3 * (0.0466 - 0.01) / 1)²)
• 7.3% when 10% of stake is in violation (i.e., (3 * (0.1 - 0.01) / 1)²)

The chart below illustrates the proposed curve with two alternatives (aggressive and linear).

Total slashable stake (TSS) is calculated using a weight based on the type of violation. Voting violations are penalized at a weight of 1 as they are less severe. Duplicate block violations are weighted at 10, as they are considered more severe.

A key advantage of quadratic, correlated slashing penalties, such as the one currently proposed, is that they incentivize those running multiple validators, such as exchanges or staking-as-a-service providers, to maintain high-quality, independent infrastructure to minimize the risk of widespread, correlated failures.

Alternatives to Traditional Slashing

Slashing delegated stake introduces important questions around fairness and accountability. In the current staking model, the vast majority, if not all, of the stake at most non-private validators is delegated. This means that when slashing occurs, it is typically the delegators, not the validator operators who committed the violation, who bear the brunt of the penalty. Even diligent stakers who choose reputable validators could potentially be slashed through no fault of their own if a validator acts maliciously or misconfigures their node.

To address this imbalance, several alternative slashing designs have been proposed. One such approach is to require all validators to maintain a minimum level of self-stake. This ensures operators have skin in the game and can’t externalize the full cost of slashing onto their delegators. A stricter version of this approach would be to slash only self-stake, while automatically destaking all delegators associated with a slashed validator. Delegators would lose out on rewards but retain their principal, allowing them to reallocate their stake to another validator with minimal long-term impact.

Another approach is to freeze accounts for a defined period, during which they are unable to earn rewards, change ownership, or withdraw funds. The duration of the freeze would increase with the severity of the offense. Alternatively, the protocol could slash future rewards, reducing the validator’s and its delegators’ earnings over a set duration without touching the principal stake.

Some have proposed redistributing slashed stake to honest validators as a form of positive reinforcement, rather than burning it. However, burning SOL effectively achieves a similar outcome as it reduces total supply, thereby increasing every holder’s relative share of network ownership.

Considerations

The introduction of slashing on Solana carries several important implications. In this section, we explore two critical areas: cooldown periods and the resulting risk, insurance, and operational burden for ecosystem participants.

Cooldown Periods

A key vulnerability in the current staking model arises when a validator commits a slashable offense but unstakes before the violation is observed and reported. Without a mechanism to delay withdrawal, malicious actors could potentially exploit this timing gap to escape punishment.

A cooldown period during which stake remains eligible for slashing even after deactivation would mitigate this. This cooldown must exceed the worst-case time required for validators or external observers to detect and coordinate a slashing response, particularly under adversarial conditions such as network-level DDoS attacks or collusion among malicious validators. In practice, this means cooldown periods should last multiple days.

Solana's reliance on precomputed stake snapshots exacerbates this issue. Several critical protocol components, including the leader schedule and fork choice rule, rely on stake values calculated in advance. As a result, deactivated or even fully withdrawn stake can still influence consensus.

For instance, the leader schedule is derived from a prior snapshot of stake taken one epoch in advance at the epoch boundary. This creates a window where a validator could commit a slashable offense, having already deactivated their stake in the prior epoch and withdrawn it at the start of the current one. By the time the violation is uncovered, there is already no active stake left to penalize.

A solution would be to introduce an additional cooldown period where stake remains slashable but no longer counts toward the protocol’s stake weight. Stakers deactivating their stake in epoch N, but will only be able to withdraw stake at the beginning of epoch N+3. While this improves security, such a delay creates a poor user experience by forcing stakers to wait an extra ~2-4 days before they can fully withdraw their stake. One way to address this would be to shorten epochs to preserve similar real-time unstaking delays to the current standard. However, any reduction in the duration of epochs could have unforeseen protocol implications and would need to be carefully assessed.

Risk, Insurance, and Operational Burden

The introduction of slashing on Solana carries implications for a wide range of ecosystem participants, particularly those who custody, manage, or build financial products on top of staked SOL. Even the potential for slashing can introduce financial risk, operational complexity, and reputational concerns, particularly for institutions operating under fiduciary or regulatory constraints. These risks can be addressed through safeguards such as insurance or bonds.

Stakeholders potentially affected include:

• Liquid staking protocols
• Stake pools
• Custodial staking providers
• Restaking protocols
• DeFi protocols
• Staking ETFs

For some of these entities, a slashing event could have cascading consequences. For example, liquid staking tokens (LSTs) are backed by the assumption that underlying validators perform safely. If a validator is slashed, it could trigger a sharp repricing of their LST or, in extreme cases, a depeg if confidence collapses in the validator at which the underlying SOL is staked. This could lead to liquidations if the LST is being used as collateral on a lending protocol.

It is common for staking providers in other ecosystems to offer slashing insurance to mitigate these risks. On Ethereum, for example, many providers make affordable coverage available to protect against slashing losses, with protection levels varying by coverage plan.

Slashing risk also introduces new operational responsibilities across the staking value chain. Those impacted include:

• Staking service operators, who must now monitor validator behavior and mitigate risks proactively
• Custodial platforms and crypto exchanges, which depend on third-party operators and may need to vet and diversify their validator sets
• Institutional asset managers, who may seek own-loss coverage to protect against slashing-related losses caused by external operators

Comparison with Peer Networks

This section examines how slashing is implemented on peer Proof of Stake networks such as Ethereum and Cosmos. These networks have enforced programmatic slashing for many years, offering valuable real-world data on the frequency of slashing events and their impact on network security and validator behavior.

Ethereum

Ethereum’s Proof of Stake protocol, introduced with the launch of the Beacon Chain in December 2020, has included slashing as a core enforcement mechanism from day one. Ethereum defines four specific slashable offenses, all centered around equivocation:

• Proposing multiple blocks for the same slot
• Submitting conflicting attestations for the same target checkpoint
• Attesting to different head blocks with the same source and target checkpoints
• Creating two attestations where one “surrounds” the other in terms of source and target votes

Each of these offenses carries the same penalty structure. When a validator is slashed, an immediate penalty of 1/32 of their effective balance is applied, capped at 1 ETH, due to the maximum effective balance of 32 ETH. The validator is then forcibly exited from the active set and placed in the exit queue for roughly 36 days.

During this period, the validator is inactive and cannot withdraw funds. It continues to lose rewards it would have earned if active, effectively experiencing a steady opportunity cost. After 18 days, an additional correlation penalty is applied, designed to escalate in proportion to the number of validators slashed within a 36-day window. If only a few validators are slashed, the penalty is minor. However, in the case of mass slashing events, whether through coordinated misbehavior or shared infrastructure failures, the penalties scale dramatically and could, in the worst-case scenario, result in the loss of nearly the validator’s entire staked balance.

Despite its centrality in Ethereum's protocol, slashing is extremely rare in practice. As of May 2025, only 484 validators, less than 0.05% of the total validator set, had been slashed across 131 incidents. These incidents often stemmed from a single error affecting multiple validators and were typically the result of operator mistakes or software bugs, not malicious intent.

The largest slashing event occurred in November 2023, when Bitcoin Suisse saw 100 validators slashed for inactivity-related offenses, each losing 1 ETH.

To date, no slashing incident on Ethereum has threatened the protocol’s overall integrity. This suggests that while slashing is an essential deterrent, its actual enforcement is infrequent, and the validator ecosystem has largely internalized the behaviors required to avoid these penalties.

Cosmos

Cosmos and Cosmos SDK-based chains, such as the Cosmos Hub, implement slashing as a built-in security mechanism targeting two principal faults: double-signing and extended downtime. These slashing rules serve to enforce both safety and liveness properties of the protocol.

A validator that signs two different blocks at the same height faces immediate punishment. Any participant can submit on-chain evidence of the violation, and once verified, the validator is automatically slashed 5% of their staked tokens and placed in a tombstoned state, meaning they are permanently removed from the active validator set and cannot re-enter. Once tombstoned, both the validator and its delegators must wait out the unbonding period before their stake can be redelegated. While a tombstoned validator operator can relaunch under a new key, they must rebuild their reputation and delegations from the ground up.

Cosmos also enforces liveness through automatic slashing for prolonged downtime. If a validator signs less than 5% of the last 10,000 blocks, it is considered inactive and penalized with a 0.01% stake slash. While minor in comparison, this enforcement is strict and non-negotiable, ensuring validators maintain uptime and reliable participation in consensus.

Interestingly, some validators opt to take this minor penalty as a cost of voluntarily shutting down operations, viewing the loss as negligible.

While Cosmos SDK networks share standard default slashing parameters, individual chains can modify or extend these rules to reflect their own security assumptions and risk models. This flexibility allows each network to calibrate its slashing system according to its validator set size, decentralization goals, or expected fault tolerance. Slashing activity across 57 Cosmos SDK-based mainnets provides a broader view of enforcement across the ecosystem:

• 12,143 downtime-related slashes
• 111 double-signing slashes
• 326 other infractions
• 12,580 total slashing incidents

These figures demonstrate that while double-signing is rare and heavily penalized, downtime slashing is more frequent and viewed mainly as a routine operational cost. 

Conclusion

Slashing remains one of the most debated and emotionally charged topics in the blockchain industry. Whenever new forms of validator misbehavior or incentive misalignment emerge, calls for slashing are quick to follow. It's easy to see why, on the surface, slashing appears to be a powerful deterrent, offering a direct, on-chain mechanism to punish bad actors and uphold network integrity.

However, as this article has illustrated, programmatic slashing is far from a silver bullet for misbehavior. Its effectiveness relies on the offenses being both unambiguous and provable, conditions that are not always easy to meet in complex, real-world situations. Slashing in cases where evidence is unclear or open to interpretation risks punishing honest actors, destabilizing trust, and potentially causing more harm than the violations it seeks to prevent.

Arguably, the greatest value that automated forms of slashing bring to a network is the psychological impact on stakeholders. Even the mere possibility of economic loss for any form of violation, no matter how rare, can be enough to push risk-averse stakers to spread their delegations across multiple validators, while motivating operators to invest in diverse, independent infrastructure.

Further Resources

• Slashing: Panacea or Pandora's Box? - Tim Roughgarden, Accelerate Conference
• The Economic Limits of Permissionless Consensus - Eric Budish, Andrew Lewis-Pye, Tim Roughgarden 
• Accountable Liveness - Andrew Lewis-Pye, Joachim Neu, Tim Roughgarden, Luca Zanolini