DeFi Insurance for Protocols: Scope, Exclusions and Claims Evidence

Coverage types

DeFi insurance for protocols is a broad label for arrangements that may compensate a defined loss under specific terms. The useful question is narrower: who can claim, for which position, after which event and under which version of the wording? A product name cannot answer those questions. Some arrangements are described as cover or an insurance alternative rather than a conventional insurance policy.

Begin with the claimant and the asset. A protocol team buying protection for treasury exposure is not necessarily buying protection for every depositor. A user buying cover for a position does not automatically protect the protocol's operating company. The policy or cover record must connect the claimant, the covered interest and the defined event.

Our census of the Nexus Mutual products endpoint returned 474 product objects. Of those, 215 were explicitly marked deprecated. The remaining 259 were marked not deprecated, but that field does not establish that a product is currently purchasable. This is why a directory count should never be presented as the number of available protection options.

These categories are a reading framework. They are not interchangeable offers and the table does not assert that every provider sells every type. The current Nexus overview and the fetched Generalized Fund Portfolio Cover wording illustrate why the exact product matters: portfolio terms can include annexes and eligibility rules that should not be transferred to a different cover product.

Sherlock Shield is another distinct example. Its current documentation describes exploit payout coverage for qualified codebases after an audit and fix review. It explicitly says Shield is not included by default with every audit. A buyer must confirm eligibility, covered code, amount and final terms rather than assume that purchasing an audit activates protection.

Keep the protected position identifiable through upgrades and migrations. A product name may stay the same while the underlying vault, token or implementation changes. Ask how the terms treat that change before moving assets or changing the covered system. The answer should be in the applicable wording or an explicit confirmation, not inferred from the brand name.

A useful first deliverable is a coverage map: claimant, asset, deployment, event, period and limit. If any of those fields is unresolved, the procurement question remains open. The due diligence checklist helps assemble the technical identity evidence that this map depends on.

Exclusions compared

Read exclusions against a threat model, one loss path at a time. A protocol can suffer a serious loss while its code behaves exactly as designed. Examples include an authorized administrator exercising a harmful permission or a user signing an unwanted approval. Whether such a loss is covered depends on the wording; the fact that it occurred in DeFi is not enough.

The fetched Nexus Mutual overview lists exclusions involving compromised wallets, activity where the protocol acts as intended, permitted rug-pull behavior, certain market movements, bridge components and events predating the cover period. These are the provider's summary statements. The applicable wording and any product-specific conditions must be checked before treating a particular event as included or excluded.

Do not treat silence in a summary page as inclusion. A short product description can omit a condition that appears in the wording or an annex. Conversely, a broad exclusion on one product should not be copied into a comparison of another without checking its terms. The correct comparison unit is a named wording version and the relevant clause.

Separate the trigger from the loss calculation. An event may meet a technical definition while the claimant still needs to prove a qualifying loss, comply with timing rules or account for another reimbursement. A positive answer to "was there an exploit?" does not finish the claims analysis. The protected interest and the claimant's own position still matter.

The Generalized Fund Portfolio Cover document fetched during this research states that its annexes form part of the terms and prevail in a conflict. That is a concrete reason to retain the complete contract package. A generic product webpage cannot reproduce a bespoke annex's scope, and a reviewer should not imply that it does.

1. Confirm that the person or entity can claim for the identified interest.
2. Match the actual mechanism to the applicable event definition.
3. Apply exclusions, deductions and the specified valuation rule.
4. Submit the required evidence through the agreed process and await its decision.

For a protocol team, unresolved exclusions should feed back into prevention and response. If a bridge component falls outside the selected cover, document that exposure rather than assuming the protocol limit covers it. If harmful authorized behavior is excluded, narrow the authority and improve key controls. Cover can transfer a defined risk; it cannot erase an excluded one.

Cost

Compare quotes for the same protected interest and period. A premium or cover price has little meaning without the amount, duration, deductible, event definition and exclusions attached to it. A smaller headline price can correspond to a narrower event or a lower recoverable amount. Keep those fields visible before comparing numbers.

The product endpoint used in our census contains fields such as minPrice, initialPriceRatio and capacityReductionRatio. We did not convert them into annual premiums. Their presence in an inventory response is not a quote for a particular buyer, amount or time window. Publishing a price from those fields without the pricing rules would create an unsupported estimate.

A worked budget should use the actual quoted terms. For example, if a hypothetical arrangement has a deductible, the team must hold resources for that retained exposure as well as uncovered losses. Do not present the covered amount as cash that will certainly arrive during an incident. A claim can take time and may be declined under the terms.

Ask whether the quote can change before execution and whether renewal requires another eligibility check. A position that is covered during one period may not be available on identical terms later. Build the renewal decision around current exposure and product conditions instead of assuming continuity from an earlier purchase.

Bespoke arrangements add another comparison problem: the scope may be negotiated individually. Nexus Mutual's overview says bespoke covers for institutional clients, funds and protocol teams are individually structured and priced. The useful output is a documented term comparison, not an invented market-wide price range for all protocols.

Keep procurement charges separate from operational controls. Audit work, monitoring and incident preparation may remain necessary even when cover is purchased. The audit scope builder can help define the code-review work, while the cover quote should state its own protected event and eligibility conditions. Paying for both does not imply that their scopes automatically match.

The decision memo should identify the amount of exposure retained by the team, the loss paths excluded and the evidence needed to claim. That gives treasury and engineering the same understanding of what the expenditure buys.

Interaction with audits

An audit and a cover arrangement answer different questions. The audit records what reviewers examined and found within a technical scope. Cover terms define conditions under which a qualifying loss may be compensated. An audit can inform eligibility or underwriting without making every future defect a covered event.

Sherlock Shield makes the connection explicit in its published process: complete the audit, complete the fix review, undergo an eligibility evaluation and confirm final terms. The documentation also states that payment and fund availability are not guaranteed. A protocol team should therefore preserve the approved scope and claims terms alongside the report rather than infer protection from the audit purchase alone.

The same separation applies when an insurer or cover provider asks for an audit as evidence. Ask whether the requirement concerns the firm's identity, the reviewed revision, unresolved severities or the scope of remediation. A report for the token may not satisfy a condition concerning the vault or bridge integration through which the loss could occur.

The audit report field guide helps distinguish a remediated finding from an accepted risk or an unverified fix. The dependency risk guide helps identify components that can sit outside both an audit and a cover boundary. These distinctions matter more than the presence of a badge.

When reviewing a provider, use evidence of its actual services and deliverables. The Pharos Production member profile is one reference for technical service scope. A firm's ability to review a contract does not mean it determines another provider's coverage eligibility or claims decision.

After a material code change, revisit both records. The technical report may need a delta review, and the cover terms may require notice or another scope confirmation. A governance vote approving an upgrade does not itself update a report or a cover contract. Assign an owner to each follow-up so the release process cannot silently leave one behind.

Audit findings also improve the procurement question. If the review identifies a loss path involving privileged operations or a third-party component, ask the cover provider how the wording treats that path. The answer can affect whether the team changes the architecture, accepts retained exposure or seeks different terms.

Claims record

A claims record is useful only with a defined denominator and outcome. Count submitted claims separately from accepted claims, rejected claims, withdrawn claims and payments actually made. A public total of payouts does not reveal the probability that a future claim will be accepted, especially when products and wording versions differ.

Our attempted Nexus claims API URL returned 404, so this research does not publish a computed claims acceptance rate. The successful products endpoint is an inventory source, not a claims dataset. Substituting its product count as a denominator for payout statistics would be meaningless.

During an incident, preserve the evidence that the terms require. This can include the covered position, transaction history, the event chronology and the amount of loss attributable to the covered mechanism. Keep original records and distinguish observed facts from preliminary explanations. The incident response guide explains why evidence collection should begin before a final root cause is known.

A protocol's reimbursement can affect a user's remaining claim under some terms. The Nexus overview describes reductions for other recovery and prohibits double recovery. That provider statement should prompt the team to coordinate its reimbursement records with the actual cover wording. It is not a rule to assume for every product in the market.

Ask for the complete decision trail when reviewing a provider's claims history. A useful example identifies the applicable terms, the accepted event, the loss calculation and the payment record. A marketing case that provides only a large dollar amount cannot answer whether your position would have met the same conditions.

The practical end state is a claims-ready evidence plan before purchase. The team knows who can submit, which records must be retained and which uncertain conditions need clarification. That preparation supports a future assessment without pretending that the outcome is guaranteed.

Original inventory census: deprecated is a separate state

Method

Source and selection

Read every product object returned by Nexus Mutual /v2/products. Classify only explicit isDeprecated and isPrivate booleans; retain missing values as unknown. Do not interpret minPrice as a quote.

Retrieved

2026-09-06

Observation

474 returned objects, no exclusions and no duplicate product IDs.

Results

The API distinguished 215 deprecated objects from 259 not-deprecated objects. We retained every row and did not filter private products into a public availability estimate. The 142 private flags overlap the other classifications, so these counts must not be added together.

For a procurement team, the result supports a simple check: verify the selected product's current eligibility, capacity and wording before treating an inventory row as an offer. The catalog itself cannot answer those buyer-specific questions.

Limits

• Inventory only: no quote was requested and no coverage was purchased.
• No claim outcome or payout probability was calculated; the attempted claims endpoint failed.
• Product status may change after retrieval. The raw snapshot is retained for reproducibility.

The reproducible record is kept in the repository: seo/research/articles-42-51-2026-09-06/surveys.py and seo/research/articles-42-51-2026-09-06/survey-46.json. These file paths are not public downloads.