For the complete documentation index, see llms.txt. This page is also available as Markdown.

88281 sc high coverorderallocator reuses collateral still backing previous period claims leaving new cover insolvent

Submitted on Aug 12th 2026 at 15:34:55 UTC by @Tradi3 for Audit Comp | Firelight

  • Report ID: #88281

  • Report Type: Smart Contract

  • Report severity: High

  • Target: https://github.com/immunefi-team/audit-comp-firelight/blob/v1_audit_ready/contracts/core/CoverOrderAllocator.sol

  • Impacts:

    • Protocol insolvency

Description

Summary

CoverOrderAllocator treats the vault balance at the start of the current period as available collateral. The same assets can still be paid to a valid incident from the previous period.

This allows the protocol to fully match a new cover order and charge its premium using collateral that remains liable for an older claim. If that older incident is reported after the new order settles, it consumes the backing already counted for the new cover. A later valid claim on the new order then receives only what remains, which can be zero.

The PoC uses the intended 1x configuration. The order curator creates two valid orders, the allocator commits and settles them, the incident curator reports two genuine incidents, and the assessment approver approves both losses within their respective allocations. None of those roles behaves maliciously or exceeds its permissions.

Root cause

CoverOrderAllocator._computeAvailableCapacity() derives current-period capacity from the vault's opening checkpoint:

commitAllocation() stores that capacity, and settlement later increases the amount of settled cover against it:

However, IncidentManager permits an incident from period P-1 to be created and approved during period P. FirelightVault.payout() then pays it from the vault's live assets:

No previous-period liability is reserved when period-P capacity is committed. Settlement also does not prevent an older, still-valid incident from being registered afterwards. The result is that the same vault collateral backs two consecutive periods of cover.

Reproduction sequence

  1. An LP deposits 1,000 units into the vault.

  2. A 1,000-unit cover order is created and settled for period 1.

  3. A second 1,000-unit order is created for period 2.

  4. At the start of period 2, totalAssetsAt(currentPeriodStart()) and the live vault balance are both 1,000. At 1x leverage, the allocator commits and settles exactly 1,000 units of new cover. The buyer receives the Cover NFT and pays the premium.

  5. Only after that settlement, a valid period-1 incident is reported and approved within the permitted payout window. It consumes the assets counted for period-2 capacity.

  6. A valid period-2 incident is then approved. With no first-loss buffer it closes with vaultPaidAmount == 0. With a real 100-unit first-loss buffer funded and fully approved, the period-2 claim receives only 100 of the promised 1,000 units.

Impact

A buyer can pay premium for fully matched cover that is not actually backed when its claim is processed. The PoC demonstrates a 100% shortfall with no first-loss buffer and a 90% shortfall with a funded 100-unit buffer.

This is protocol insolvency: settled cover exceeds the collateral still available to honor it. The problem occurs during capacity accounting, before either incident is approved.

This is separate from the disclosed aggregate-claims issue. The PoC uses two different orders in two different periods and one valid loss against each order. It follows FIFO and never claims the same cover twice. Adding a per-order remainingCoverage cap would not reserve collateral for the still-live period-1 liability before period-2 capacity is committed.

Do not make collateral available for new-period matching while it can still be claimed by the previous period. The protocol can reserve the maximum unresolved previous-period liability, segregate collateral by coverage period, or delay new-period settlement until the previous-period reporting window closes.

A one-time live-balance check during settlement is not sufficient because the older incident can be registered after settlement, which is the ordering used in the PoC.

Preconditions

The buyer cannot approve its own incident. The loss requires two genuine incidents to be processed by the intended roles in FIFO order. No compromised role, invalid assessment, excessive leverage, repeated claim, or first-loss-buffer failure is required.

Proof of Concept

Steps to reproduce

  1. Save the test below as test/PoC_ConsecutivePeriodDoubleUse.js.

  2. From the frozen v1_audit_ready checkout at commit 42f9ea5e43d88b35197b901acc2a8c24b314fa62, run:

Expected result:

The first case leaves the new period-2 claim with zero vault payment. The second funds and fully approves a real 100-unit first-loss buffer; the new claim still receives only 100 of the promised 1,000 units.

PoC SHA-256: CDE79D636A90AB8CC83A9BF4F7BA12A509452246E42874B078D73C6E783B929D

The two focused cases pass. Running this PoC together with the relevant allocator, incident-manager, and vault-payout regression suites passes 189/189.

Full runnable test

Was this helpful?