> 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/core-concepts/periods-and-coverage-cycles.md). # Periods and Coverage Cycles Firelight organizes time into fixed 30-day periods. Coverage, pricing, and capacity all align to period boundaries. This creates predictable cycles for program operators, stakers, and the Risk Consortium. ### Why periods Periods serve three purposes: * **Predictable pricing.** On-chain pricing parameters refresh every 30 days. Program operators know that a quote reflects the current period's published rates. * **Fair capacity allocation.** Coverage demand and supply are matched at period boundaries rather than continuously, which removes race conditions and enables pro-rata allocation under oversubscription. * **Bounded risk windows.** A 30-day coverage period limits the period during which a single set of coverage terms applies, reducing the protocol's exposure to stale assumptions. ### Period boundary sequence At each period boundary, the following happens in sequence: 1. **Pricing refresh.** The Cover Registry is updated with new base premium rates and available limits by protocol for each approved market. 2. **Capacity calculation.** The protocol computes available coverage capacity based on staked capital, the First-Loss Buffer, and effective leverage. 3. **Renewal matching.** Existing coverage holders who opted to renew are matched first. If renewal demand exceeds capacity, allocations are pro-rated by each holder's prior-period coverage amount. 4. **New order matching.** Remaining capacity is allocated to new orders, pro-rated by requested amount if demand exceeds capacity. 5. **Premium settlement.** Premiums for matched orders settle from the program operator's approved balance to the reward pool. Unmatched or partially matched orders receive proportional refunds. 6. **Coverage activation.** Matched coverage is issued as an on-chain coverage token and becomes active for the new period. Period settlement is **deterministic with respect to the period start timestamp**. Deployments and withdrawals submitted after a period has started do not affect the current period's settlement; they are picked up in the next period's capacity calculation. This makes each period's outcomes reproducible from its starting state. ### Mid-period mechanics Most operational activity happens at period boundaries, but certain components run continuously inside a period. #### Deployments Staker deployments do not wait for a period boundary, but they do move through screening before activation. Rewards begin only after the deployment becomes active. Deployments pause whenever an incident is opened, so capital entering after an incident does not absorb its loss. Deployments reopen when the slash settles, the incident is cancelled, or the next period begins. See [Claims Process](/for-program-operators/claims-process.md). #### Withdrawals An unstake can be initiated at any time, but the underlying only becomes withdrawable after the unstaking window: the remainder of the current period plus one full period. Periods are currently 1 day, so the unstaking window is currently 1 to 2 days. At the Feature-Complete launch, periods extend to 30-day cover periods to align with coverage obligations, so an unstake initiated at any point in a period becomes withdrawable at the end of the following period and the total effective unstaking window then ranges from 30-60 days. See [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals.md). #### Coverage scope within a period A Cover Token covers the markets declared when cover is enabled, up to the allocated amounts, for the full 30-day period. Coverage does not float between markets mid-period: a position that moves into a market not declared in the cover token is not covered for that allocation until the program operator renews with an updated declaration at the next boundary. ### Renewal vs. new order priority Renewals are processed before new orders at every boundary. This protects existing coverage holders from being displaced by incoming demand and gives program operators a reliable path to continuous coverage across periods. Within the renewal queue, allocation is pro-rata by prior-period coverage amount. First-come-first-served behavior is not used anywhere in the matching process. ### Why 30 days A 30-day period balances faster feedback on pricing and capacity against operational overhead and program operator friction, and aligns with institutional planning cycles. ### Where to read next * [Deployments and Withdrawals](/for-stakers/deployments-and-withdrawals.md) covers the supply-side mechanics of activation and unstaking. * [Pricing](/for-program-operators/pricing.md) explains how period-refreshed parameters produce a program operator quote. --- # 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/core-concepts/periods-and-coverage-cycles.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.