Contenu source (brut)
<p>Many thanks to 0xIchigo and Ashwin Sekar for reviewing earlier versions of this work.</p><h2>Introduction</h2><p>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.</p><p></p><p>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.</p><p></p><p>Slashing provides several key benefits:</p><ul class="list-bullet"><li value=1>It acts as a direct economic disincentive against malicious activity</li><li value=2>It incentivises stakers to distribute their stake amongst reputable validators, improving decentralization</li><li value=3>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).</li><li value=4>It provides another metric for validators to distinguish themselves and accrue reputation through avoiding slashing violations and detecting the malicious activity of other participants.</li></ul><p></p><blockquote><p>My view is that slashing is a stick, inflation is a carrot and both should be incentivizing decentralization.</p><cite>Anatoly Yakovenko, Solana Co-Founder</cite></blockquote><p></p><p>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.</p><p></p><p>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 <a href="https://orb.helius.dev/tx/45pGoC4Rr3fJ1TKrsiRkhHRbdUeX7633XAGVec6XzVdpRbzQgHhe6ZC6Uq164MPWtiqMg7wCkC6Wy3jy2BqsDEKf?cluster=mainnet-beta&tab=summary"><span style="text-decoration: underline">burned 11.36 million SOL</span></a> 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 <a href="https://medium.com/solana-labs/solana-will-reduce-its-token-supply-to-account-for-market-making-allocation-b8366288acef"><span style="text-decoration: underline">transparency issues raised by the early community</span></a>.</p><p></p><p>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.</p><p></p><p>The upcoming feature gate activation of <a href="https://github.com/solana-foundation/solana-improvement-documents/pull/204"><span style="text-decoration: underline">SIMD-0204: Slashable Event Verification</span></a> 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.</p><p></p><h3>Slashing Related SIMDs</h3><p>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.</p><p></p><p>First, is the prerequisite <a href="https://www.helius.dev/blog/agave-v23-update--all-you-need-to-know#leader-schedule-keyed-by-vote-accounts"><span style="text-decoration: underline">SIMD-0180: Use Vote Account Address to Key Leader Schedule</span></a>. 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.</p><p></p><img src="/_next/image?url=/api/media/file/slashing-related-SIMDs.PNG&w=3840&q=90" alt="Slashing Related SIMDs" /><p></p><p><a href="https://github.com/solana-foundation/solana-improvement-documents/pull/204"><span style="text-decoration: underline">SIMD-0204: Slashable Event Verification</span></a> outlines a new <a href="https://github.com/solana-program/slashing"><span style="text-decoration: underline">Slashing Program</span></a>. 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.</p><p></p><p>Finally, <a href="https://github.com/solana-foundation/solana-improvement-documents/pull/212/commits/297bcd403d3502c01e1c55239971c6cdc81490b4"><span style="text-decoration: underline">SIMD-0212: Slashing</span></a> 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.</p><h2>Fault Detection and Attribution</h2><p>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 <a href="https://orb.helius.dev/address/8sT74BE7sanh4iT84EyVUL8b77cVruLHXGjvTyJ4GwCe/history?cluster=testnet&page=1"><span style="text-decoration: underline">live on Testnet</span></a>, with sample submissions (e.g., <a href="https://orb.helius.dev/tx/2A6cdwon8673NKfDE4oKFjovvyp613LZKkCPbDYchxUGWoj5RkLqpCfQpmv1tkGqKZx9YLKTtNBBrRxWKnSLpeo1?cluster=testnet&tab=logs"><span style="text-decoration: underline">DuplicateBlockProof transactions</span></a>) demonstrating how violations can be recorded.</p><h3>Duplicate Block Production</h3><p>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. </p><p>Previously, in September 2022, a <a href="https://www.helius.dev/blog/solana-outages-complete-history#duplicate-block-bug-september-2022"><span style="text-decoration: underline">network outage</span></a> 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 simultaneous
