Audit Comp | Firelight
Firelight is an on-chain cover protocol. The contracts implement an upgradeable ERC4626-compatible vault for staked collateral, an off-chain-matched cover order allocation flow, cover receipt NFTs, incident assessment and payout execution, a vault reward distributor, and a Flare FTSO v2 price adapter exposed through a Chainlink AggregatorV3-compatible read surface.
Evaluating
Triaged by Immunefi
Runnable PoC Required
Vault program
This Audit Competition Is Under Evaluation
Competition timeline
This timeline may change depending on the competition progress and Immunefi needs
| Milestone | Date |
|---|---|
| Announcement | Aug 10, 2026 |
| Launch (competition goes live) | Aug 12, 2026 |
| Competition ends | Aug 25, 2026 |
| Project deadline to resolve all reports | Aug 31, 2026 |
| Results frozen and calculated | Aug 31, 2026 |
| Final 48-hour dispute deadline | Sep 11, 2026 |
| Payment complete | Sep 30, 2026 |
| Results published | Sep 30, 2026 |
Immunefi vault program
Rewards
Rewards by Threat Level
Rewards are distributed among SRs according to Immunefi's Standardized Competition Reward Terms, and include the All Star Pool and Podium Pool reserved for All Star Program participants. Rewards are denominated in USD and distributed in USDC on Ethereum.
- If any valid bug is found — even a single Low-severity bug — the full reward pool of $20,000 USD is unlocked and must be fully distributed among security researchers.
- If no security vulnerability is found (Insights do not count as bugs), the reward pool is $3,000 USD.
Private Known Issues Reward Policy
Private known issues — known issues that were not publicly disclosed — are valid for a reward at their full severity and unlock the corresponding reward pool without any downgrade. Public known issues are invalid.
Program Overview
Firelight is an on-chain cover protocol. The contracts implement an upgradeable ERC4626-compatible vault for staked collateral, an off-chain-matched cover order allocation flow, cover receipt NFTs, incident assessment and payout execution, a vault reward distributor, and a Flare FTSO v2 price adapter exposed through a Chainlink AggregatorV3-compatible read surface.
The MVP is intentionally permissioned: trusted operators create and settle cover orders, submit matching commitments, assess incidents, and execute approved payouts. The contracts enforce role boundaries, capacity checks, settlement constraints, payout accounting, withdrawal delays, blocklist/rescue controls, and asset transfer paths.
This audit covers Firelight Phase 2, as described in the Firelight documentation. For more information about Firelight, please visit https://docs.firelight.finance.
Technical Project Information
System overview and upgrade context
One existing deployed contract is being upgraded: the legacy predeposit vault (contracts/legacy/FirelightVaultPredeposits.sol, with storage in contracts/legacy/FirelightVaultStoragePredeposits.sol). The upgrade implementation is contracts/core/FirelightVault.sol, with V2 storage in contracts/core/FirelightVaultStorage.sol. Reviewers should compare the legacy vault and the V2 vault for storage compatibility and behavior changes. All other in-scope Phase 2 contracts are new deployments.
Upgrade context
FirelightVault.sol is the V2 upgrade implementation for the already-deployed legacy predeposit vault (contracts/legacy/FirelightVaultPredeposits.sol), deployed on Flare at 0x4C18Ff3C89632c3Dd62E796c0aFA5c07c4c1B2b3. Reviewers should examine both the new V2 behavior and its compatibility with the legacy vault storage/layout. The legacy contracts (contracts/legacy/FirelightVaultPredeposits.sol and contracts/legacy/FirelightVaultStoragePredeposits.sol) are included to support upgrade-diff and storage-compatibility review. All other in-scope Phase 2 contracts are new deployments.
Priority areas of concern
Firelight is most concerned about:
- Commitment and settlement correctness in
CoverOrderAllocator. - Capacity calculation and solvency constraints.
- Incident/payout accounting: FIFO priority, payout-window behavior, assessment loss validation, first-loss buffer waterfall, vault payout bounds, and interaction between multiple incidents in the same period.
- Upgradeability safety for the upgradeable contracts.
- External price and token assumptions, especially FTSO adapter behavior.
Standardized Rules
This program follows Immunefi's standard competition rules. For the full default rules on validity, duplicates, known issues, severity, disputes, KYC, payments, and publication, read How Audit Competitions Work: Rules and Policies. Where this program page defines a specific rule, the program page prevails.
Proof of Concept (PoC) Requirements
A runnable PoC is required. For more information, please read the Web3 PoC Guidelines.
Insight Reporting
- Insight reports may be submitted to this program. Runnable code is not required, but the PoC section must describe the conditions under which the insight is valuable.
- Only the best report of a given Insight is rewarded. Duplicates of Insights are not rewarded.
- Insights are rewarded according to Immunefi's Standardized Competition Reward Terms and are not eligible for mediation or appeal.
Dispute Resolution
- Disputes may only address report validity, duplicate determinations, and severity.
- If a researcher disagrees with a closure decision while the competition is live, they may request mediation. A mediation fee, set by Immunefi, is required to initiate the review.
- After the evaluation phase, a dispute period opens for appealing decisions. Immunefi announces a final 48-hour deadline for the last disputes. Once the window closes, results are final.
- Immunefi has final say on validity, duplicates, and severity, based on the terms of this program. Insights are not eligible for mediation or appeal.
Responsible Publication Policy
Immunefi will publish bug reports, earnings, and a leaderboard for this Audit Competition. Security researchers may publish their bug reports as well, but only after Immunefi has published the valid bug reports as part of the competition results.
Eligibility Criteria
Security researchers who wish to participate must adhere to the rules of engagement set forth in this program and cannot be:
- On OFAC's SDN list.
- An official contributor, past or present.
- Employees and/or individuals closely associated with the project.
- Security auditors that directly or indirectly participated in an audit review of the code in scope (such auditors may participate only if they receive project permission).
- From a restricted country or territory per Immunefi's Terms of Use.
- Under 18 years of age. Participants under 18 cannot pass KYC and will not receive rewards.
Submission Fees
A submission fee, set and managed by Immunefi, applies to each report and is shown at submission time. If a researcher disagrees with a closure decision, initiating a mediation also requires a fee set by Immunefi.
Audits
Completed audit reports for this project can be found at the links below.
Any unpatched or unresolved vulnerabilities disclosed in these reports are not eligible for rewards.
Known Issues
Reports covering previously identified bugs listed below are not eligible for rewards under this program.
This includes:
- Known issues that the project is aware of, even if no fix or code changes have been implemented.
- Issues the project has consciously decided not to remediate.
- Cases where operational mitigations or procedures have been implemented to reduce potential risk.
KYC not required
No KYC information is required for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.