> 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/protocol-architecture/claims-liquidation.md). # Claims Liquidation Once an assessment is approved, settlement runs automatically. The protocol draws the buffer, slashes the vault for any remainder, converts slashed collateral to stablecoins, and distributes to beneficiaries. This page covers settlement order, payout capacity, execution, shortfalls, and recovery. ### Settlement order Incidents settle FIFO by confirmation time. The first-confirmed incident pays first. The next pays from whatever remains. Each incident triggers exactly one slash, one liquidation, and one distribution. There is no repeat slashing for the same incident. ### Settlement cooldown Before any distribution executes, there is a **12-hour cooldown** after the distribution's Merkle root is published on-chain. The cooldown provides a final validation window: a distribution can be cancelled during this period if an error or a key compromise is detected. Once the cooldown elapses, settlement proceeds automatically. ### Payout capacity A single value bounds every payout: `totalPayoutCapacity = first-Loss buffer + market value of staked assets` Capacity is measured at settlement. No per-market cap applies at payout. Market caps govern cover sales only. If approved loss is within capacity, the incident pays in full. If it exceeds capacity, beneficiaries share what is available pro-rata. After each incident, capacity is reduced by the amount paid. ### The waterfall | Layer | Source | Behavior | | -------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------- | | 1. First-Loss Buffer | Protocol-owned stablecoin reserve | Absorbs the first tranche. If a prior incident depleted it, only the remaining balance is available | | 2. Vault slashing | Staker collateral | Absorbs the rest, pro-rata across positions, denominated in USD at the slash instruction | Vaults are never slashed beyond the instruction amount. Staker downside is bounded, and stakers cannot be forced into negative equity. Anything the buffer and slash cannot cover passes through to the beneficiary as a shortfall. A payout that only partially consumes a Cover Token leaves the remaining coverage in force for the rest of the period. ### Liquidation execution Slashed collateral is routed to the Liquidation Execution Service, which unwraps staked assets, such as `stXRP -> XRP`, and sells into payout currencies. Payouts are made in approved, audited stablecoins published on-chain. The Cover Token's preferred currency is filled first; if liquidity is short, the protocol falls back through the supported set or splits across currencies. Entitlement is always denominated in USD. Currency preference governs denomination, not the amount owed. At MVP, distribution to beneficiary addresses is performed manually by the Firelight Network multisig. Automated on-chain claiming is planned after MVP. Execution strategy scales with slash size: | Slash size | Strategy | | ------------ | ------------------------------------- | | `< $5M` | Exchange TWAP or VWAP | | `$5M–$25M` | OTC primary plus exchange residual | | `$25M–$100M` | Multi-OTC plus exchange TWAP | | `> $100M` | Syndicated OTC plus structured unwind | ### **Shortfalls** A beneficiary can receive less than the approved loss in three cases: a prior incident has already consumed payout capacity, collateral value declines before liquidation completes, or execution slippage reduces proceeds. In each case the shortfall is shared pro-rata - every beneficiary in the incident takes the same percentage reduction. The slash amount is fixed at the moment it is instructed. The protocol does not draw additional buffer or slash further collateral to cover execution friction, so staker downside is bounded and known at instruction time. If execution underperforms, the shortfall passes to beneficiaries; if it overperforms, the excess returns to the vault rather than topping up payouts. Execution strategy and the recovery process are designed to keep these outcomes rare and small. ### **Recovery** Settlement opens a recovery window, the length of which is published before launch. Assets recovered after payout — through white-hat return, law-enforcement action, or protocol-level recovery — flow back through the waterfall in reverse order of absorption: stakers are made whole first, and any remainder replenishes the First-Loss Buffer. The Firelight Network manages the recovery process off-chain. ### Where to read next * [Claims Process](/for-program-operators/claims-process.md) for the incident timeline. * [Risk and Exposure](/for-stakers/risk-and-exposure.md) for the staker-side view of vault slashing. --- # 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/protocol-architecture/claims-liquidation.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.