Firelight is preparing to turn $XRP-linked assets into capital that backs protection for DeFi users, offering holders a new source of yield in exchange for putting their collateral at risk.
The Flare-based protocol lets holders deposit FXRP, an $XRP-linked asset on Flare, into a vault and receive stXRP representing their position. Firelight’s next phase would use that deposited FXRP to back coverage sold to DeFi protocols. Customers pay premiums for the protection, and those payments generate income for the holders supplying the collateral.
The trade-off is that getting the collateral back could take much longer. Firelight’s withdrawal rules say its current one-day periods produce a withdrawal wait of roughly one to two days. Once the protocol introduces 30-day coverage periods, the same process would extend that wait to just over 30 days and, depending on when a holder asks to leave, nearly 60 days.
Rewards also stop when the withdrawal process begins, while an eligible claim tied to the period when the holder’s FXRP was backing coverage can still reduce the amount eventually returned.
That is the biggest issue for $XRP holders: Firelight can turn otherwise idle $XRP-linked assets into income-producing capital, but earning that income means accepting less immediate access to the collateral and the possibility of losing some of it to claims.
Firelight has already attracted substantial $XRP-linked capital ahead of that transition. DefiLlama displayed $71.74 million in Firelight total value locked in a Sept. 13 snapshot captured at 12:07 UTC.
That figure measures FXRP held in the vault, however, not the amount of protection Firelight has sold or the premiums customers have paid. Deposits show how much capital is available to back coverage. They do not show whether the coverage business can generate enough income to make the risk worthwhile for depositors.
Firelight’s Sept. 1 funding announcement scheduled the protocol and its first cover integrations for September without naming a launch day. Its withdrawal documentation still describes one-day periods as current, so the available evidence does not establish that coverage or the longer withdrawal setting has activated.
Why the exit gets longer
The longer withdrawal period comes from the role Firelight gives depositors’ FXRP. Once the coverage system is active, that collateral can be used to support protection sold to DeFi protocols. A holder therefore cannot necessarily remove it the moment they decide to leave because claims may still arise from the period when that money was backing coverage.
Under Firelight’s documented process, a holder initiates unstaking during one period and then waits until the end of the following full period before the FXRP becomes available to withdraw.
With one-day periods, that produces the current one-to-two-day window. With 30-day cover periods, the same rule would stretch the wait to just over a month for someone exiting near the end of a period and as much as 60 days for someone requesting an exit near the beginning.
The financial cost starts before the FXRP is returned. Initiating unstaking redeems the corresponding stXRP, records its redemption value, and stops the holder’s rewards. The pending withdrawal earns nothing further while the process runs.
Claim exposure follows a different clock. During the remainder of the period in which the holder asks to leave, the collateral continues backing coverage and can take a proportional loss from an eligible incident. During the following period, it no longer backs new coverage.
However, a claim tied to an earlier period when the collateral was still backing cover can still reduce the pending withdrawal.
That means the redemption value recorded when unstaking begins is an accounting snapshot, not a guarantee of the final amount the holder will receive.
Once the waiting period ends, the holder must submit another transaction to withdraw the FXRP. The assets remain in the vault until the transaction is submitted.
Completing Firelight’s redemption process therefore returns FXRP on Flare, not native $XRP directly to the $XRP Ledger.
Existing depositors also have a reason to watch the rollout. Firelight’s staking overview says positions from its initial phase automatically become active positions backing coverage when Phase 2 begins.
That is when depositors begin receiving income tied to coverage and taking on the corresponding risk of losses, without needing to complete a separate migration.
What actually pays the yield
Firelight is not native $XRP staking. Instead, it uses $XRP-linked assets on Flare as capital for a DeFi coverage business. FXRP supplies the collateral, stXRP represents the holder’s position in the vault, and FLR pays transaction fees on Flare.
Flare announced FXRP v1.2 on mainnet on Sept. 24, 2025. Its FAssets system creates representations of assets such as $XRP that can be used in applications on Flare. That infrastructure made $XRP-linked capital available to Flare applications. Firelight adds another use for it by putting FXRP behind protection sold to DeFi protocols.
The economically important source of income is the money customers pay for that protection.
Firelight’s emissions documentation says settled premiums are converted into the vault’s collateral asset and added to the value of depositor positions. Its July 23 Phase 2 explanation describes stablecoins being converted into FXRP and returned to staker positions. In practice, customers pay for coverage, and those payments can become additional FXRP for the holders supplying the collateral.
Firelight also has separate protocol incentives and Firelight Points. Those are different from income generated by customers buying coverage. Points track participation and provide no claim on premiums. They therefore cannot show how much customers are paying Firelight or how much income its coverage business is generating. That distinction is important because customer premiums are what could make the model sustainable after incentives fade.
For $XRP demand, the premium conversion mechanism is also the most significant part of the model. Recurring customers paying for coverage could fund recurring purchases of FXRP, while holders who keep that income in the vault would leave more collateral available to back additional coverage.
But an FXRP purchase does not necessarily require a new purchase of native $XRP. FXRP can already exist and change hands in a secondary market. Nor does issuing stXRP create another independent pool of $XRP. stXRP represents a claim on FXRP already deposited in Firelight.
Counting $XRP, FXRP, and stXRP as three separate additions to demand would therefore count different layers of the same capital more than once.
The test is whether paying customers bring in enough recurring income to retain and grow the collateral pool after withdrawals and claims.
The reserve comes before staker losses
The income comes with the possibility that some collateral will eventually be needed to pay a claim. Firelight does not send a valid claim directly to depositors first. It has a separate reserve designed to absorb losses before staked FXRP is affected.
Under Firelight’s documented loss waterfall, a protocol-owned stablecoin reserve called the First-Loss Buffer absorbs validated claims first. Any amount remaining after that reserve is exhausted reaches vault positions proportionally. That means a holder can retain the same number of vault shares while the amount of FXRP those shares can redeem falls.
Slashed collateral is sent to a liquidation service and converted into stablecoins used to pay claims. A sufficiently large loss can therefore remove assets from the same collateral pool that premium income is intended to grow.
The size of the First-Loss Buffer is consequently as important as the fact that it exists. Without a verified current buffer balance and information about how much coverage it supports, the first-loss structure does not show how much protection depositors actually have.
The available documentation establishes the order in which losses would be absorbed. It does not establish the size of a current loss cushion or show that a paid claim has occurred. Firelight also limits how much coverage it can support relative to the assets available to absorb losses.
Its capital-adequacy framework compares the resources available to cover losses with the amount the protocol needs to support its coverage commitments. The documentation sets a target ratio of 1.75 to 2.0 at feature-complete launch and prevents new coverage from being allocated if that ratio falls below 1.2.
In simpler terms, Firelight is designed to stop taking on additional coverage when the assets available to absorb losses become too small relative to its existing obligations.
Collateral prices can affect that calculation even when no claim occurs. Because the value of staked assets forms part of Firelight’s available capital, falling prices can reduce its financial cushion. For holders, the risk therefore goes beyond whether a claim occurs. Their FXRP can also remain unavailable during a sharp market move while the withdrawal process runs.
A secondary-market sale of stXRP could provide another way to leave, but that depends on available liquidity and the price buyers are willing to pay. It is not the same as immediately redeeming the position for its recorded value.
The demand test starts with paid cover
Firelight’s roughly $72 million in deposited assets shows that $XRP holders have been willing to supply collateral. It does not show whether Firelight has built a business around that collateral.
That distinction affects both the yield depositors can earn and any effect Firelight could have on demand for $XRP-linked assets.
Dollar-denominated TVL can rise because more FXRP enters the vault, because FXRP’s price rises, or both. The dollar figure alone therefore cannot show how much new $XRP-linked capital has entered Firelight.
More importantly, deposits are only one side of the market. Firelight needs customers willing to pay for protection on the other side. If those customers repeatedly pay premiums and those premiums are converted into FXRP, the system could create recurring demand for the asset while adding income to depositor positions.
But TVL alone cannot show whether that is happening.
Paid coverage, settled premiums, the size of the First-Loss Buffer, claims and completed withdrawals would provide a clearer picture of whether Firelight is developing an income-producing coverage business around its $XRP-linked collateral.
Those numbers would also show whether premium income is large enough to offset withdrawals and losses and leave more FXRP in the system over time. Until then, the proposition for $XRP holders is easier to measure than its eventual effect on $XRP demand.
They supply FXRP that Firelight can use to back DeFi coverage. Customers pay for that protection, creating a potential source of income for the people supplying the collateral. In exchange, holders give up some liquidity and accept the possibility of losses.
Once Firelight moves to 30-day coverage periods, withdrawals could take roughly 30 to 60 days. Rewards stop when the holder asks to leave, while an eligible claim tied to the period when the collateral-backed coverage can still reduce the amount eventually returned.
The question is whether customers will pay enough for DeFi protection to make that trade worthwhile.
Firelight’s deposits show that it has attracted the capital. Its coverage business will determine whether that capital can earn enough to justify the wait and the risk.
