“Slashing coverage” shows up in almost every institutional staking pitch. It sounds like a single, well-defined product, something you either have or don’t. In practice, it isn’t one thing. Ask three different providers what their slashing coverage includes, and you’ll get three different answers: a contractual uptime guarantee, a third-party insurance policy, a mutual coverage pool, or some combination of all three, each with its own exclusions.
For an institution sizing a staking allocation, that ambiguity is the actual risk; not slashing itself. This post breaks down what slashing coverage really means, the different models providers use, and what each one does and doesn’t protect against.
What Slashing Actually Is, Briefly
Slashing is the protocol-level penalty that proof-of-stake networks impose on validators who misbehave. As Coinbase’s institutional research team explains in its slashing primer, a validator’s stake functions “as a form of collateral, with slashing being akin to a (fractional) collateral liquidation event.” When a validator violates network rules, the protocol automatically confiscates part of its staked balance: no human judgment call involved, no appeal process. The penalty is enforced directly by the protocol’s code.
The exact size of the penalty varies by network, and there isn’t a single standard percentage across Proof-of-Stake chains, which is itself part of why “coverage” is hard to standardize. What’s consistent across networks is the logic: the penalty exists specifically to make dishonest or careless validator behavior more costly than it’s worth.
The two conditions that matter most:
Double signing is the severe case: a validator signs two conflicting blocks at the same height, which threatens the integrity of the chain itself. Because it directly undermines consensus, double-signing penalties are typically the harshest a network imposes, and in some cases can also trigger permanent ejection from the validator set.
Extended downtime is the far more common case: a validator goes offline or fails to participate in consensus for a prolonged stretch. Most networks treat this less severely than double signing, sometimes applying a smaller penalty or simply “jailing” the validator (temporary removal with lost rewards) rather than confiscating stake outright.
Chain.link’s overview of slashing adds a third, less-discussed category: surround voting, where a validator’s attestations contradict its own prior votes in an attempt to manipulate consensus. It’s worth noting that delegators share this exposure; when you delegate stake to a validator, you inherit a portion of that validator’s slashing risk, which is exactly why operator vetting matters as much as the staking decision itself.
Why “Coverage” Means Different Things to Different Providers
Once you move past the mechanics of slashing itself, “coverage” splits into a handful of genuinely different models. None of them are wrong, but they protect against different things, and institutions evaluating a provider need to know which one they’re actually being offered.
Model | Who bears the risk | Typical scope | Best fit |
|---|---|---|---|
Provider-absorbed guarantee | The provider’s own balance sheet | Downtime-driven penalties from provider error | Clients prioritizing simplicity over formal underwriting |
Third-party commercial insurance | A licensed insurer | Defined events per policy terms | Institutions with counterparty-concentration limits |
Mutual / pooled on-chain coverage | A shared, capped pool | Proportional payout on proven on-chain events | Liquid staking and DeFi-native positions |
Self-insurance via reserves | The institution itself | Whatever the institution chooses to model | Large allocators with in-house risk expertise |
None of these four is inherently stronger than the others: a well-capitalized provider guarantee can be more reliable than a thinly capitalized insurance pool, and vice versa. The table is a starting point for the conversation, not a ranking.
1. Provider-Absorbed Guarantees
The simplest model: the provider contractually commits to reimbursing clients for losses caused by its own infrastructure failures: typically downtime-driven penalties, not double-signing events caused by a genuine bug or misconfiguration. This is less “insurance” in the formal sense and more an extension of an uptime SLA, backed by the provider’s own balance sheet rather than a third party. It’s straightforward, but its strength is only as good as the provider’s financial capacity to actually pay out at scale.
2. Third-Party Commercial Insurance
Some providers underwrite slashing risk through licensed insurance brokers. This shifts the financial exposure off the provider’s own balance sheet and onto a regulated insurer, which can matter for institutions with fiduciary requirements around counterparty risk concentration. The tradeoff is usually narrower, more clearly defined coverage terms and conditions, since insurers price risk conservatively and exclude edge cases explicitly.
3. Mutual or Pooled On-Chain Coverage
A third model runs coverage through decentralized mutual pools: protocols where participants pay into a shared fund that pays out claims based on on-chain proof of a slashing event. This approach has grown alongside liquid staking and restaking, since it can plug into smart contracts natively. The Continuum guide to slashing insurance frames this model’s core value simply: it gives stakers “a financial safety net against technical failures or honest mistakes” without requiring a traditional insurance relationship. The tradeoff is that payouts are typically proportional, not full compensation, and pool capacity can be a real constraint during a network-wide slashing event that affects many validators simultaneously.
4. Self-Insurance via Reserves
Larger institutions sometimes skip external coverage altogether and instead size their own risk reserve, holding capital aside to absorb potential slashing losses directly, based on their own risk modeling. This only makes sense at scale, where the cost of maintaining a reserve is lower than the premium for external coverage, and where the institution has the risk expertise to model its own exposure accurately.
Self-insurance also requires ongoing recalibration. A reserve sized against a single-network staking position looks very different once that position is delegated across multiple validators, multiple networks, or restaked into additional protocols. Institutions that take this route tend to treat the reserve calculation as a living model, revisited whenever the underlying staking footprint changes materially, rather than a number set once and left alone.
What Coverage Usually Excludes
This is the part that gets skipped in most vendor conversations, and it’s the part that matters most in due diligence. Across nearly every model, a few exclusions show up consistently:
Minor, isolated downtime penalties are frequently excluded or treated as accepted operational risk rather than a covered event; the assumption being that some baseline downtime is a normal part of running infrastructure, not a claimable loss.
Smart contract vulnerabilities in the coverage mechanism itself are typically carved out. If the mutual pool or insurance contract has its own bug, that’s a separate risk layer entirely, not something the coverage protects against.
Restaking introduces a genuinely new complication. When a validator’s stake secures multiple protocols simultaneously (the model popularized by EigenLayer and similar restaking systems) the slashing conditions stack. A single fault can now trigger penalties across several layers at once, and standard coverage products, largely designed around single-network slashing, often aren’t built to price or cover that layered exposure yet. This is a fast-moving area, and it’s worth asking any provider directly how their coverage, if any, treats restaked positions.
The Due Diligence Questions That Actually Matter
Given how much these models diverge, the useful question isn’t “do you offer slashing coverage.” It’s a short list of follow-ups that actually distinguish a real answer from a marketing line:
Which slashing conditions does the coverage apply to: double signing only, or downtime too? Is the payout full replacement of the loss, or proportional? Who is financially responsible if a claim exceeds the coverage pool or the insurer’s capacity; does that risk revert to the client? And critically: does the coverage extend to restaked or re-delegated positions, or only to a validator’s base stake?
None of these questions have a universally “right” answer: a provider can reasonably run any of the four models above. What matters is whether the provider can actually answer the questions specifically, rather than falling back to a general assurance that coverage exists. We touched on a version of this same idea in our recent breakdown of what to evaluate in institutional staking security: the labels providers use (SOC 2, enterprise-grade, insured) are rarely the differentiator. The specifics behind them are.
BitGo’s guidance on institutional staking risk makes a related point worth internalizing: slashing coverage is one layer of a broader risk stack that also includes custodial controls, geographically distributed and redundant validator infrastructure, and compliance integration. Coverage that reimburses a loss after the fact is a weaker position than infrastructure that meaningfully reduces the odds of a slashing event happening in the first place. The strongest approach treats coverage as a backstop, not a substitute for operational discipline.
Where GlobalStake Fits
We think about slashing coverage the same way we’d want a counterparty to think about it if the roles were reversed: as one part of a layered risk model, not a headline feature. That means being specific with clients about exactly which conditions are covered, how claims are substantiated on-chain, and where the limits of any coverage sit, rather than leaning on the word “insured” as a stand-in for due diligence.
If you’re evaluating slashing coverage as part of a broader staking provider assessment, our institutional staking infrastructure page goes into more detail on the operational side: infrastructure diversification, key management, and the certifications that back it.
Common Questions About Slashing Coverage
Does slashing coverage protect against market losses if the price of the staked asset drops?
No. Slashing coverage addresses only the protocol-level penalty applied to the staked balance itself; it has nothing to do with the market value of the underlying asset. Price risk and slashing risk are entirely separate categories, and no slashing coverage model in the market today addresses the former.
Is slashing coverage the same thing as custody insurance?
No, and conflating the two is a common due diligence mistake. Custody insurance typically covers theft, loss of private keys, or a breach of the custodian’s systems. Slashing coverage addresses a specific protocol-level penalty event tied to validator behavior. An institution can have strong custody insurance and no meaningful slashing coverage, or the reverse: the two need to be evaluated separately.
Do all Proof-of-Stake networks slash the same way?
No. Penalty size, the specific conditions that trigger slashing, and whether downtime alone can trigger a penalty (versus just lost rewards) all vary by network. Several institutional staking providers have moved toward quantifying risk exposure on a per-network basis rather than applying a single blanket policy across every chain they support: a reasonable approach, since a one-size-fits-all coverage model doesn’t map well onto genuinely different penalty structures.
How does restaking change the coverage picture?
Restaking protocols allow a single staked position to secure multiple services simultaneously, which means a single validator fault can trigger slashing conditions across more than one layer at once. Most coverage products in the market were designed around single-network slashing and are still catching up to what layered, multi-protocol slashing exposure actually looks like. This is the fastest-moving part of the slashing coverage landscape, and it’s worth revisiting with any provider on a regular basis rather than assuming a policy written a year ago still reflects current exposure.
The Takeaway
Slashing coverage isn’t a single product, and treating it like one is exactly how institutions end up with a false sense of security. There are at least four distinct models in the market today: provider guarantees, commercial insurance, mutual pools, and self-insurance, each with its own exclusions, and restaking has already started to outpace what most of these models were built to handle.
The question worth asking isn’t whether a provider has slashing coverage. It’s what, specifically, that coverage actually does – and doesn’t – protect against. Get a specific answer to that question, in writing, and the rest of the due diligence conversation tends to get a lot easier.