Historical DeFi Insurance Claims Case Studies

core-concepts

Core Concepts in DeFi Insurance

Foundational principles and mechanisms that underwrite risk management protocols in decentralized finance.

Coverage Pools

Capital pools where liquidity providers deposit funds to backstop potential claims. These are the foundational reserves of an insurance protocol.

Funds are locked in smart contracts to collateralize policies.
Providers earn premiums and protocol tokens as yield.
Pool diversification and size directly correlate with protocol capacity and security.

Claims Assessment

The decentralized process for verifying and adjudicating insurance claims, often using token-weighted voting or specialized committees.

Claim assessors (often token holders) vote on the validity of a submitted claim.
Successful claimants receive payouts from the coverage pool.
This mechanism is critical for maintaining trust and protocol solvency.

Parametric Triggers

Pre-defined, objective conditions that automatically execute a payout, removing subjective claims assessment.

Triggers are based on verifiable oracle data (e.g., a token price falling below a threshold).
Enables faster, gas-efficient payouts for qualifying events.
Reduces moral hazard but requires precise, attack-resistant oracle design.

Risk Modeling & Pricing

The actuarial framework used to calculate insurance premiums based on the probability and potential severity of a covered event.

Models assess smart contract risk, oracle failure, and economic exploits.
Dynamic pricing adjusts premiums based on pool utilization and historical data.
Accurate modeling is essential for protocol longevity and fair user costs.

Policy NFTs

Non-fungible tokens that represent an active insurance policy, encoding coverage parameters, expiration, and the insured address.

Enables secondary market trading of active coverage positions.
Provides immutable proof of coverage terms and period.
Facilitates composability with other DeFi protocols for leveraged or hedged positions.

Staking & Slashing

The incentive and penalty system for claims assessors and other protocol service providers to ensure honest participation.

Assessors stake protocol tokens to participate in voting; correct votes earn rewards.
Malicious or incorrect voting can result in a portion of the stake being slashed.
Aligns economic incentives with truthful claims adjudication.

Major Claims by Insurance Protocol

Smart Contract Failure Coverage

Nexus Mutual is a decentralized, member-owned alternative to insurance, focusing on smart contract risk. Its most significant claim event was the bZx protocol exploit in February 2020, where a series of flash loan attacks resulted in losses. Members holding cover for the bZx contracts successfully claimed approximately $250,000. This event validated the protocol's model, demonstrating that on-chain claims assessment via member voting could function effectively in a crisis. The process involves a Claims Assessment where NXM token holders vote to approve or deny payouts based on submitted evidence.

Key Characteristics

Cover Scope: Primarily for bugs or exploits in smart contract code.
Claims Process: Decentralized voting by mutual members (staked NXM).
Payout Currency: Claims are paid in ETH, not the native NXM token.
Example: A user holding cover on a Compound vault could file a claim if a reentrancy bug drains funds.

Comparative Analysis of Historical Claims

Comparison of key metrics and outcomes from major DeFi insurance claim events.

Metric	Nexus Mutual (bZx Hack)	Euler Finance (Euler Hack)	Sherlock (Sentiment Hack)
Total Claim Payout (USD)	$8.1 million	$33.8 million	$3.5 million
Cover Limit per Policy	Up to pool capacity	Up to 1,500 ETH	Up to $10 million
Claim Assessment Time	~14 days (governance vote)	~45 days (complex investigation)	~7 days (security council)
Payout Resolution Method	On-chain governance vote	Multi-sig trustee execution	Security council ruling
Coverage Trigger	Smart contract failure	Smart contract failure	Smart contract failure
Claim Dispute Mechanism	Stake-weighted voting	Arbitration via trustee	Appeal to UMA oracle
Payout Currency	ETH, DAI, NXM	USDC, DAI, wETH	USDC

The Decentralized Claims Process

A technical walkthrough of the on-chain workflow for submitting and adjudicating a DeFi insurance claim.

Initiate a Claim via Smart Contract

The policyholder triggers the claims process by calling the protocol's claims contract.

Detailed Instructions

To initiate a claim, the policyholder must call the submitClaim(uint256 policyId, bytes calldata proof) function on the claims manager contract. The policyId is the unique identifier of the active coverage NFT, and the proof is a structured data blob containing evidence of the loss, such as transaction hashes, block numbers, and relevant contract addresses.

Sub-step 1: Verify Policy Status: Call getPolicyStatus(policyId) to ensure the policy is active and the incident occurred within the coverage period.
Sub-step 2: Prepare Proof Data: Structure your proof according to the protocol's required schema, often including the exploited contract address (e.g., 0x...), the block number of the exploit, and the user's lost amount.
Sub-step 3: Submit Transaction: Execute the submitClaim function, paying the necessary gas fee. A successful transaction emits a ClaimSubmitted event with a new claimId.

solidity
// Example interaction with a claims contract
IClaimsManager claims = IClaimsManager(0xClaimsManagerAddress);
bytes memory proofData = abi.encode(exploitTxHash, vulnerableContract, lossAmount);
uint256 claimId = claims.submitClaim(myPolicyId, proofData);

Tip: Always verify the claim submission deadline (claimSubmissionDeadline) in the policy terms to ensure timeliness.

Stake Claims Assessor Tokens

Claims assessors (CAs) signal their intent to review the case by staking protocol tokens.

Detailed Instructions

After a claim is submitted, a voting period opens. Claims Assessors (CAs), who are token holders, must stake the protocol's native token (e.g., NXM or CLAIM) into the claim's specific assessment pool to participate. The required stake acts as a skin-in-the-game mechanism to incentivize honest voting.

Sub-step 1: Monitor New Claims: CAs listen for the ClaimSubmitted event or query the contract's getOpenClaims() function.
Sub-step 2: Evaluate Initial Evidence: Review the publicly submitted proof data on-chain and any off-chain incident reports to form a preliminary opinion.
Sub-step 3: Lock Stake: Call stakeOnClaim(uint256 claimId, uint256 amount) to commit tokens to the claim. Staking typically locks funds until the claim is resolved.

solidity
// A claims assessor staking tokens
IAssessmentPool pool = IAssessmentPool(0xAssessmentPoolAddress);
// Approve transfer first
IERC20(protocolToken).approve(address(pool), stakeAmount);
// Then stake
pool.stakeOnClaim(claimId, stakeAmount);

Tip: Assessors who vote with the majority typically earn rewards from the staking pool of those who voted incorrectly, aligning incentives with accurate assessments.

Vote and Reach Consensus

Staked assessors vote on the validity of the claim, with mechanisms to prevent manipulation.

Detailed Instructions

The core of decentralized adjudication is the voting round. CAs cast votes for ACCEPT (1), DENY (0), or potentially MORE_INFO. Voting power is proportional to the amount staked. Many protocols use a supermajority threshold (e.g., 70%) of total staked votes to reach a conclusion, preventing a simple 51% attack.

Sub-step 1: Cast Vote: Before the voting period ends, call voteOnClaim(uint256 claimId, uint256 vote).
Sub-step 2: Monitor Tally: Track the live vote tally via events or view functions like getVoteTally(claimId).
Sub-step 3: Await Finalization: The vote finalizes automatically when the period ends and the threshold is met, emitting a ClaimDecided event.

solidity
// Casting a vote as an assessor
claimsContract.voteOnClaim(claimId, 1); // 1 for ACCEPT
// Checking the current tally
(uint256 acceptVotes, uint256 denyVotes) = claimsContract.getVoteTally(claimId);
bool isAccepted = (acceptVotes * 100) / (acceptVotes + denyVotes) >= 70;

Tip: Some systems have a challenge period after voting where a high-stake assessor can dispute the result, triggering a new round with escalated stakes.

Execute Payout or Denial

The smart contract autonomously executes the community's decision, transferring funds or releasing stakes.

Detailed Instructions

Once consensus is reached, the claims contract enters the payout phase. If accepted, the contract calculates the payout amount based on the policy's terms and the proven loss, then transfers funds from the protocol's capital pool to the claimant. If denied, the claimant receives nothing, and assessor stakes are unlocked (with rewards distributed).

Sub-step 1: Trigger Payout: Anyone can call executePayout(uint256 claimId) to finalize an accepted claim, which is permissionless but often done by the claimant or a keeper bot.
Sub-step 2: Verify Transfer: The claimant should monitor their wallet for the inbound transfer of the payout asset (e.g., DAI, ETH).
Sub-step 3: Resolve Stakes: For assessors, call withdrawStake(uint256 claimId) to retrieve your original stake and any earned rewards after the claim is fully resolved.

solidity
// Executing a payout for an accepted claim
claimsContract.executePayout(claimId);
// An assessor withdrawing their stake and rewards
rewardsContract.withdrawStake(claimId);

Tip: Payout execution often involves complex logic, such as pro-rata payouts if the capital pool is insufficient, or converting locked cover assets into the payout currency.

Audit and Appeal (Optional)

Post-resolution mechanisms for disputing outcomes or investigating complex claims.

Detailed Instructions

Some protocols include an appeal or arbitration layer for contested decisions. This is typically a more formal, and often slower, process involving a dedicated panel or a decentralized court like Kleros. The appellant must usually stake a significant bond to initiate an appeal, which is forfeited if the appeal fails.

Sub-step 1: File Appeal: Within the appeal window, call appealClaim(uint256 claimId, bytes calldata appealData) with a new bond.
Sub-step 2: Escalate to Arbitrator: The case and all evidence are submitted to an external arbitration contract (e.g., 0xKlerosConnector).
Sub-step 3: Abide by Final Ruling: The arbitrator's ruling overrides the initial vote. The smart contract enforces the final payout or denial based on this input.

solidity
// Initiating an appeal with a bond
IArbitrableClaims appeals = IArbitrableClaims(0xAppealsAddress);
appeals.appealClaim{value: appealBond}(claimId, additionalEvidence);
// The arbitrator will later call a function like:
// appeals.executeRuling(claimId, ruling);

Tip: Appeals are costly and time-consuming, designed as a last resort for clear errors or highly subjective claims where the on-chain evidence is ambiguous.

attack-vectors

Common Covered Attack Vectors

Insurance protocols have historically paid out for specific, well-defined categories of technical failure and economic exploitation. This section details the primary attack vectors that have triggered successful claims.

Smart Contract Exploits

Logic bugs or vulnerabilities in protocol code leading to unauthorized fund access.\n\n- Reentrancy attacks allowing recursive withdrawals.\n- Integer overflows/underflows manipulating token balances.\n- Access control flaws permitting unauthorized privileged actions.\nThese are the most common and severe claims, as they directly drain user deposits from a protocol's core contracts.

Oracle Manipulation

Price feed attacks where an attacker artificially inflates or deflates an asset's price to exploit lending or derivatives markets.\n\n- Flash loan-powered price manipulation on a DEX to create bad debt.\n- Stale price data used for liquidations during high volatility.\nThis matters because many DeFi protocols rely on external, often decentralized, data sources for critical financial logic.

Governance Attacks

Malicious proposals or voting exploits that transfer protocol control or treasury funds.\n\n- A proposal disguised as a routine upgrade that contains a malicious payload.\n- Vote manipulation through token borrowing or flash loans to pass harmful changes.\nThis vector highlights the risks in decentralized governance models where code execution is tied to token-weighted votes.

Economic Design Flaws

Protocol mechanism failures where the intended economic model is exploited without a direct code bug.\n\n- Incentive misalignment leading to liquidity mining exploits and bank runs.\n- Improperly calibrated slippage or fee parameters enabling arbitrage at the protocol's expense.\nThese claims arise from flawed game theory, showing that secure code alone is insufficient for overall system safety.

Custodial & Bridge Failures

Breaches of trusted components that manage wrapped assets or cross-chain transfers.\n\n- Private key compromise of a multi-sig governing a bridge's minting function.\n- Validator collusion in a federated bridge to authorize fraudulent withdrawals.\nThis matters as bridges and custodial wrappers represent centralized points of failure within otherwise decentralized ecosystems.

DeFi Insurance Claims FAQ

The claim process begins with the claimant submitting a proof-of-loss to the insurance protocol's governance forum, detailing the transaction hashes, lost amounts, and the specific exploit vector. This triggers a claims assessment period, often 3-7 days, where appointed claims assessors or a decentralized committee reviews the evidence against the policy's covered perils. For example, a claim on Nexus Mutual for a hack requires demonstrating the loss resulted from a smart contract bug, not user error. The final payout, if approved, is executed via an on-chain vote and can take an additional 1-2 weeks to settle.

Further Resources and Protocols

Nexus Mutual Documentation

Protocol documentation covering coverage products, claims assessment process, voting mechanics, and historical claim outcomes.

Visit resource

Nexus Mutual Claims Statistics

Public dashboard with historical claims data, payouts, rejected claims, and incident-level breakdowns.

Visit resource

Rekt News Incident Archive

Independent reporting on major DeFi exploits with timelines, root cause analysis, and references to insurance responses.

Visit resource

DeFiLlama Hacks and Exploits Database

Aggregated dataset of DeFi hacks and exploits useful for cross-referencing insurance coverage and claim events.

Visit resource

Nexus Mutual Smart Contracts

Open-source smart contracts implementing coverage, claims assessment, staking, and governance logic.

Visit resource