6.4. 20% Insurance Fund

The Insurance Fund represents a critical risk-mitigation pillar within the Fhenix-FairMarket economic architecture. Receiving 20% of the net fee distribution (equivalent to 0.06% of the winning bid), this fund is exclusively dedicated to acquiring parametric insurance coverage and maintaining a self-custodied capital reserve to protect users against low-probability, high-impact events.

By front-loading security funding before protocol scaling, the model ensures that user capital remains protected even in scenarios involving smart contract vulnerabilities, EigenLayer AVS consensus failures, or catastrophic CoFHE infrastructure degradation.

Core Allocation Mechanics

Economic Flow Example

For an auction with a winning bid of 100 ETH:

1. Success Fee (0.5%): 0.5 ETH collected.
2. Keeper Bounty (0.2%): 0.2 ETH paid to the executor.
3. Net Fee: 0.3 ETH remains for distribution.
4. Insurance Fund (20% of Net): Receives 0.06 ETH. (The remaining 0.24 ETH is split among Treasury, Grants, and Bug Bounties).

️ Technical Implementation

1. Deterministic Routing (InsuranceRouter.sol)

The Insurance Fund allocation is mathematically enforced at the smart contract level, ensuring no discretionary overrides.

// Conceptual Insurance Routing Logic
function _allocateNetFees(uint256 netFeeAmount) internal {
 require(netFeeAmount > 0, "No fees to allocate");
 
 // Insurance Fund receives 20%
 // Calculation: (netFee * 20) / 100
 uint256 insuranceShare = (netFeeAmount * 20) / 100;
 
 // Route to Insurance Vault (Multisig Controlled)
 insuranceVault.deposit(insuranceShare);
 
 emit InsuranceAllocation(insuranceShare, block.timestamp);
}

2. Parametric Coverage Integration

The fund is primarily used to purchase coverage from decentralized insurance protocols like Nexus Mutual or Unslashed Finance. This creates a secondary layer of protection beyond the protocol’s own code.

// Pseudo-code: Insurance Policy Management
interface IParametricInsurance {
 function purchaseCoverage(
 address coveredContract,
 uint256 coverageAmount,
 uint256 duration,
 bytes32[] calldata riskTypes // e.g., "SmartContractBug", "AVSFailure"
 ) external payable returns (uint256 policyId);
 
 function claimPayout(uint256 policyId, bytes calldata proof) external;
}
 
function _renewInsuranceCoverage() internal onlyGovernance {
 // Use accumulated Insurance Fund balance to purchase/renew coverage
 uint256 availableBalance = insuranceVault.balance();
 IParametricInsurance(nexusMutual).purchaseCoverage{value: availableBalance}(
 address(fhenixFairMarket),
 TOTAL_LOCKED_VALUE, // Dynamic coverage based on TVL
 90 days,
 ["SmartContractBug", "AVSConsensusFailure", "CoFHEInfrastructure"]
 );
}

3. Emergency Restitution Mechanism

In the event of a verified exploit where external insurance does not fully cover losses, the fund can be deployed for direct user restitution via governance vote.

// Emergency Restitution Function (Governance-Gated)
function _restituteUsers(address[] calldata victims, uint256[] calldata amounts) internal onlyGovernance {
 require(emergencyHaltActive, "Not in emergency state");
 
 uint256 totalClaim = 0;
 for (uint256 i = 0; i < amounts.length; i++) {
 totalClaim += amounts[i];
 }
 
 require(insuranceVault.balance() >= totalClaim, "Insufficient insurance funds");
 
 for (uint256 i = 0; i < victims.length; i++) {
 (bool success, ) = victims[i].call{value: amounts[i]}("");
 require(success, "Restitution failed");
 emit UserRestituted(victims[i], amounts[i]);
 }
}

Fund Flow & Coverage Architecture

️ Risk Coverage Scope

The Insurance Fund is designed to cover specific, well-defined risk categories:

Fund Management & Transparency

Accumulation & Deployment Cycle

1. Accumulation Phase: Fees flow into insuranceVault after each successful auction.
2. Threshold Trigger: When balance reaches X ETH (e.g., 10 ETH), governance proposes insurance purchase.
3. Coverage Purchase: Multisig executes _renewInsuranceCoverage() to buy parametric policy.
4. Monitoring Phase: Active policies are tracked via on-chain events and off-chain dashboards.
5. Claim/Restitution: Upon verified incident, funds are distributed via automated payout or governance vote.

Transparency Measures

• On-Chain Events: Every allocation and deployment emits indexed events (InsuranceAllocation, PolicyPurchased, UserRestituted).
• Public Dashboard: A dedicated Insurance Fund Dashboard displays:
• Current fund balance
• Active policy coverage amount & expiry
• Historical claims & payouts
• Risk exposure metrics
• Quarterly Reports: Governance publishes simplified reports summarizing fund health and risk posture.

Audit Gate Compliance (P1 - Pre-Mainnet)

Progression to Mainnet deployment requires the Insurance Fund module to pass the following verification gates:

• [] Deterministic Math Verification: Unit tests confirm the calculation (netFee * 20) / 100 is precise and handles dust correctly.
• [] Multisig Ownership: owner() of the Insurance Vault points to the Gnosis Safe (Multisig) address, not an EOA.
• [] Usage Restrictions: No function allows arbitrary withdrawal; all deployments require governance proposal + timelock.
• [] Event Transparency: InsuranceAllocation, PolicyPurchased, and UserRestituted events are emitted and indexed.
• [] Parametric Integration Test: Mock integration with Nexus Mutual interface successfully simulates policy purchase and claim flow.
• [] Emergency Restitution Test: Governance-gated restitution function correctly distributes funds to test addresses.

Unresolved Points & Explicit Gaps

Fact vs. Analysis Distinction: The 20% allocation rate, parametric coverage purpose, and multisig access controls are verified facts from the official Whitepaper and Technical Specification. The bootstrapping strategy, dynamic coverage formula, and cross-chain portability are unresolved architectural gaps that require explicit definition before Mainnet deployment.

Next Steps

• Proceed to 6.5. 15% Developer Grants to understand community incentive mechanisms and research funding.
• Review Security Model → Emergency Protocol for scenarios where Insurance Fund restitution is triggered.
• Explore Governance & DAO Transition for the multisig-to-DAO handoff procedure and insurance fund voting mechanics.