DeFi insurance platforms sell protection against specific onchain losses, such as a smart contract exploit, a stablecoin depeg or a custodian failure, funded by a pool of capital providers who earn premiums. The hard problems are not the contracts: they are deciding what counts as a valid claim, pricing risks with little history, and keeping the pool solvent when a large protocol fails.
How onchain cover works
- Capital providers deposit assets into a pool and earn a share of premiums. Their capital is at risk if claims are paid.
- A buyer selects a covered protocol or event, an amount and a period, and pays a premium.
- An incident occurs, and the buyer files a claim with evidence of loss.
- Claims are assessed by a vote, a committee, or an automatic trigger.
- Approved claims are paid from the pool, reducing capital providers' balances.
Claims models
Discretionary mutual
Nexus Mutual is the best-known example. It is structured as a discretionary mutual: members pool funds, and claims are decided by member assessment rather than paid as a contractual right. Membership requires identity verification. This structure was chosen partly so that the product is not legally insurance in the jurisdictions involved, which shows how much the legal design shapes the product.
Parametric cover
Payout is triggered automatically when a measurable condition occurs, such as a stablecoin trading below a threshold for a set period, or an oracle reporting a weather event. There is no claims assessment, so payouts are fast and resistant to bias. The trade-off is basis risk: the trigger may fire when the buyer had no loss, or fail to fire when they did. Etherisc has applied parametric designs to crop and flight-delay insurance.
Audit-linked coverage
Some security firms back their audits with coverage pools, so the auditor has capital at stake if audited code is exploited. This aligns incentives but concentrates exposure.
Comparing models
| Model | Claim decision | Speed | Main weakness |
|---|---|---|---|
| Discretionary mutual | Member vote or assessment | Days to weeks | Voter incentives, ambiguity in what is covered |
| Parametric | Automatic trigger | Fast | Basis risk, oracle manipulation |
| Committee-assessed | Appointed experts | Days | Centralization, conflicts of interest |
| Audit-linked | Contract terms with the auditor | Varies | Concentrated exposure |
Pricing and capital
There is little actuarial data for smart contract failure, and losses are correlated: one exploit of a widely used library or bridge can trigger claims across many covered protocols at once. Practical approaches:
- Capacity limits per protocol, so a single failure cannot drain the pool.
- Risk-based pricing using audit history, time live, total value at risk, upgradeability, admin key structure and dependencies.
- Capital models that size required capital against plausible worst cases, not average losses.
- Withdrawal delays for capital providers, so they cannot exit as soon as an exploit is announced.
- Reinsurance or backstops for tail events, where available.
Be careful about investing pool capital in yield strategies. Putting it into the same protocols you cover multiplies exposure.
Smart contract components
- Capital pool with share accounting, often an ERC-4626-style vault.
- Cover products as NFTs (ERC-721) recording terms, amount and expiry, so cover can be displayed and possibly transferred.
- Pricing module, with parameters set by governance or a risk team.
- Claims module: voting with staking and slashing for dishonest assessors, or oracle-based triggers.
- Governance and timelocks for parameter changes.
Covered protocols are typically lending markets, DEXs and bridges; understanding their failure modes, from lending liquidations to exchange settlement, is part of writing good cover wording. The guide to smart contract audits explains what audits do and do not catch, which is directly relevant to pricing.
Legal structure
Selling insurance is a licensed activity almost everywhere. Unlicensed onchain cover can be treated as insurance, a derivative or a collective investment, depending on how it is structured and marketed. Products are often called "cover" or "protection" for this reason, but naming does not settle the question. Plan the legal entity, membership rules and distribution restrictions with counsel before writing contracts.
Evaluating a build partner or platform
- Do they have people with insurance or risk modeling experience, not only Solidity engineers?
- Can they explain how claims would have been decided for past exploits?
- How do their designs handle correlated failures and capital-provider runs?
- Have previous contracts been independently audited, and are reports public?
Frequently asked questions
What does DeFi cover usually exclude?
Commonly excluded are losses from phishing, compromised private keys and price drops not caused by a covered event. Read the cover wording carefully.
Is parametric cover better than claims voting?
It is faster and less subjective, but buyers carry basis risk. It suits events that can be measured cleanly onchain, such as a depeg.
Can a cover pool go insolvent?
Yes, if claims exceed capital. Capacity limits, conservative capital models and withdrawal delays reduce, but do not remove, that risk.