Understanding the foundational mechanisms that enable financial protection for smart contract assets and protocols.
LABS
Guides
How Smart Contract Coverage Works in DeFi
Chainscore © 2025
core_concepts
Core Concepts of On-Chain Coverage
01
Coverage Policy
A smart contract policy is the core financial instrument, representing a binding agreement between a user and a coverage provider. It specifies the protected asset, coverage amount, premium cost, and policy duration. Users pay premiums to mint these on-chain NFTs. In the event of a verified exploit, the policy contract facilitates the payout of claims to the holder, transferring funds directly to their wallet.
02
Coverage Pool
A capital pool is a decentralized vault where liquidity providers (LPs) deposit assets like ETH or stablecoins to back potential claims. LPs earn premiums from policy sales as yield. The pool's solvency is critical; its total value locked (TVL) must exceed the sum of all active coverage limits. Automated risk models adjust premium pricing based on pool utilization and protocol risk scores to maintain balance.
03
Claim Assessment
Claim validation is the process of verifying that a smart contract exploit qualifies for a payout. It often involves decentralized dispute resolution, where a committee of experts or token holders votes on claim legitimacy using on-chain proof. This prevents fraudulent claims while ensuring legitimate victims are compensated. The assessment criteria are typically encoded in the protocol's governance rules, requiring transparent evidence of the hack's root cause.
04
Risk Parameters
Protocol risk scoring involves evaluating a smart contract's security posture to determine coverage costs. Factors include audit history, code complexity, total value locked (TVL), and historical incidents. These parameters dynamically influence the premium rate for policies covering that protocol. For example, a newly launched unaudited protocol will command a significantly higher premium than a battle-tested one like Aave, directly aligning cost with perceived risk.
05
Activation Trigger
A coverage activation is the specific on-chain event that makes a policy eligible for a claim. This is precisely defined in the policy terms, such as "a loss of user funds due to a verified exploit in the specified contract address." It excludes market volatility, admin key compromises, or frontend hacks. Clear triggers are essential for unambiguous claim adjudication and are often verified by oracle networks or multisig committees.
The Smart Contract Coverage Lifecycle
Process overview
1
Risk Assessment and Policy Selection
Analyze the contract and choose appropriate coverage parameters.
Detailed Instructions
Begin by conducting a technical risk assessment of the smart contract you intend to cover. This involves reviewing the contract's codebase, its dependencies, and the historical performance of its underlying protocol. Evaluate key risk vectors like reentrancy, oracle manipulation, and admin key compromise.
- Sub-step 1: Audit the contract's public functions and state variables for known vulnerability patterns.
- Sub-step 2: Analyze the protocol's Total Value Locked (TVL) and transaction volume to gauge potential loss magnitude.
- Sub-step 3: Select coverage parameters, including the coverage amount (e.g., 100 ETH), coverage period (e.g., 90 days), and deductible (e.g., 5%).
solidity// Example: Key state variables to assess in a lending protocol address public admin; uint256 public totalCollateral; mapping(address => uint256) public userDebt;
Tip: Use tools like Slither or Mythril for automated vulnerability detection as part of your initial assessment.
2
Premium Calculation and Staking
Determine the coverage cost and lock collateral with the coverage provider.
Detailed Instructions
The coverage premium is calculated dynamically based on the risk profile and selected parameters. Providers use algorithms that factor in the contract's age, audit status, and historical exploit data. The premium is typically denominated in the native asset (e.g., ETH) or a stablecoin and is paid upfront for the coverage period.
- Sub-step 1: Query the provider's premium quote by calling a function with your parameters:
getPremium(address _contract, uint256 _amount, uint256 _period). - Sub-step 2: Approve the premium amount for the coverage protocol's contract address.
- Sub-step 3: Execute the
purchaseCoveragetransaction, which also involves staking the coverage amount as collateral in a secure vault (e.g.,CoverageVault.sol).
solidity// Simulated premium quote interaction uint256 premium = ICoverageProvider(providerAddr).getPremium( contractAddr, 100 ether, // Coverage amount 90 days // Coverage period );
Tip: Premiums are non-refundable. Ensure you understand the exact coverage triggers before purchasing.
3
Active Monitoring and Proof of Loss
Monitor the covered contract and gather evidence if a covered incident occurs.
Detailed Instructions
During the coverage period, the contract should be monitored for any anomalous activity. A covered incident is typically defined as a loss of funds directly caused by a smart contract vulnerability. If a potential exploit is detected, you must immediately begin gathering cryptographic proof of loss.
- Sub-step 1: Capture the transaction hash of the malicious exploit and the block number where funds were drained.
- Sub-step 2: Document the pre- and post-exploit state of the contract using a block explorer, noting specific storage slot changes.
- Sub-step 3: Prepare a formal claim, including the exploit vector analysis (e.g., flawed logic in a
withdrawfunction) and the calculated loss amount in the vault's base asset.
javascript// Example: Fetching state changes via Ethers.js const preBlock = await provider.getBlockNumber() - 1; const postBlock = await provider.getBlockNumber(); const preState = await contract.getBalance(userAddress, { blockTag: preBlock }); const postState = await contract.getBalance(userAddress, { blockTag: postBlock });
Tip: Maintain off-chain records of all interactions with the covered contract to streamline the claims process.
4
Claims Adjudication and Payout
Submit the claim for validation and receive compensation if approved.
Detailed Instructions
Submit your compiled claim to the coverage provider's claims adjudication system. This is often an on-chain process involving a claims assessor or a decentralized committee. The assessor verifies that the loss resulted from a covered peril, matches the proof against the contract's state, and ensures the claim amount is accurate.
- Sub-step 1: Call
submitClaim(uint256 _policyId, bytes calldata _proof)on the coverage protocol, attaching your evidence. - Sub-step 2: The assessor reviews the claim, which may involve a voting period by token holders (e.g., 7 days).
- Sub-step 3: If approved, the locked collateral from the vault is released to your address, minus any deductible. A rejected claim can often be appealed.
solidity// Example claim submission in a contract interface interface ICoverage { function submitClaim(uint256 policyId, bytes memory proof) external; function getClaimStatus(uint256 claimId) external view returns (ClaimStatus); }
Tip: The adjudication process's transparency and the assessor's reputation are critical factors when selecting a coverage provider.
Comparison of Major Coverage Protocols
Key operational and financial metrics for leading on-chain coverage providers.
| Protocol Feature | Nexus Mutual | InsureAce | UnoRe |
|---|---|---|---|
Coverage Model | Mutualized Risk Pool | Capital Provider Pools | Reinsurance & Direct |
Smart Contract Cover | Yes (v2.0) | Yes | Yes |
Staking APY Range | 3-8% (NXM) | 15-40% (ACE) | 12-25% (UNO) |
Claim Assessment | Member Voting (7 days) | Adjudication Panel | Uno Claims Assessor (UCA) |
Cover Cost (Annual % of Cover) | ~2-4% | ~3-6% | ~2.5-5% |
Max Coverage per Protocol | $20M (Soft Cap) | $5M | $10M |
Governance Token | NXM | ACE | UNO |
Supported Chains | Ethereum, Arbitrum, Polygon | Ethereum, BSC, Polygon, Avalanche | Ethereum, Polygon, BSC |
Risk Assessment and Pricing Models
Understanding Coverage Pricing
Risk assessment is the process of evaluating how likely a smart contract is to fail. This directly determines the premium you pay for coverage. Think of it like car insurance: a risky driver pays more.
How Premiums Are Calculated
- Protocol Risk Score: Platforms like Nexus Mutual or InsurAce assign scores based on code audits, team reputation, and historical exploits. A newer, unaudited protocol has a higher score and cost.
- Cover Amount: The premium is a percentage of the total value you want to insure. Covering $10,000 in a vault costs 10x more than covering $1,000.
- Cover Period: Longer coverage terms (e.g., 90 days vs 30 days) typically have a higher total cost.
Example
If you deposit 1 ETH into a new yield farm, the coverage premium might be 2% per month due to its high risk score. For 3 months of cover on 1 ETH ($3,000), you'd pay $180 upfront.
claims_adjudication
Claims Adjudication and Governance
The process for validating, voting on, and paying out claims, governed by decentralized mechanisms to ensure fairness and protocol solvency.
01
Claim Submission and Validation
The claim filing process begins when a policyholder submits proof of a covered smart contract failure.
- Requires on-chain transaction data and a detailed incident report.
- Initial automated checks filter for completeness and policy eligibility.
- Invalid or fraudulent submissions are rejected at this stage to conserve governance resources.
- This gatekeeping is crucial for maintaining the protocol's efficiency and trust.
02
Security Council or Expert Panel
A technical committee of white-hat hackers and auditors provides the first layer of human review.
- They analyze the exploit's root cause and verify the loss is attributable to a covered risk.
- Their assessment and recommendation are published for token holders.
- This expert layer adds credibility and reduces the informational burden on general voters.
- It ensures complex technical events are judged accurately before a community vote.
03
Tokenholder Voting
Final approval is decided by a decentralized vote from governance token holders or specific coverage token stakers.
- Voters weigh the panel's report against the protocol's long-term health.
- Mechanisms like conviction voting or quadratic voting may be used to prevent manipulation.
- A successful vote authorizes the treasury to release funds to the claimant.
- This aligns payer and payer interests, as voters are financially incentivized to protect the protocol's reserves.
04
Payout Execution and Reimbursement
The settlement phase involves the automated transfer of funds from the protocol's capital pool to the verified claimant.
- Payouts are typically made in the stablecoin or native asset used for the premium.
- The protocol may then replenish its reserves by minting and selling new coverage tokens.
- This cycle maintains the capital pool's solvency for future claims.
- Timely, automated execution is critical for user trust following a security incident.
05
Dispute Resolution Mechanisms
Protocols implement appeal processes for contested claim decisions to ensure fairness.
- A rejected claimant can often escalate to a second, more specialized panel or a decentralized court like Kleros.
- This layer provides a check against potential voter apathy or collusion.
- Bonding mechanisms are used to discourage frivolous appeals.
- A robust dispute system is essential for the long-term legitimacy of decentralized insurance.
06
Governance Parameter Controls
Token holders govern key risk parameters that directly affect claims, not just individual cases.
- This includes voting on premium rates, coverage limits, and the types of contracts eligible for coverage.
- They can adjust the security council's composition or the voting quorum required for claim approval.
- Managing these parameters allows the community to dynamically respond to market risk and claim history.
- Effective parameter governance is fundamental to the protocol's actuarial soundness.
Technical FAQ on DeFi Coverage
The payout calculation is based on the verified loss amount and the policy's coverage limit. First, the claims assessor validates the incident against the policy's defined parameters, such as the specific contract address and exploit vector. The payout is then the lesser of the proven loss or the coverage cap, minus any applicable deductible. For example, if a pool with a $1M policy suffers a $1.5M hack, the payout is capped at $1M. If there's a 5% deductible, the final payout to the policyholder would be $950,000.