> 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 30 days, so the unstaking window is currently 30 to 60 days. {% hint style="info" %} The launch of the Feature-Complete protocol on October 6, 2026 transitioned the length of periods from 1 day to 30 days, effectively increasing the unstaking and withdrawal window to 30-60 days. See [Deployments and Withdrawals](/for-stakers/deployments.md). {% endhint %} #### 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.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 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/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 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.