FTSO delegation
WFLR holders can delegate vote power to FTSO data providers and may receive a share of the rewards those providers earn. Results vary by provider performance, fees, weight, and protocol conditions.
Flare staking lets you put FLR to work through FTSO delegation, validator staking, or both. Flarestake helps you stake FLR with a self-custody flow, clear provider context, and no made-up reward-rate promises.
Flare staking covers two real participation routes: delegating WFLR vote power to FTSO data providers and staking FLR to validators on the P-chain.
On Flare, token holders can delegate wrapped FLR to FTSO data providers, which helps choose and weight the providers that support Flare's enshrined oracle protocols. A separate validator-staking path uses FLR on the P-chain, where stake is locked for a selected validator and period. Wrapping FLR into WFLR is used for FTSO delegation and governance vote power; validator staking is a distinct P-chain action, not the same thing as FTSO delegation.
To stake FLR, start with a compatible wallet, choose the correct Flare route, delegate or stake, then claim rewards when they become available.
Flarestake frames Flare staking as a choice between liquid FLR delegation through WFLR and time-locked validator staking. The documented staking path may require moving FLR from the C-chain, where smart contracts run, to the P-chain, where validator staking happens. FTSO delegation stays closer to ordinary wallet use: wrap FLR into WFLR, choose data providers, and keep custody while changing or removing delegation when needed. Step-by-step developer details are in the Flare developer staking docs.
Start with FLR on Flare Mainnet and a wallet that can connect to Flare apps. Keep enough FLR available for transaction fees before wrapping, delegating, claiming, or moving funds between chains.
For FTSO delegation, wrap FLR into WFLR. For validator staking, use the documented staking route, which may involve moving FLR from the C-chain to the P-chain before staking.
FLR delegation through WFLR supports FTSO data providers. Validator staking delegates stake to a validator on the network and locks FLR for the selected staking period.
Claim eligible rewards through supported Flare tooling when they become available. Some rewards can be wrapped after claiming, but rewards are variable and not guaranteed.
Flare staking rewards are variable and depend on protocol rules, provider or validator performance, participation weight, fees, and claiming behavior.
Do not present Flare rewards as fixed APY. FTSO delegation rewards are tied to the data providers a holder supports. Validator staking rewards depend on the selected validator and staking conditions. FlareDrops are now historical: official Flare materials state that FlareDrops concluded on January 30, 2026, and WFLR, rFLR, and staked FLR no longer accrue that reward component. Governance adds utility rather than a guaranteed yield stream. Delegations and reward claims are managed in the Flare Portal.
WFLR holders can delegate vote power to FTSO data providers and may receive a share of the rewards those providers earn. Results vary by provider performance, fees, weight, and protocol conditions.
Validator staking locks FLR on the P-chain for a selected validator and staking period. Rewards are tied to validator performance and the applicable Flare staking rules.
FlareDrops are historical, not an ongoing accrual source. Official Flare materials state they concluded on January 30, 2026, and no longer accrue to WFLR, rFLR, or staked FLR.
WFLR and staked FLR can carry governance vote power for eligible Flare proposals. Governance participation is utility and influence, not a guaranteed financial return.
The core network is Flare, the native token is FLR, and WFLR is the wrapped form used for delegation and governance.
Flare is an EVM-compatible Layer 1 with native FLR as its gas and staking asset. WFLR represents wrapped native FLR in an ERC-20 style contract, making it usable for FTSO delegation and governance vote power. FTSO is Flare's enshrined oracle system, where data-provider participation is weighted by community delegation and staking signals.
Self-custody means you control the wallet, but Flare staking still carries risk.
Users should verify official Flare apps and contract destinations before signing transactions, especially when wrapping, delegating, moving assets between chains, or staking to validators. Provider and validator selection matters because rewards can vary with performance, eligibility, fees, and protocol conditions. Smart-contract risk, wallet risk, validator downtime, market volatility, and lock-up timing can all affect outcomes. Flarestake copy should make the action feel straightforward without implying guaranteed returns.
Flare staking is the broad user action of putting FLR to work on Flare. It includes FTSO delegation, where users wrap FLR into WFLR and delegate vote power to data providers, and validator staking, where FLR is staked to validators on the P-chain. These are related but different mechanics. FTSO delegation supports Flare's data protocols, while validator staking supports network validation and uses a lock-up model.
To stake FLR, first hold FLR on Flare and connect a compatible wallet. If you want FTSO delegation, wrap FLR into WFLR and choose one or more data providers. If you want validator staking, use the documented Flare staking route and be ready for P-chain staking mechanics, including lock-up terms. Always verify the app URL, transaction details, and destination before signing.
Rewards can come from FTSO delegation or validator staking, depending on the route you choose. FTSO delegation rewards depend on data-provider performance, fee settings, participation weight, and protocol conditions. Validator staking rewards depend on the validator and staking rules. Any APY shown in an interface should be treated as indicative only. Rewards are variable, can change over time, and are not guaranteed.
FTSO delegation is the non-custodial delegation of WFLR vote power to Flare Time Series Oracle data providers. Data providers submit information used by Flare's enshrined oracle systems, and delegated weight helps determine provider influence and reward sharing. You keep control of your tokens while delegating, and delegation is different from locking FLR in validator staking. Provider quality and fees can affect outcomes.
FTSO delegation is designed to be non-custodial, so you can keep wallet control while delegating WFLR vote power. Validator staking is also wallet-directed, but the staked FLR is locked for the selected period. Both routes carry risk. Users should consider wallet security, smart-contract risk, provider or validator performance, transaction mistakes, market volatility, and whether they are using official Flare tooling.
For FTSO delegation, official Flare materials describe delegation as non-custodial and not locked, so users can change or remove delegation. Validator staking is different: staked FLR is locked for the staking period selected, and funds become available after the period ends. The shortest and minimum terms can change through protocol rules, so confirm current requirements in official Flare documentation before staking.