> For the complete documentation index, see [llms.txt](https://docs.firelight.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.firelight.finance/resources/cover-scope.md). # Cover Scope Firelight cover protects on-chain capital against defined technical and economic risks. This summary explains how that cover works: what is covered and excluded, the conditions an event must meet, the responsibilities of Program Operators, and how a validated incident leads to a payout. It is a plain-language overview and does not replace the governing documents listed below. Governing documents: * Scope of Firelight Cover Enablement: the categories of Covered Exploit Events, exclusions and conditions * Cover Enablement Order Form: the commercial terms of each cover request * Cover Enablement Support Services Agreement: the technical services provided by Firelight Networks * Firelight Network Terms of Participation: the rules for participating in the Firelight protocol, including the payout waterfall ### How cover works Cover runs in fixed 30-day Periods and applies only to the Covered Markets and peripheral smart contracts recorded in the [registry](https://github.com/firelight-protocol/firelight-markets/blob/main/registry.json) connected to the markets in your Cover Token.
ElementHow it works
Cover PeriodOne or more fixed 30-day Periods. Coverage, pricing and capacity align to Period boundaries.
Cover TokenAn ERC-721 token issued at Settlement recording your Covered Markets, per-market coverage amounts, rate, Period dates, Payout Recipient and status.
Covered MarketA specific chain, protocol and market (and pool, where relevant) approved by Firelight's risk process and recorded on your Cover Token.
Covered Peripheral InfrastructureConnected protocols (for example, an issuer of collateral used in your Covered Market) that are approved and recorded for that market. Technical risk coverage extends to them.
DetectionAn Independent Threat Detection Vendor (e.g., Hypernative) monitors Covered Markets in real time.
Exploit reportAn Independent Security Partner (currently ZeroShadow) publishes an independent report on each incident.
Loss assessmentFirelight Networks, acting as Incident Reporter, calculates proposed losses.
ValidationA five-member Risk Consortium approves or rejects each assessment by a 3-of-5 multisig vote.
Payout sourceA protocol-owned First-Loss Buffer, then staked Collateral, per the payout waterfall in the Terms of Participation.
### What is covered #### Technical Risks Technical cover applies when on-chain code, price data or governance mechanisms fail in a way that causes a verifiable loss to your Covered Position. | Risk | What qualifies | Examples | Not included | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Smart contract exploits | A bug or vulnerability in the Scheduled Protocol's deployed code is exploited on-chain, causing it to behave outside its documented specification. Includes flaws introduced by later upgrades. | Logic and arithmetic errors, reentrancy, access control failures, proxy upgrade errors, cross-contract interaction errors, token accounting errors such as donation attacks | Contracts working as specified, blockchain network failures, bugs in third-party contracts, unless recorded as Covered Peripheral Infrastructure | | Oracle failures | The protocol acts on a price that deviates from the true market price by more than 1% (stablecoins) or 2.5% (other assets), long enough for at least one exploitative transaction. | Faulty configuration, stale data, compromised data sources, price manipulation, oracle infrastructure failure, hardcoded price floor or ceiling errors | Deviations within the oracle's documented tolerance, liquidations on accurate prices, sequencer downtime itself | | Governance exploits | A malicious governance action passes only because of a technical or procedural weakness in the governance mechanism, and moves, destroys or locks funds. | Flash loan voting attacks, disguised malicious upgrades, governance contract bugs, emergency function abuse | Legitimate token accumulation, procedurally valid decisions, even if they cause losses |
The true market price is the median of the approved oracle providers in the Oracle and Venue Schedule (e.g., Chainlink, Chronicle, RedStone), including NAV-based oracles for liquid staking and similar derivative assets. #### Economic Risks Economic cover applies when a protocol's own mechanism malfunctions. Market conditions acting on a mechanism that works as designed are not covered. All three categories are subject to the duty to mitigate (see Program Operator responsibilities). | Risk | Trigger threshold | Qualifying mechanism failures | Not included | | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bad debt from mechanism failure | Your Bad Debt Share exceeds the greater of 5% of your Covered Position or USD 50,000. Applies to lender, LP and depositor positions. | Liquidations fail to execute, liquidations recover less than 80% of Fair Realizable Value due to mechanism design, collateral ratio or interest rate errors, cascading liquidations that exceed reserves, utilization manipulated as part of an exploit | Collateral illiquidity in external markets, depeg of an external collateral asset where the market's mechanisms work as designed, governance write-offs, position increases after the event | | Depegs caused by mechanism failure | A pegged asset issued or managed by the Scheduled Protocol trades more than 5% off peg for more than 4 consecutive hours, measured by VWAP across at least 3 liquid venues. | Redemption malfunction, collateral rebalancing failure, unauthorized or erroneous minting, stabilization mechanism that amplifies the depeg | Depegs where redemption works as designed, bank runs where redemptions process correctly, depegs of external collateral, procedurally valid governance changes to the peg | | Redemption failures | Your Covered Position cannot be withdrawn for more than 72 continuous hours, or a withdrawal returns less than 90% of fair value after disclosed fees. | Withdrawal queue malfunction, share or exchange rate accounting errors, liquidity calculation errors, funds locked by contract errors or erroneous pauses, infinite mint or drain exploits | Designed queues, cooldowns and epochs operating as documented, organically high utilization, network congestion, documented emergency pauses after which funds are released | Losses under these categories are measured at the end of a 24-hour Stabilization Period, or another period set by the Risk Consortium. ### Conditions every event must meet An event qualifies as a Covered Exploit Event only if all of the following hold: 1. It occurs during the Cover Period. 2. The loss is suffered by a Covered Position in a Covered Market listed in the Coverage Enablement Schedule and recorded on your Cover Token. 3. It is detected by the Independent Threat Detection Vendor, recorded on-chain as an Incident, and validated by the Risk Consortium. 4. Your position held funds in the affected Covered Market when the event occurred, based on the pre-exploit position reconstruction. 5. It is not excluded (see What is not covered). 6. For bad debt, depeg and redemption events, the duty to mitigate has been met. Three further rules apply across all categories: * One cause, one recovery. If an incident spans several categories, the Risk Consortium classifies it by its most proximate cause. No loss is recovered twice. * 24-hour grouping. All Covered Markets hit by the same root cause within 24 consecutive hours form one Incident. Each market is assessed against its own coverage amount. * Position snapshot. Any increase to your position after public disclosure of the exploit or its detection, whichever is earlier, is disregarded. ### Program Operator responsibilities Program Operators file no claim or report. Your main obligation is to take reasonable steps to limit losses in economic risk events, and to share information when asked. #### Duty to Mitigate For bad debt, depeg and redemption events, the payout may be reduced in proportion to losses you could reasonably have avoided. On-chain evidence is what counts: | Event | What demonstrates mitigation | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Bad debt | An attempted withdrawal or deleveraging once the protocol's health metrics showed material deterioration, or evidence that the mechanism failure prevented it | | Depeg | An attempted redemption through the standard mechanism once the deviation passed 5%. Reverted transactions, queue timeouts or error logs are sufficient. | | Redemption failure | An attempted withdrawal within a reasonable time of the exploit's public confirmation. A failed attempt counts as evidence of the failure. | Where an exploit is instantaneous, such as a single-transaction flash loan drain, and there was no reasonable chance to act, the duty is treated as met automatically. The Incident Reporter assesses mitigation from on-chain records and the Risk Consortium validates it. If the record is inconclusive, you carry the burden of showing compliance. #### Other conditions * Provide information reasonably requested, including evidence about your Covered Positions and mitigation steps. * Each Scheduled Protocol must use Hypernative monitoring, or an equivalent approved by Firelight Networks. Real-time detection is required to validate an exploit. * All known audit findings and risk registry items must be disclosed at coverage inception. Undisclosed findings may void cover for related exploits. ### From incident to payout Once the Risk Consortium approves an assessment, the payout waterfall runs automatically. Neither the Incident Reporter nor Firelight Networks can block, delay or override it.
The stated times are service-level targets, not protocol-enforced deadlines. The only hard limit is the resolution window: an Incident must be validated and settled before the end of the Period after the one in which it was created. Incidents may only reference exploits from the current or immediately preceding Period. ### How the Loss Amount is calculated The Loss Amount is the drop in your position's value in each affected Covered Market, converted to USD. * Formula: pre-exploit position value minus post-exploit position value, per Covered Market, as reconstructed by the Incident Reporter. * Timing: measured at the Time of Loss (the first exploit transaction) for technical risks, or at the end of the Stabilization Period for economic risks. * Bad debt: your loss is your Bad Debt Share, which is total Bad Debt in the market multiplied by your share of supplied capital. * Conversion: valued in USD using a reputable crypto pricing source chosen by Firelight Networks. The amount actually paid follows the payout waterfall in the Terms of Participation: the First-Loss Buffer first, then staked Collateral. Because Collateral is finite and fluctuates, a payout may be less than the validated Loss Amount. ### What is not covered Cover is limited to on-chain mechanism failures. Market risk, off-chain attacks, insider actions and anything outside your recorded markets are excluded.
CategoryExcluded
Market riskNormal volatility and correct liquidations on accurate prices
MEV and AMM propertiesSandwich attacks, frontrunning, other MEV, slippage within documented parameters, impermanent loss
Insider riskInsider theft, misappropriation, rug pulls, admin key abuse or multisig collusion, where evidence available to the Risk Consortium within the resolution window shows the loss resulted from these rather than a code-level exploit. Exploits of code vulnerabilities remain eligible even where an insider was involved.
Key compromise and social engineeringStolen, lost or misused private keys or signing credentials, and validly signed transactions obtained improperly
User errorWrong signatures, wrong addresses, misconfigured approvals
Frontend and off-chainPhishing, DNS hijacking, interface compromise, API, backend or keeper bot failures, wallet vulnerabilities
RegulatorySanctions, seizures, compliance actions, legal judgments
Known conditions at inceptionFlaws or vulnerabilities in the Scheduled Protocol or its Covered Peripheral Infrastructure that, before the Cover Period began, were publicly disclosed, already exploited in the protocol or a protocol it forks, identified in an audit made available to you, or acknowledged in your Order Form. Flaws that were unknown and undisclosed at inception are not excluded.
Depegs and utilization as designedDepegs where redemption works, withdrawals blocked by organic high utilization
External collateralCollapse of third-party assets that are not Covered Markets or Covered Peripheral Infrastructure, where your market's mechanisms work
Legitimate governanceOutcomes of legitimate token accumulation and voting
Blockchain failureChain halts, reorganizations, consensus failures, sequencer downtime
Force majeureAttacks by one nation on another, acts of war, protocol-level sanctions
TimingExploits occurring outside the Cover Period
Undeclared marketsChains, protocols or pools not on your Cover Token, including positions moved there mid-Period
Fraudulent onboardingMarkets onboarded mainly to procure a payout
Where an excluded cause and a covered failure both contribute, cover applies only if the covered failure is the proximate cause: the loss could not have occurred had the protocol's on-chain mechanisms worked as specified. ### Key terms
TermMeaning
Bad DebtThe amount by which a borrow position exceeds the Fair Realizable Value of its collateral, once it becomes a determinable loss to your position
Covered Exploit EventAn event within a covered category that meets all general conditions and is not excluded
Covered PositionThe portion of your vault's position in a Covered Market that has cover enabled
Fair Realizable ValueWhat collateral could reasonably have been liquidated for: VWAP across at least 3 liquid venues, or underlying redemption value for NAV-based assets
IncidentThe on-chain record created for a confirmed exploit, which sets its Period and settlement order
Payout RecipientThe address that receives payouts. Defaults to your Beneficiary Address unless you choose otherwise at order creation.
PeriodA fixed 30-day protocol period
Scheduled ProtocolA DeFi protocol hosting Covered Markets that meets all eligibility requirements
Stabilization Period24 hours after the Time of Loss, unless the Risk Consortium sets another period
Time of LossThe on-chain timestamp of the first transaction that triggers the event
**Note for Program Operators** The complete cover terms are available to all program operators. This text provides a summary of the current cover terms. Each Cover Token also references the current [terms of participation](https://framerusercontent.com/assets/94A1D2PPjoPAah8PWkJSqndH2C0.pdf) via its termURL. ### Important Notice Firelight cover is a conditional, collateral-backed release mechanism executed through smart contract logic. It is not insurance, an indemnity, a guarantee or a regulated financial service, and no Firelight Party acts as an insurer, broker or financial institution. Any payout is a claim on finite and fluctuating Protocol collateral and depends on sufficient staked assets at settlement. This summary is for information only. Cover is governed by the Cover Enablement Support Services Agreement, your Cover Enablement Order Form and the Firelight Network Terms of Participation. \ \
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.firelight.finance/resources/cover-scope.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.