DeFi insurance: what is excluded from coverage?

Most decentralised cover products do not insure every loss associated with a protocol, a token, or a wallet. They respond to defined events under defined conditions—and the boundary between a covered exploit and an excluded loss is often where the real risk begins.

The historical claims record makes this visible. Nexus Mutual, one of the best-known providers in the sector, has reported a settlement rate of roughly 73%, implying that approximately 27% of claims were denied. That does not mean every denied claim was mishandled, nor that every accepted claim followed automatically from a technical exploit. It shows that DeFi cover is a governance-mediated system in which code failure, policy language, timing, and evidence must align.

The practical question, then, is not simply whether a protocol was attacked. It is whether the incident fits the cover’s definition of loss.

The governance gap: why claims can be denied after an exploit

In conventional financial products, a claimant generally expects a contract to specify the conditions under which compensation is due. Decentralised cover introduces a second layer: claims may be assessed through governance voting by token-holding members. The result is not merely an actuarial process. It is a collective decision about whether a reported event falls within the protection that members agreed to provide.

That distinction matters because a smart contract exploit can produce several different interpretations at once.

A protocol may have suffered an unauthorised transfer, yet the relevant cover may define a valid claim more narrowly. The exploit may have affected an external dependency rather than the insured contract. The loss may have occurred before the policy began. Or the claimant may not have met a materiality threshold, even if the dollar value appears significant in isolation.

For Nexus Mutual smart contract cover, the loss generally needs to reach a minimum materiality threshold of 20% of the cover amount. This is not a minor technicality. A policyholder who purchases cover for a large position but suffers a partial loss may discover that the event does not qualify under the relevant definition, or that the payout is reduced by the policy’s own limits.

Claims assessment therefore involves several questions:

1. What exactly failed? Was the loss caused by a bug in the covered smart contract, an oracle, a bridge, a frontend, a wallet, or another protocol?

2. When did the failure occur? Events before the cover period are normally outside the policy, even if their consequences become visible later.

3. Was the vulnerability already publicly disclosed? A bug that had been announced as a warning before the policy started may be treated as a pre-existing condition.

4. How large was the eligible loss? Coverage limits, materiality rules, and proportional payout mechanisms can change the amount ultimately paid.

5. Does the evidence support the claim? Governance participants must evaluate an on-chain event, often alongside incomplete incident reports and competing interpretations.

This is why “DeFi insurance payout triggers” are better understood as a chain of conditions than as a single switch. A protocol can be exploited and still fall outside the scope of a particular cover.

DeFi cover does not ask only whether capital was lost. It asks whether the loss belongs to the risk the pool agreed to absorb.

The governance model also creates an institutional risk that is difficult to measure precisely. It is not established that claim denials are caused by collusion or voting manipulation, and the available data does not provide a reliable breakdown of denials by motive. But the structure remains consequential: the final interpretation of a claim depends on a decentralised body whose incentives, information, and participation may vary over time.

That is the governance gap. The product is designed to distribute risk, but its decisions are still made through a political economy of token ownership, delegated judgment, and available evidence.

Beyond the code: user-side and frontend failures

The most important smart contract insurance exclusions concern incidents in which the underlying contract behaved as designed.

This is where many users misclassify their exposure. If a wallet signs a transaction to an attacker-controlled address, or a frontend displays a malicious destination while the underlying contract executes correctly, the loss may be real but the insured protocol may not have failed. Cover for protocol failure is not automatically cover for every pathway through which a user can lose funds.

Standard DeFi cover commonly excludes losses caused by:

• phishing and social engineering;
• compromised private keys or seed phrases;
• malware on the user’s device;
• user-interface errors;
• malicious or altered website behaviour when the underlying smart contract continues to operate as intended;
• DNS hijacking, website spoofing, or frontend compromise;
• incorrect transaction signing by the user.

The distinction between frontend and contract security is particularly important. A user may visit what appears to be the correct application, approve a transaction, and lose assets through a manipulated interface. From the user’s perspective, the application was compromised. From the perspective of protocol cover, however, the smart contract may have processed a valid transaction according to its rules.

That division follows the architecture of DeFi. The frontend is an access layer; the contract is the execution layer. They are connected, but they are not the same security boundary. A frontend attack can redirect a user without changing the protocol’s bytecode or permission structure.

The result is a mismatch between operational risk and cover design. Users experience the application as one product. Risk pools often assess it as a stack of separate components:

This makes security monitoring inseparable from coverage analysis. An audit may reduce the probability of a contract bug, but it says little about a compromised deployment pipeline, an exposed administrator key, or a malicious frontend update. A bug bounty may surface vulnerabilities, but public disclosure can also affect eligibility if the policy begins after the warning has been published.

In that sense, security controls and insurance are not substitutes. Audits, multisig procedures, monitoring, and bug bounty programmes reduce the probability of failure. Cover addresses a narrower residual risk. Confusing these functions produces a false sense of capital alignment: the user may believe that every major control failure has a corresponding payout mechanism, when in practice the layers remain separate.

Even the communication layer has a role in how incidents are understood. Protocol teams increasingly publish visual reconstructions and incident explainers alongside technical postmortems; organisations working across that boundary may draw on a video production and creative media hub when translating complex events for a broader audience. Clear communication does not expand coverage, but it can determine whether governance participants understand the mechanism of loss well enough to assess it.

The rug pull paradox: when authorised theft is not a covered exploit

Rug pulls reveal a deeper limit in DeFi cover. The term is used broadly, but standard protocol protection usually distinguishes between an unauthorised exploit and an action performed through permissions that the protocol intentionally granted.

If a protocol owner or controller can withdraw funds, alter parameters, mint assets, or redirect liquidity under the system’s existing permissions, the resulting loss may be excluded—even if the outcome is indistinguishable from theft to depositors. The critical question is not whether the funds were taken, but whether the action violated the contract’s defined execution rules.

This is the rug pull paradox: permissioned malice can be technically valid.

A smart contract can contain privileged functions that are disclosed in its code or documentation. If the controlling party uses those functions to confiscate or steal funds, standard protocol cover generally treats the event as a protocol-owner action rather than a covered smart contract failure. The code did not malfunction. It performed the operation available to the authorised actor.

That boundary is difficult for users because decentralised finance frequently presents governance and administration as part of a continuum. A protocol may advertise decentralised ownership while retaining upgrade keys, emergency withdrawals, pausing authority, or the ability to change critical parameters. The existence of a multisig wallet can reduce single-key risk without eliminating governance or controller risk.

The relevant security questions are therefore architectural:

• Can an administrator upgrade the implementation without a timelock?
• Can a multisig change the oracle, collateral factor, or withdrawal logic?
• Are signers independent, identifiable, and operationally secure?
• Is there a pause function, and who can activate it?
• Can privileged actors move user funds directly?
• Does governance control the permissions, or does a small group retain unilateral authority?
• Are changes announced before taking effect?

These features may not determine whether a protocol is “safe” in the general sense, but they influence whether a future loss resembles an exploit, an operational failure, or an excluded authorised action.

This is also why “crypto insurance for protocol failure” should not be treated as a synonym for protection against fraud. Some emerging products may advertise broader cover, including forms of team misconduct or rug-pull protection, but the underwriting criteria and claim standards for such products are not uniform. A broader promise on a landing page is not the same thing as a clearly defined and well-capitalised payout mechanism.

The distinction has consequences for capital allocation. A protocol with high smart contract cover but extensive upgrade authority may still expose users to a large uninsured governance surface. Conversely, a protocol with conservative permissions may have a smaller technical attack surface even if no cover is available. Insurance changes the residual risk; it does not erase the underlying design.

Composability risk and the limits of multi-protocol cover

DeFi protocols are rarely isolated. Lending markets rely on oracles. Automated market makers provide liquidity for derivatives. Vaults route capital through several strategies. Stablecoin systems depend on collateral markets, price feeds, bridges, and settlement contracts. This composability is the source of much of DeFi’s capital efficiency, but it also fragments the responsibility for failure.

A covered protocol may function exactly as designed while an external, non-covered protocol fails. If the covered application depends on that external component, the user can still lose money. Standard protocol cover commonly excludes this type of composability risk.

Consider a vault that deposits funds into another lending market. An exploit in the underlying lending market drains the vault’s assets. The vault’s own accounting may remain correct: it records a position that has become worthless because the external market was compromised. Whether the vault is covered depends on the precise policy structure, but the general principle is clear—coverage of one contract does not automatically extend through every protocol in its dependency graph.

The same issue appears in oracle manipulation. An oracle can publish a distorted price because of thin liquidity, a faulty update, or manipulation elsewhere in the market. The insured protocol may then liquidate positions or issue loans according to the price it received. Some covers may respond to defined oracle failures; others may exclude the event, particularly where the oracle is an external dependency or the loss is classified as market movement.

Bridge failures are another major boundary. Standard protocol cover commonly excludes failures in cross-chain bridge components. That means a user may hold a token represented on one chain, deposit it into a covered application, and remain exposed to the bridge’s security assumptions. The cover on the destination protocol does not necessarily cover the mechanism that made the asset available there.

A multi-protocol pass can appear to solve this fragmentation by grouping several applications under one limit. But aggregation changes the mathematics rather than eliminating the dependency problem. If the total assets held across covered protocols exceed the purchased coverage limit, any payout may be scaled down proportionally.

For example, if a pass covers several protocols up to a fixed limit while the policyholder’s eligible assets are substantially larger, the limit is shared across the entire position. The pass is not a promise to reimburse every covered deposit at full value. It is a pool of protection allocated across an aggregate exposure.

This creates a capital-alignment problem that is easy to miss when comparing advertised cover amounts. The relevant ratio is not the headline limit alone, but the limit relative to the capital exposed across all covered venues and the correlation between their failure modes.

A portfolio spread across five protocols can still have concentrated risk if all five depend on the same oracle, bridge, stablecoin, or governance framework. Diversification by application name is not necessarily diversification by security assumption.

Depeg cover is a separate instrument, not a general loss policy

Asset depegs sit at the boundary between market risk and protocol risk. A stablecoin can lose its target value without any smart contract exploit. A collateral asset can become illiquid. A lending market can remain operational while the assets deposited into it lose their market value.

Standard protocol cover generally excludes normal price movements and asset depegs unless a dedicated Depeg Cover has been purchased. This distinction prevents the risk pool from becoming a general hedge against market volatility, but it also means that users must identify the type of loss they are trying to protect against.

A depeg policy typically introduces its own conditions. One example is a minimum holding period: covered tokens may need to have been held for at least 72 hours before the depeg event begins. Tokens acquired after the event has started would not qualify, because the cover would otherwise function as retrospective protection for a loss already in progress.

The timing rule reflects a basic underwriting principle. Cover is intended to absorb uncertain future events, not to convert known deterioration into an insurable event after the fact. It also creates a practical distinction between portfolio rebalancing and risk protection. Moving assets into a covered token shortly before a widely visible depeg warning may not create an eligible position.

Depeg cover can also be limited by definitions of the event itself. A temporary price deviation, a liquidity premium, and a permanent loss of solvency are not necessarily treated in the same way. The policy may specify an observation period, a reference market, or a threshold that must be reached before a claim becomes valid.

This is another reason that APY and cover should be evaluated together. A high-yield position may derive its return from exposure to a fragile stablecoin, thin liquidity, or recursive collateral. Purchasing smart contract cover may address one failure mode while leaving the dominant source of loss untouched. The protocol can remain secure at the code level while the economic design breaks under stress.

Pre-existing conditions, limits, and the shape of a real payout

The most consequential exclusions are often temporal and quantitative rather than dramatic. A policy can fail to respond because the vulnerability was known before inception, because the cover was too small relative to the position, or because the loss did not meet the required threshold.

Pre-existing conditions are particularly important in a market where disclosures travel quickly. If a vulnerability has been publicly announced before the policy begins, losses connected to that issue may be excluded. The same may apply when an incident started before the cover period, even if the full financial impact became visible later.

This creates a difficult boundary for users and providers alike. Blockchain incidents unfold over time. An attacker may begin manipulating a system hours before funds are drained. An oracle may drift before a liquidation cascade. A protocol team may publish a warning while the exploit remains active. Determining the start of the event can become as important as identifying the final transaction.

Policy limits create a second boundary. If a user holds more assets than the purchased cover amount, the uncovered portion remains exposed. In pooled or multi-protocol products, the effective payout may be reduced further when many policyholders claim against the same event or when the aggregate limit is allocated proportionally.

The historical record gives some indication of the scale of payouts that decentralised cover has supported. Reported examples include approximately $397,000 related to the C.R.E.A.M. Finance oracle exploit in November 2021, $5 million for the Rari Capital Fuse exploit in May 2022, $337,000 connected to a Perpetual Protocol economic design failure in June 2022, and $3.3 million following the Euler Finance exploit in March 2023. These payments demonstrate that cover can provide meaningful recovery. They do not establish that every exploit is payable, or that a future pool will have the same capacity under stress.

The reported total pool size of Nexus Mutual was approximately $81.56 million as of mid-2026, while the broader DeFi insurance industry has historically paid out around $18 million in claims. Those figures should be read as indicators of available risk-bearing capacity, not as guarantees. A pool can be large relative to ordinary claims and still face difficult choices when several correlated protocols fail at once.

For users assessing DeFi insurance pool coverage limitations, the key exercise is to map the policy against the actual dependency graph of the position:

• Contract risk: Is the deployed code itself vulnerable to reentrancy, faulty accounting, access-control failure, or an economic exploit?
• Oracle risk: Can a manipulated or delayed price feed create insolvency while the contract behaves normally?
• Governance risk: Can authorised actors change the rules or withdraw funds?
• Bridge risk: Does the asset depend on a cross-chain component that the policy excludes?
• Frontend risk: Can a compromised interface redirect transactions without altering the contract?
• Market risk: Would a depeg or liquidity collapse be treated as a separate event?
• Timing risk: Was the position opened after a warning, or did the event begin before cover?
• Capacity risk: Is the policy limit meaningful relative to the capital deployed and the possibility of proportional scaling?

The answer is rarely a single risk score. It is a map of where responsibility moves from code to governance, from protocol to dependency, and from the risk pool back to the user.

What DeFi cover can—and cannot—align

DeFi insurance is most useful when its scope is narrow enough to be evaluated and its capital base is large enough to absorb the events it names. It can reduce the severity of a smart contract exploit, an oracle failure, or another explicitly covered incident. It cannot turn a complex application stack into a single insured object.

The exclusions are not peripheral terms. They describe the architecture of the market itself: the separation between frontend and contract, the distinction between authorised control and unauthorised exploitation, the dependence on bridges and external protocols, and the difference between a technical failure and a market loss.

A defensible risk assessment therefore begins with the policy wording, not the product label. “Smart contract cover” may leave private keys, phishing, frontend attacks, rug pulls, depegs, bridges, and composability failures outside the perimeter. “Multi-protocol cover” may still impose one shared limit. “Decentralised claims” may mean that governance voters determine whether the event qualifies, with a historical settlement rate of roughly 73%.

The central problem is one of alignment. Users want protection at the level where they experience loss: the application, the wallet, the portfolio. Cover providers underwrite narrower technical and economic events. Between those two perspectives lies the real perimeter of DeFi risk.

As protocols become more composable and staking, lending, and yield strategies converge into shared liquidity systems, will cover products evolve toward the full dependency graph—or will the market continue to insure isolated components of a system whose failures are increasingly collective?