Solana Validator Slashing: Does SOL Have It?

Solana validator slashing was not active at the protocol level at the source's last review in June 2025. This article preserves that dated finding and identifies what readers must verify before relying on it.

This content is for informational purposes only and does not constitute financial advice. Cryptocurrency staking involves risk, including the potential loss of staked assets. Consult a qualified financial advisor before making investment decisions.

Last updated: June 2025

If you stake SOL and have recently come across the phrase "Solana validator slashing," here is the direct answer: as of June 2025, Solana does not implement protocol-level validator slashing. Your delegated SOL cannot be automatically reduced by the protocol because of your validator's behavior. This article covers what slashing means, Solana's current status, how Tower BFT handles misbehavior instead, what risks actually exist for delegators today, how Marinade Finance and Jito fit in, and how Solana compares to Ethereum, Cosmos, and Polkadot.

Key Takeaways

• As of June 2025, Solana does not implement protocol-level validator slashing
• Your delegated SOL cannot be automatically reduced by the protocol due to your validator's misbehavior today
• Solana uses Tower BFT lockout mechanics to deter validator misbehavior instead of direct token penalties
• Governance proposals called Solana Improvement Documents (SIMDs) to introduce slashing exist but have not been implemented
• Liquid staking protocols like Marinade Finance and Jito spread stake across many validators, reducing single-validator exposure

Contents

• What Is Validator Slashing?
• Solana Validator Slashing: Does Solana Currently Have It?
• How Solana Handles Validator Misbehavior: Tower BFT and Lockout Mechanics
• What Solana's Slashing Status Means for Stakers and Delegators
• Liquid Staking and Slashing Risk: Marinade Finance and Jito
• Solana vs. Ethereum, Cosmos, and Polkadot: How Slashing Compares
• Validator Best Practices: How to Avoid Slashing Conditions on Solana
• Solana Slashing Governance: SIMD Proposals and What They Mean
• Frequently Asked Questions About Solana Validator Slashing
• Conclusion: Is Solana Staking Safe From Slashing Today?
• Glossary

What Is Validator Slashing?

Definition: Validator slashing is a protocol-level penalty mechanism in Proof of Stake (PoS) blockchains that automatically reduces a validator's staked tokens as punishment for provable misbehavior. It is designed to make dishonest behavior financially irrational by ensuring validators lose more than they could gain from manipulating the network.

On a blockchain like Solana, validators are the nodes responsible for processing transactions and reaching consensus on the network's state. Validator slashing is fundamentally a network security mechanism: by making dishonest behavior financially costly, it deters validators from attempting to manipulate the blockchain. In Proof of Stake (PoS) systems, validators put up tokens as a security deposit to participate. Unlike Bitcoin, which uses Proof of Work where miners compete to solve mathematical puzzles, stake-based consensus systems hold validators financially accountable through their locked capital. Slashing is what happens when they break the rules. For the broader network context, see what a Solana validator is.

Two conditions trigger slashing in most PoS networks. Equivocation (commonly called double voting) occurs when a validator signs two conflicting votes or blocks for the same slot, trying to support two different versions of the blockchain at once. Surround voting is the second condition: a validator signs attestations that contradict previously signed ones. Both behaviors undermine consensus finality and, at scale, could enable double-spending attacks.

The Economic Logic Behind Slashing

Slashing exists because validators post staked tokens as collateral. A validator who stands to lose more by misbehaving than they could gain by cheating has no rational incentive to cheat. Byzantine Fault Tolerance (BFT) is the theoretical computer science framework underlying distributed consensus systems, named after the Byzantine Generals Problem, a thought experiment about coordinating actors who may be traitors. Tower BFT is Solana's specific implementation of BFT-class consensus. Slashing enforces BFT properties by converting equivocation from a theoretical risk into a financially irrational act. On networks like Ethereum, delegators who lend their stake to validators also share proportionally in slashing penalties, which raises the question of whether SOL delegators face the same exposure on Solana.

Solana Validator Slashing: Does Solana Currently Have It?

Last updated: June 2025

As of June 2025, Solana does not implement protocol-level validator slashing. Solana currently has no mechanism that automatically burns or reduces a validator's staked SOL as a penalty for misbehavior. Validators cannot be slashed at the protocol level under Solana's live code.

This is a deliberate design characteristic, not an oversight. Solana's architecture provides deterrence through Tower BFT's lockout mechanism, and the developer community has actively debated whether adding financial slashing penalties is worth the operational complexity it introduces in a high-throughput environment. That debate now has a formal track: Solana Improvement Documents (SIMDs) have proposed introducing slashing, but none have been implemented. For full governance tracking, see the SIMD governance section below.

Three categories of validator consequences exist on Solana:

1. Protocol-level slashing (does not exist on Solana as of June 2025): automatic reduction of staked tokens
2. Social and economic penalties (live): validators who misbehave lose delegations as delegators withdraw their stake
3. Governance-proposed slashing (proposed via SIMD, not yet implemented): what would exist if a relevant SIMD is accepted

Why Solana Has Not Implemented Slashing

Solana's architecture provides deterrence against equivocation through Tower BFT's lockout mechanism, but implementing financial penalties in a high-throughput environment introduces operational risks the community has actively weighed. Validators in high-performance systems face greater exposure to false-positive slashing conditions from network latency, software restarts, or infrastructure failures. The governance discussion has considered whether these operational risks outweigh slashing's security benefits, and as of June 2025 the question remains unresolved through formal governance channels.

How Solana Handles Validator Misbehavior: Tower BFT and Lockout Mechanics

Solana's approach to validator misbehavior runs through Tower BFT, and understanding that mechanism explains both why equivocation is structurally difficult on this network and why no financial penalty currently accompanies detection.

Proof of History: Solana's Cryptographic Clock

Proof of History (PoH) is a cryptographic timekeeping mechanism created by Solana co-founder Anatoly Yakovenko. It functions as a verifiable clock for the network, not as a consensus mechanism. PoH creates a historical record proving that a specific sequence of events occurred at a specific time, allowing validators to agree on ordering without constant back-and-forth communication. Tower BFT, the consensus mechanism, is built on top of this clock. Solana uses a hybrid architecture combining Proof of History as its timekeeping layer with Tower BFT as its consensus layer, rather than standard Proof of Stake.

Tower BFT: Solana's Consensus Protocol

Tower BFT is Solana's consensus protocol, the system validators use to agree on the state of the blockchain. Built on top of Proof of History, it uses exponentially increasing lockout windows to make voting on multiple competing blockchain versions economically irrational. Lockout windows are the Tower BFT mechanism that prevents a validator from voting on competing forks after committing to one.

The lockout mechanism works as follows:

1. A validator casts a vote on Fork A of the blockchain
2. That vote carries a lockout window, initially 2 slots, during which the validator cannot vote on a competing fork
3. Each subsequent vote on the same fork doubles the lockout: 4 slots, then 8, then 16, continuing exponentially
4. Abandoning Fork A to vote on Fork B before the lockout expires is a lockout violation

The deeper a validator's tower of votes on a given fork, the longer it must wait before switching. This commitment mechanism makes reversing a prior vote progressively more costly in time, not just reputation.

Validators earn vote credits for timely, accurate votes. Missing votes reduces credits and thus reduces staking rewards proportionally. This vote credit system is Solana's live soft penalty mechanism, affecting rewards without touching staked principal.

The Tower BFT lockout mechanism: each validator vote on a fork carries an exponentially increasing lockout window. A lockout violation constitutes equivocation.

Equivocation and Lockout Violations

Equivocation (commonly called double voting) occurs when a validator signs two conflicting votes or blocks for the same slot, attempting to support two different versions of the blockchain at the same time. A lockout violation specifically refers to a validator voting on a competing fork before the Tower BFT lockout window expires.

The detection-to-consequence sequence under the current protocol:

1. Validator casts votes on Fork A, building an exponentially increasing lockout
2. Validator signs a vote on Fork B before the lockout expires
3. PoH timestamps make both votes cryptographically provable
4. Protocol detects the conflicting signatures as equivocation
5. Validator loses vote credits for the affected period; staked SOL is not reduced

This is the architectural gap that SIMD slashing proposals seek to close. Under proposed slashing implementations, step 5 would add automatic token burning from both the validator's own stake and proportionally from delegated stake.

A stake account is a Solana-specific on-chain record that holds a delegator's staked SOL and tracks their delegation to a specific validator. Under a slashing implementation, the stake account would be directly debited if a validator is penalized.

What Solana's Slashing Status Means for Stakers and Delegators

As of June 2025, your staked SOL is not at risk of reduction through slashing. Solana does not implement this mechanism. For institutional allocators, slashing currently represents no material financial risk to SOL staking positions. Your principal balance cannot be automatically burned by the protocol because of your validator's behavior. That picture would change if SIMD slashing proposals are accepted: under current drafts, delegators would face proportional principal exposure alongside validators.

Validator performance does affect your staking rewards. A poorly performing or delinquent validator (one that misses votes due to downtime) earns fewer vote credits, which reduces the approximately 5–8% APY your stake earns. The distinction between reward risk and principal risk is the key to assessing Solana staking accurately. Delegators can apply the checklist in how to choose a Solana validator.

Delegators vs. Validators: Who Bears the Risk?

Most SOL holders who stake are technically delegators. The exposure profile differs by role. Validators face direct protocol penalties under any slashing framework; delegators face derived exposure proportional to their stake share. On networks with live slashing, both categories bear financial risk. On Solana today, neither does at the protocol level.

A validator is the entity that runs the node and casts consensus votes. Under any slashing implementation, the validator would be the primary penalized entity. A delegator lends their SOL to that validator's pool and earns rewards in proportion to their stake share. Under most proposed slashing implementations, delegators would be affected proportionally alongside the validator's own stake. If a validator were slashed 5% of their total stake pool, and you had 100 SOL delegated, you could lose approximately 5 SOL.

Under proposed Solana slashing implementations, delegators would be proportionally affected. If a validator is slashed a percentage of their total stake pool, delegators lose the same percentage of their delegated SOL.

Real Risks That Exist for Delegators Today

Several financial risks exist for delegators today, even without slashing. They affect staking rewards rather than your principal balance:

1. Validator delinquency: a validator missing votes earns fewer vote credits, reducing your APY for the affected epoch (an epoch is approximately 2–3 days in Solana's protocol)
2. Unbonding period: staked SOL cannot be withdrawn immediately; Solana's unbonding period is approximately 2–3 days, during which your tokens remain locked in your stake account
3. Commission rate: validator commission is the percentage of staking rewards the validator retains before passing the remainder to delegators; a 10% commission means 10% of earned rewards, not 10% of principal
4. Solana program risk: staking is governed by an on-chain program (equivalent to a smart contract on other networks); protocol bugs, while historically rare, represent a theoretical risk to staked assets (exchanges offering SOL staking products also face slashing exposure considerations in their validator selection and custody design)

Currently, the absence of slashing is itself a protection for institutional and retail delegators alike. Selecting reputable validators and diversifying through liquid staking protocols are the primary risk mitigation approaches available today.

For a comparison of how Solana's risk profile stacks up against Ethereum and Cosmos, see how Solana compares across PoS networks.

How to Evaluate and Choose a Safe Solana Validator

When evaluating a Solana validator, six criteria give the clearest picture of reliability and risk:

1. Check uptime and delinquency rate: target validators with above 95% uptime using Stakewiz, Solana Beach, or Validators.app
2. Review vote credits per epoch: consistent, high vote credits signal reliable participation in consensus
3. Compare commission rates: 0–10% is the standard range; factor this in alongside performance metrics, not independently
4. Check stake concentration: avoid delegating to validators holding above 10% of total network stake, as this increases network centralization risk
5. Review the validator's track record: look for a clean history without extended delinquency periods
6. Consider liquid staking via Marinade Finance or Jito for automatic diversification across many validators simultaneously

Liquid Staking and Slashing Risk: How Marinade Finance and Jito Handle It

Liquid staking protocols pool delegated SOL across many validators and issue a tradeable liquid staking token (LST) representing your underlying stake. Marinade Finance issues mSOL; Jito issues jitoSOL. Rather than locking your SOL with a single validator, these protocols spread your stake across their validator pools automatically.

How Liquid Staking Diversification Reduces Single-Validator Exposure

Marinade Finance and Jito distribute stake across large validator pools. A single validator's misbehavior affects only a small fraction of the total pooled stake rather than your entire position. If one validator in a pool of 100 were slashed 5% of their own stake, only 1/100th of the pool's exposure would be affected at that validator. This structural diversification reduces concentration risk relative to delegating everything to a single validator.

As of June 2025, with no live slashing on Solana, this diversification operates primarily as a forward-looking protection mechanism. Both Marinade Finance and Jito employ validator selection criteria and monitoring to avoid delinquent or underperforming validators, which protects your staking rewards today regardless of slashing status.

Marinade Finance (mSOL) and Jito (jitoSOL): Protocol-Specific Coverage

Marinade Finance and Jito approach slashing risk differently based on their validator selection methodologies and pool compositions.

Marinade Finance uses an automated stake delegation strategy that scores validators across performance metrics including vote credit rate, commission, and stake concentration. According to Marinade Finance documentation, the protocol distributes stake across a large validator set and applies scoring criteria to minimize exposure to underperforming validators. mSOL holders would be affected proportionally if any validator in the pool faced slashing, but the impact per holder would be a fraction of what a single-validator delegator would face.

Jito's validator pool focuses on MEV (maximal extractable value) infrastructure, with validators running Jito's software stack. According to Jito staking documentation, jitoSOL holders benefit from pool diversification. Jito's MEV-focused validator composition has unique characteristics: the validator set may differ from general Solana validator pools in its composition and operational profile.

Direct staking and liquid staking represent different risk profiles, not a clear hierarchy of safety. Neither Marinade nor Jito eliminates future slashing exposure, and both introduce Solana program risk that direct staking does not carry. A protocol bug or governance vulnerability would represent a separate category of risk. Readers who prefer a custodial earning product can also review Bybit Earn, where available; compare current terms, withdrawal conditions, and custody risks before deciding.

Solana vs. Ethereum, Cosmos, and Polkadot: How Slashing Compares Across PoS Networks

Three of the five major PoS networks compared below have live slashing. Solana and Cardano do not, as of June 2025. This single structural fact accounts for the primary difference in principal risk exposure for delegators across these networks.

Ethereum's Beacon Chain: Live Slashing Since The Merge (2022)

Ethereum's Beacon Chain is the PoS consensus layer introduced with The Merge in September 2022. Solana does not implement slashing; Ethereum has had it live since The Merge. On the Beacon Chain, two conditions trigger slashing: double proposals (a validator proposes two different blocks for the same slot) and surround voting (a validator signs an attestation contradicting a previously signed one). The minimum initial penalty is 1/32 of the validator's effective balance, and correlation penalties scale upward when many validators commit the same offense in the same period. Slashed validators face a withdrawal queue delay before their remaining stake is removed. See the Ethereum Beacon Chain penalty documentation for full specification details.

Ethereum requires a minimum of 32 ETH to run a validator directly; Solana has no minimum stake requirement. For a broader comparison of these two networks, see Solana vs Ethereum.

Multi-chain slashing comparison | Data current as of June 2025. Verify against current protocol documentation before making staking decisions.

For background on Polkadot's staking and consensus model, see What Is Polkadot?

Five PoS networks, two slashing approaches: those with live financial penalties (Ethereum, Cosmos, Polkadot) and those without (Solana, Cardano). The absence of slashing at Solana's protocol level means delegators face no principal reduction from validator misbehavior today. Proponents of the current architecture argue Tower BFT's lockout mechanism provides sufficient deterrence; critics argue that economic penalties are necessary for validator accountability at scale.

Validator Best Practices: How to Avoid Slashing Conditions on Solana

Validator delinquency, jailing, and slashing are three distinct penalty types on Solana. Only delinquency and jailing carry live consequences under the current protocol. Delegators reading this section can use it to understand what to look for in a validator's track record; for the validator selection checklist, see How to Evaluate and Choose a Safe Solana Validator.

Delinquency vs. Slashing vs. Jailing: Understanding the Difference

Slashing and jailing are distinct validator penalties with fundamentally different consequences for staked tokens.

Slashing and jailing are two distinct validator penalties. Slashing (proposed on Solana) involves a forced reduction of staked tokens as punishment for misbehavior like equivocation. Jailing is a temporary exclusion from the active validator set due to extended downtime; it does not reduce staked tokens. Jailing affects rewards; slashing affects principal.

A validator going offline for an extended period may be temporarily removed from the active set, sometimes called being jailed or excluded from the leader schedule. This differs from slashing and does not result in token loss for delegators.

Operational Safeguards for Solana Validator Operators

Seven operational safeguards reduce the risk of accidental equivocation conditions, the primary trigger for slashing under proposed SIMD implementations. For provisioning and account-security context, also review Solana validator requirements:

1. Run a single active signing key at any given time. Never have two nodes sharing the same validator identity simultaneously, as this is the primary cause of accidental equivocation.
2. Implement tower state backups. A restarted node should recover its last committed lockout state rather than starting fresh from a potentially conflicting position.
3. Use hardware security modules (HSMs) for validator key custody where operationally feasible, reducing the risk of key compromise.
4. Monitor vote credit rate with automated alerting. Sharp drops in vote credit rate signal problems before they escalate to extended delinquency or equivocation exposure.
5. Follow Solana Labs and Anza client release notes and upgrade on recommended timelines to avoid consensus-altering bugs that could cause unintended behavior.
6. Maintain infrastructure redundancy through fail-over nodes, but never run two active signing nodes simultaneously. Redundancy and dual active signing are mutually exclusive requirements.
7. Participate in testnet upgrade cycles before mainnet exposure to catch consensus behavior changes that could create equivocation conditions at scale.

Even without live slashing, validators who accumulate poor reputations face economic consequences through delegator withdrawal. Delegators monitor performance data through Stakewiz, Solana Beach, and Validators.app and move stake away from underperforming operators.

Solana Slashing Governance: SIMD Proposals and What They Mean for the Future

Last updated: June 2025

A Solana Improvement Document (SIMD) is Solana's formal governance mechanism for proposing protocol-level changes, analogous to Ethereum's EIPs. SIMDs are how the Solana developer community formally proposes, debates, and ratifies changes to the protocol. The Solana Foundation, a Swiss-based non-profit that supports the Solana ecosystem, plays a role in stewarding SIMD discussions alongside validators, developers, and other community stakeholders.

SIMD proposals related to validator slashing have been put forward by members of the Solana developer community. These proposals seek to introduce financial penalties for equivocation (specifically, lockout violations detected by Tower BFT) for the first time at the protocol level. Readers should verify the current status of relevant SIMDs directly at the Solana Improvement Documents (SIMD) repository on GitHub, as proposal statuses change as community review progresses.

The governance debate centers on two positions. Proponents argue that economic penalties are necessary to align validator incentives at scale and that the absence of slashing represents a security gap relative to Ethereum and Cosmos. Those who caution against rapid implementation point to the risks of false-positive slashing in Solana's high-throughput environment, where network latency or client bugs could trigger equivocation conditions in honest validators.

If a SIMD proposing slashing is accepted and implemented, the consequences for validators and delegators would include:

• Equivocation would become a slashable offense for the first time on Solana
• A defined percentage of the validator's total staked SOL would be burned automatically
• Delegators would likely face proportional principal reduction, depending on the specific SIMD accepted
• Validators would need to implement the operational safeguards described in the previous section before the change takes effect

As of June 2025, no slashing SIMD has been implemented. Readers tracking this topic should monitor the SIMD repository directly, as governance discussions evolve outside the publication cycle of this article.

Frequently Asked Questions About Solana Validator Slashing

Does Solana have validator slashing?

No. As of June 2025, Solana does not implement validator slashing at the protocol level. Solana has no mechanism that automatically burns or reduces a validator's staked SOL as a penalty for misbehavior. Slashing has been formally proposed through Solana Improvement Documents (SIMDs) but remains unimplemented. Validators face reward-affecting penalties (delinquency, vote credit reduction) but not token reduction.

Can you lose your staked SOL due to validator misbehavior on Solana?

As of June 2025, your delegated SOL principal cannot be automatically reduced by the protocol due to your validator's misbehavior. What can affect you is validator performance: a delinquent or underperforming validator earns fewer vote credits, which reduces your staking rewards for that period. If SIMD slashing is implemented in the future, delegators would face proportional principal risk.

What is equivocation in Solana's consensus?

Equivocation occurs when a validator signs two conflicting votes or blocks for the same slot, attempting to support two different versions of the blockchain at once. In Tower BFT, this constitutes a lockout violation. Equivocation is the primary misbehavior that proposed slashing implementations target. Solana's protocol can detect equivocation but does not currently penalize it with token reduction.

What is the difference between validator delinquency and slashing on Solana?

Delinquency means a validator misses votes due to downtime. It affects only staking rewards through vote credit reduction and does not reduce your principal SOL balance. Slashing (proposed on Solana) would involve the automatic burning of staked tokens as punishment for deliberate misbehavior like equivocation. Delinquency affects yields; slashing affects principal. A jailed validator has been temporarily removed from the active set due to extended delinquency and also does not affect delegator principal.

Is Solana staking safer than Ethereum staking with respect to slashing?

As of June 2025, Solana delegators face no slashing risk to their principal because slashing does not exist at Solana's protocol level. Ethereum's Beacon Chain has implemented slashing since The Merge in 2022, meaning Ethereum delegators using liquid staking protocols bear proportional slashing exposure if their validators commit violations. Ethereum slashing events have been relatively rare in practice. Solana's current principal risk comes from sources other than slashing.

What are the SIMD proposals for Solana slashing?

Solana Improvement Documents (SIMDs) are formal governance proposals for protocol-level changes. As of June 2025, SIMD proposals have been put forward to introduce financial penalties for equivocation on Solana. The current status of specific proposals should be verified at the Solana Improvement Documents (SIMD) repository, as statuses change during community review.

Does Marinade Finance or Jito protect against slashing?

Both Marinade Finance and Jito spread delegated SOL across many validators, reducing your exposure to any single validator's misbehavior. If one validator in a large pool is slashed, only a small fraction of the total pooled stake is affected. Neither protocol eliminates slashing risk entirely, and both introduce Solana program risk that direct staking does not carry. Consult Marinade Finance documentation and Jito staking documentation for current details.

How would slashing work on Solana if it were implemented?

Under proposed SIMD slashing implementations, the mechanism would operate through Tower BFT's existing equivocation detection. If a validator commits equivocation (a lockout violation), the protocol would automatically burn a defined percentage of the validator's total staked SOL. Delegators would likely lose the same percentage of their delegated stake proportionally. Penalty amounts are proposed in SIMD discussions but not finalized. For the full mechanism explanation, see How Solana Handles Validator Misbehavior.

What is a Solana stake account?

A Solana stake account is an on-chain record that holds your staked SOL and tracks your delegation to a specific validator. It records the amount staked, the validator it is delegated to, and the current stake status (active, deactivating, or inactive). Under a slashing implementation, your stake account would be the direct target of any penalty applied to your validator. A stake account is distinct from your main SOL wallet.

What is Tower BFT?

Tower BFT is Solana's consensus protocol, the system validators use to agree on the state of the blockchain. Built on top of Proof of History, it uses exponentially increasing lockout windows that make voting on multiple competing blockchain versions economically irrational. Tower BFT can detect equivocation but does not currently trigger financial penalties for it. It is the architectural foundation through which any future slashing mechanism on Solana would operate.

Conclusion: Is Solana Staking Safe From Slashing Today?

As of June 2025, Solana staking does not carry protocol-level slashing risk. Your delegated SOL cannot be automatically reduced by the protocol due to your validator's misbehavior. The risks that exist for delegators today affect staking rewards through validator delinquency and commission structure, not your principal balance.

The forward-looking picture is different. SIMD governance proposals to introduce slashing are active in the Solana community, and if accepted, delegators would face proportional principal risk. Monitoring SIMD status is now a meaningful part of tracking your staking risk profile.

For stakers: Review your validator's vote credit rate and uptime using Solana Beach or Validators.app. For automatic diversification, liquid staking via Marinade Finance or Jito distributes your stake without requiring manual validator management. Consult the validator selection criteria above before delegating.

For validators: Review current SIMD proposals in the Solana Improvement Documents (SIMD) repository and implement Tower BFT operational safeguards now, before any protocol changes are ratified.

For researchers and analysts: Track SIMD governance status at the SIMD repository and benchmark Solana's validator penalty model against Ethereum's slashing incident history for comparative security modeling.

Glossary

Beacon Chain: Ethereum's proof-of-stake consensus layer, introduced with The Merge in September 2022. Slashing is implemented on the Beacon Chain, not on pre-Merge Ethereum.

Byzantine Fault Tolerance (BFT): A property of distributed systems that allows the network to continue operating correctly even when some participants act maliciously or fail. Named after the Byzantine Generals Problem. Tower BFT is Solana's specific implementation of BFT-class consensus.

Delinquency: A Solana validator that misses votes due to downtime or performance issues. Delinquency reduces vote credits and thus staking rewards, but does not reduce staked principal. Distinct from slashing and jailing.

Delegator: A SOL holder who assigns their stake to a validator without running a node themselves. Delegators earn staking rewards proportional to their share of the validator's stake pool. Most retail SOL stakers are technically delegators, not validators.

Epoch: A fixed period of time in Solana's protocol, approximately 2–3 days in duration. Staking rewards are distributed per epoch. Solana's unbonding period for withdrawing staked SOL spans approximately one epoch.

Equivocation: When a validator signs two conflicting votes or blocks for the same slot, commonly called double voting. In Tower BFT, this constitutes a lockout violation. Equivocation is the primary behavior that proposed slashing implementations target.

Jailing: Temporary exclusion of a validator from the active consensus set, typically due to extended delinquency. Jailing does not reduce staked tokens. It only affects the validator's ability to earn rewards during the jail period. Distinct from slashing.

Liquid Staking Token (LST): A tradeable token representing staked SOL held within a liquid staking protocol. mSOL is Marinade Finance's LST; jitoSOL is Jito's LST. LSTs are distinct financial instruments from regular staked SOL.

Lockout: A Tower BFT mechanism that prevents a validator from voting on competing forks after committing to one. Lockout windows increase exponentially with each subsequent vote. Violating a lockout constitutes equivocation.

Proof of History (PoH): A cryptographic timekeeping mechanism, not a consensus mechanism. PoH creates a verifiable record of the sequence of events on the network, functioning as a cryptographic clock. Tower BFT, Solana's consensus mechanism, is built on top of PoH.

Proof of Stake (PoS): A consensus framework in which validators put up tokens as collateral to participate in block production and voting. Slashing is the penalty mechanism that enforces honest behavior in PoS systems. Solana uses a hybrid architecture (PoH plus Tower BFT) rather than standard PoS.

SIMD (Solana Improvement Document): Solana's formal governance mechanism for proposing protocol-level changes, analogous to Ethereum's EIPs. SIMDs are how slashing has been proposed but not yet implemented on Solana.

Slashing: A protocol-level penalty in Proof of Stake blockchains that automatically reduces a validator's staked tokens as punishment for provable misbehavior such as equivocation. As of June 2025, slashing is not implemented on Solana.

Stake Account: A Solana-specific on-chain data structure that holds a delegator's staked SOL. It records the amount staked, the validator it is delegated to, and the current stake status. Distinct from a main SOL wallet.

Tower BFT: Solana's Byzantine Fault Tolerant consensus protocol, built on Proof of History. Validators vote on forks, and each vote carries an exponentially increasing lockout window. Tower BFT can detect equivocation but does not currently penalize it with token reduction.

Validator: A node operator who runs Solana validator infrastructure, casts consensus votes via Tower BFT, and participates in block production. Validators are distinct from delegators. The validator is the entity that would be directly penalized under any slashing implementation.

Validator Commission: The percentage of staking rewards that a validator retains before distributing the remainder to delegators. Commission is a percentage of rewards, not of staked principal. A 10% commission means the validator keeps 10% of earned rewards.

Related reading

• Solana vs Ethereum: Which to Buy Now
• What Is Polkadot? Parachains Explained