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:
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.
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.
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 the cutover detail).
Activation
Deployments activate without waiting for a period boundary. Once the deployment transaction confirms:
The vault records the position in a single atomic transaction.
The deployment moves through compliance screening.
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.
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
Withdrawals are a two-step process: initiate, then claim.
Step 1: Initiate
The staker submits a withdrawal request specifying the amount to unstake. On submission the protocol records the request, the position enters the unstaking window, and the corresponding vault shares are locked or burned at the time of request.
The unstaking window for the coverage vault is longer than the window in Phase 1. 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. The exact length is a protocol parameter published before launch and adjustable by governance.
Step 2: Claim
After the unstaking window ends, the staker returns to claim the underlying. Claiming executes the final transfer from the vault to the staker's address. Claims are not automatic, a staker who initiates a withdrawal but never returns to claim leaves the assets at the vault until they submit the claim transaction.
Total effective lock
Because withdrawals align to the unstaking window rather than to periods directly, the total time a staker is locked out depends on when they initiate. In the worst case, a staker initiating close to a period boundary waits roughly the length of the unstaking window. The protocol does not add additional period-aligned waiting on top of the unstaking window.
Rewards during unstaking window
Rewards stop accruing at the moment a withdrawal is initiated, not when the claim is executed. A position in the unstaking window is no longer backing new coverage and no longer earning a share of protocol emissions.
Interactions with coverage matching
When a withdrawal becomes claimable, the vault's available capital decreases, and at the next period boundary the matching engine calculates capacity using the reduced balance. 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
Deployment activation
Without waiting for a period boundary
Reward streaming cadence
Regular (targeting steady daily accrual)
Unstaking window
Longer than Phase 1. Published before launch
Total effective lock
Up to the window length (plus time to return and claim)
Values are subject to governance adjustment after launch.
Where to read next
Emission Mechanics covers what accrues during an active position.
Risk and Exposure covers slashing and how deployments feed coverage capacity.
Last updated