> 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/introduction/the-problem.md). # The Problem DeFi has grown into a multi-hundred-billion-dollar market, but the risks behind it remain largely uncovered. Users and institutions deploy capital into smart contracts every day without a reliable way to isolate and transfer the downside of a failure. They also do not enter into a traditional insurance contract when they deposit into a vault. ### DeFi risk is structural, not occasional Losses in DeFi do not come from a single cause. They come from a stack of interdependent layers: * **Blockchain risk:** consensus failures, validator issues, reorgs, and network-level incidents * **Protocol risk:** smart contract bugs, governance exploits, oracle manipulation, upgradeable proxy errors * **Asset risk:** depegs, thin liquidity, price collapses affecting collateral * **Strategy risk:** leveraged or composed positions where one failure cascades into others A failure at any lower layer propagates upward. A blockchain halt stops every protocol on that chain. An oracle manipulation can cascade into bad debt across multiple lending markets. Users rarely have a mechanism to isolate or transfer these risks. ### Traditional risk-transfer products do not fit Legacy risk-transfer products were not built for on-chain risk: * **Speed:** DeFi exploits resolve in hours. Traditional claims take months. * **Verifiability:** exploit evidence is on-chain and auditable in real time, but legacy carriers depend on manual investigation. * **Composability:** DeFi positions move across protocols every period. Traditional policies assume static exposure. * **Eligibility:** most institutional carriers do not back crypto-native risks at all. The result is a market where capital is deployed without coverage, where participants self-cover implicitly, and where a single exploit can wipe out returns across a whole portfolio. ### What a native coverage primitive needs DeFi needs coverage built into the product stack itself, not bolted on as a separate policy purchase. A native coverage primitive must be: * **Built into the product.** A program operator elects cover on the vault they run. * **On-chain and programmatic.** Coverage criteria, evidence, and payouts are applied by protocol rules. * **Transparent.** Capacity, premiums, and risk parameters are publicly visible. * **Fast.** Claims resolve in days, not months, with payouts in stablecoins. * **Composable.** Coverage integrates into vaults, lending markets, and structured products without custom wrappers. * **Reward-aligned.** Capital that backs coverage through staking is rewarded with protocol emissions linked to protocol activity. * **Distinct from insurance.** The mechanism transfers and isolates risk through protocol design. It does not create a contract of insurance between Firelight and the depositor. Firelight Coverage is built to meet these requirements. The rest of this documentation explains how. ### Next See [How Firelight Works](/introduction/how-firelight-works.md) for a one-page walkthrough of the full coverage flow. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.firelight.finance/introduction/the-problem.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.