> 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/for-stakers/deployments-and-withdrawals.md).
# Deployments and Withdrawals
This page covers the operational mechanics a staker encounters when entering or exiting the Firelight vault: the prerequisites for staking, activation of new deployments, the unstaking window, and the period-level behavior that governs both.
### Prerequisites: getting stXRP
Staking into the Firelight protocol uses stXRP, the staking token Firelight launched with in Phase 1. New stakers go through the same three-step prerequisite chain that has applied since launch:
1. **Obtain FXRP.** Wrap XRP into FXRP via Flare's FAssets system. FXRP can also be acquired on supported EVM chains or exchanges and bridged to Flare. See the Flare and FAssets documentation for the deep walk-through.
2. **Obtain FLR.** FLR is the native token of the Flare network and is needed for gas on Flare. A small balance is enough for the staking flow.
3. **Stake FXRP into the Firelight protocol.** Approve and deploy FXRP through the Firelight interface; the protocol issues stXRP representing your position. The stXRP balance is what backs cover.
After the cutover to Phase 2, stXRP held in the Phase 1 is **automatically converted** to an active staked position in the protocol. No staker action is required for the migration itself (see [Staking Overview](/for-stakers/staking-overview.md) for the cutover detail).
#### Activation
Deployments activate without waiting for a period boundary. Once the deployment transaction confirms:
1. The vault records the position in a single atomic transaction.
2. The deployment moves through compliance screening.
3. Once screening clears and the deployment becomes active, it is added to the protocol's staked balance and rewards begin streaming.
A deployment made late in a period earns rewards for the remainder of that period once active. There is no waiting for the next boundary to start earning. Slashing exposure begins at the same moment: once a deployment is active, its capital is part of the backing and takes any pro-rata slash from a validated claim, even in its first period.
The diagram shows a stake entering mid-period (Day 45 of Cover Period 1). It begins earning protocol emissions immediately once active, and assumes slashing exposure at the same moment. There is no waiting for the next period boundary.
{% hint style="info" %}
Periods are currently **1 day** long, so the unstaking window is currently 1 to 2 days. The day counts highlighted above reflect the **30-day cover period** lengths that take effect when the Feature-Complete Launch is live.
{% endhint %}
#### What counts toward coverage capacity
Although deployments activate immediately for base rate emissions, they count toward coverage capacity at the next period boundary, when the matching engine recomputes capacity for the following period. In practice a mid-period deployments starts earning base rate emissions right away, while its contribution to new coverage allocation shows up in the next period's capacity calculation. This is a consequence of deterministic period settlement: each period settles based on its starting state, so mid-period flows take effect in the next period.
#### Steps
The deployment flow follows the same pattern Firelight launched with in Phase 1 against the Launch Vault: approve the vault to spend stXRP, call deployment, and receive the vault position. Stakers who used the original flow will find no interface changes for the basic deployments.
### Withdrawals
Unstaking is a two-step process: initiate, then withdraw.
#### Step 1: Initiate
The staker submits an unstake request specifying the amount to unstake. On submission the protocol records the request and the position enters the unstaking window. The corresponding stXRP is redeemed at the time of request a snapshot of its redemption value is taken. Redemption ends emissions accrual immediately and removes the position from the next period boundary's coverage-capacity calculation.
{% hint style="info" %}
The unstaking window is **one full period after the period in which the unstake is initiated**: the underlying FXRP becomes withdrawable at the end of the period following the unstake.
**Currently (1-day periods):** the unstaking window is 1 to 2 days, depending on when in the day the unstake is initiated.
**At the feature-complete launch (30-day cover periods):** the same mechanic applies to 30-day cover periods, so the window extends to just over 30 to 60 days. Because staked collateral is actively backing in-force coverage, the window is set so that capital cannot exit ahead of the coverage obligations it backs.
{% endhint %}
#### Step 2: Withdraw
After the unstaking window ends, the staker returns to withdraw the underlying. Withdrawing executes the final transfer from the vault to the staker's address. Withdrawals are not automatic, a staker who initiates an unstake but never returns to withdraw leaves the assets in the vault until they submit the withdrawal transaction.
#### Unstaking Window
Since the unstaking window ends at a period boundary rather than a fixed number of days after initiation, the total length of the unstaking window depends on when in the period they initiate. With today's 1-day periods, this means an effective lock of 1 to 2 days. The protocol does not add additional waiting on top of the window.
The diagram shows two unstake scenarios (Day 10 and Day 29 of Cover Period 0) that both become withdrawable at the same moment at the end of Cover Period 1. These scenarios show Feature-Complete Cover Period lengths.
**Slash exposure during the unstaking window**
Redeeming the stXRP ends reward accrual, but it does not end slashing exposure. The window has two phases:
**Backing coverage:** Your capital is still backing coverage in Firelight for the remainder of ther period where you initiated the unstaking process. If an exploit incident occurs during this period, the pending withdrawal takes the same pro-rata slash as active positions.
**Reconciliation window:** Your capital no longer backs new coverage and is not exposed to incidents that occur in this period. However, if an exploit incident is attributed to a period in which your capital was still backing coverage, the resulting slash still applies to the pending withdrawal.
#### Rewards during unstaking window
Emissions stop accruing at the moment an unstake is initiated because the stXRP is redeemed at initiation and its redemption value is snapshotted then. A position in the unstaking window earns neither base rate emissions nor a share of protocol emissions.
### Interactions with coverage matching
When an unstake is initiated, the redeemed stXRP is excluded from the next period boundary's capacity calculation. This is handled by the protocol. From the staker's perspective the only concern is the unstaking window length.
### Blocklist and rescues
Vaults implement a blocklist to comply with regulatory requirements. Blocklisted addresses cannot deploy, withdraw, or transfer. Authorized roles can rescue assets from blocklisted accounts and reassign them to a non-blocklisted address, preserving the position without violating compliance constraints. Most stakers never interact with these mechanics.
### Summary of operational parameters
| Parameter | Value at feature-complete launch |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Deployment activation | Without waiting for a period boundary |
| Reward streaming cadence | Regular (targeting steady daily accrual) |
| Unstaking window | One full period after the period of initiation. Currently 1–2 days with 1-day periods. Extends to 30-day cover periods at the feature-complete launch with unstaking window range being 30-60 days |
Values are subject to adjustment after launch.
### Where to read next
* [Emission Mechanics](/for-stakers/emission-mechanics.md) covers what accrues during an active position.
* [Risk and Exposure](/for-stakers/risk-and-exposure.md) covers slashing and how deployments feed coverage capacity.
---
# 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/for-stakers/deployments-and-withdrawals.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.