Audit Comp | Firelight

Public Disclosure of Known Issues

Bug reports for publicly disclosed bugs are not eligible for a reward. The following describe the intended, permissioned design of the Phase 2 MVP and are not eligible unless a report demonstrates a protocol-constraint bypass or unauthorized privilege escalation:

• Firelight Phase 2 is intentionally permissioned and operationally centralized for the MVP. Trusted operators and role holders create and settle cover orders, submit matching commitments, assess incidents, approve or reject assessments, configure risk parameters, operate the first-loss buffer, and execute or coordinate payouts. Reports requiring these trusted parties to act maliciously or incorrectly within their documented privileges are not eligible unless they demonstrate that the role can exceed its intended authority or bypass an intended protocol constraint.
• Cover purchasers (referred to as "Program Operators" in the official docs) do not author orders directly in the MVP. Cover orders are authored by the operator/curator, with the purchaser's on-chain consent limited to premium token approval.
• The first-loss-buffer token is treated as USD-pegged and valued through decimal conversion, without a token-specific on-chain price oracle. Reports based only on the first-loss buffer token depegging, without a protocol bug causing or mishandling that depeg, are not eligible.
• The first-loss buffer (address) is an external, unescrowed wallet. The protocol relies on that wallet remaining funded and having the required token approvals when approved claims are paid.
• If the underlying staked asset decreases in USD value, available capital and the Capital Adequacy Ratio decrease. Severe collateral drawdowns can reduce coverage capacity and may cause shortfalls or undercollateralization relative to outstanding cover obligations.
• Aggregate claims are not capped on-chain against total cover sold. The MVP relies on trusted incident/assessment roles and the approval process to prevent duplicate, excessive, or otherwise invalid claims.
• Incident assessment and payout execution are permissioned. Reports requiring trusted assessors, approvers, operators, or payout coordinators to make intentionally incorrect business decisions are not eligible unless they demonstrate a protocol-constraint bypass or unauthorized privilege escalation.
• Final distribution from the configured payout receiver to end beneficiaries may involve off-chain/manual operational processes in the MVP.

Scope boundaries (out-of-scope code that may look in-scope)

• The legacy vault is not intended to be an in-scope asset. It is mentioned only as contextual upgrade reference for reviewing FirelightVault.sol and storage compatibility and new functionality.

The repository includes tests, local mocks, harness contracts, archived/reference contract copies, and third-party Flare/FAsset interfaces. Unless a file is explicitly listed in the Assets in Scope table, it is provided for context only and is not a competition target.

Notes for researchers (unusual design points)

• Program operators do not author their own cover orders in the MVP. Orders are submitted by a permissioned Firelight operator role (named curator in the contracts) on the program operator's behalf. The program operator's only on-chain action is the premium token allowance.
• FirelightVault intentionally deviates from standard ERC4626 withdrawal semantics. Withdraw and redeem create delayed withdrawal requests; users later call claimWithdraw.
• Matching is off-chain, while settlement is verified on-chain through Merkle proofs.
• A settled cover order mints an ERC721 receipt NFT; the NFT is not itself the payout asset.
• Incident payouts are assessed/approved by permissioned roles and paid to a configured payout receiver; beneficiary distribution is off-chain/manual in the MVP.
• The first-loss buffer is an external wallet, not escrowed in the protocol.
• The first-loss buffer token is assumed to be USD-pegged and is valued by decimal conversion rather than a token-specific oracle.
• CoverNFT pausing affects settlement, because settlement mints NFTs.
• Deposits are blocked during active incidents for the relevant period.
• First-loss buffer payouts use the configured buffer balance first, up to the approved assessment loss. Insufficient allowance is treated as an operational misconfiguration and may cause payout execution to revert. The payout logic intentionally does not cap the first-loss buffer leg by allowance before calling safeTransferFrom; if the wallet is funded but allowance is insufficient, payout reverts as an operational misconfiguration rather than falling back to the vault.

General Out of Scope and Rules

These impacts are out of scope for this program.

All categories

• Impacts requiring attacks that the reporter has already exploited themselves, leading to damage.
• Impacts caused by attacks requiring access to leaked keys/credentials.
• Impacts caused by attacks requiring access to privileged addresses (governance, strategist), except in cases where the contracts are intended to have no privileged access to functions that make the attack possible.
• Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code.
• Mentions of secrets, access tokens, API keys, private keys, etc. in GitHub will be considered out of scope without proof that they are in use in production.
• Best practice recommendations.
• Feature requests.
• Impacts on test files and configuration files unless stated otherwise in the bug bounty program.

Blockchain/DLT and smart contract specific

• Incorrect data supplied by third-party oracles (this does not exclude oracle manipulation / flash loan attacks).
• Impacts requiring basic economic and governance attacks (e.g., 51% attack).
• Lack of liquidity impacts.
• Impacts from Sybil attacks.
• Impacts involving centralization risks.

Websites and apps

• Theoretical impacts without any proof or demonstration.
• Impacts involving attacks requiring physical access to the victim device.
• Impacts involving attacks requiring access to the local network of the victim.
• Reflected plain text injection (e.g., url parameters, path). This does not exclude reflected HTML injection with or without JavaScript, or persistent plain text injection.
• Any impacts involving self-XSS.
• Captcha bypass using OCR without impact demonstration.
• CSRF with no state-modifying security impact (e.g., logout CSRF).
• Impacts related to missing HTTP security headers (such as X-FRAME-OPTIONS) or cookie security flags (such as "httponly") without demonstration of impact.
• Server-side non-confidential information disclosure, such as IPs, server names, and most stack traces.
• Impacts causing only the enumeration or confirmation of the existence of users or tenants.
• Impacts caused by vulnerabilities requiring un-prompted, in-app user actions that are not part of the normal app workflows.
• Lack of SSL/TLS best practices.
• Impacts that only require DDoS.
• UX and UI impacts that do not materially disrupt use of the platform.
• Impacts primarily caused by browser/plugin defects.
• Leakage of non-sensitive API keys (e.g., Etherscan, Infura, Alchemy).
• Any vulnerability exploit requiring browser bugs for exploitation (e.g., CSP bypass).
• SPF/DMARC misconfigured records.
• Missing HTTP headers without demonstrated impact.
• Automated scanner reports without demonstrated impact.
• UI/UX best practice recommendations.
• Non-future-proof NFT rendering.

Prohibited activities

• Any testing on mainnet or public testnet deployed code; all testing should be done on local forks of either public testnet or mainnet.
• Any testing with pricing oracles or third-party smart contracts.
• Attempting phishing or other social engineering attacks against the project's employees and/or customers.
• Any testing with third-party systems and applications (e.g., browser extensions) as well as websites (e.g., SSO providers, advertising networks).
• Any denial-of-service attacks executed against project assets.
• Automated testing of services that generates significant amounts of traffic.
• Public disclosure of an unpatched vulnerability in an embargoed bounty.