Flare is an EVM-compatible proof-of-stake Layer 1 designed to make external data available to smart contracts through enshrined protocols. FLR is its native gas and staking asset, while wrapped FLR supports delegation and governance accounting. This page focuses on fLR, WFLR and FAsset Risks and the checks users need before sending funds, paying fees or using the network.
Understand how Flare data protocols and FLR roles affect transactions, delegation and FAssets.
Subject:
Flare
Market mode:
Snapshot Only
Fee asset:
FLR
Timezone:
UTC
This page does not validate an oracle value, recommend a data provider, guarantee an FAsset redemption or audit a contract.
Content ownership: BitcoinToolkit Editorial TeamTechnical references: Official protocol and developer documentation.Review approach: Technical explanations are checked against primary sources and updated when the network or asset changes.Last content review: Data integration last tested:
FLR, WFLR and FAsset Risks
Wrapping, delegation and cross-chain asset representation create distinct contracts and assumptions.
One native asset, several programmable roles
FLR pays gas and can be wrapped one for one into WFLR for delegation and governance-compatible accounting. Wrapping is not staking by itself, and delegated vote power does not give a provider custody of the token. Users still need FLR for ordinary gas.
FAssets represent external assets through over-collateralized agents, FTSO pricing and FDC verification. Minting and redemption depend on external-chain payments, collateral health, agents and protocol contracts. An FXRP or FBTC balance is not the native asset on its original chain.
Flare Operating Context
Smart contracts can consume network-supported data without every application building the same oracle path.
Execution and data consensus are separate
Flare executes Solidity contracts in an EVM environment and charges gas in FLR. Its distinctive systems coordinate providers that submit data and vote on supported values or external events. A valid Flare transaction can use those outputs, but it does not make every external claim trustworthy.
Developers must choose the correct data protocol, round and proof. Provider consensus, data freshness, supported source and application fallback behavior all matter. An application should expose when data is stale or unavailable instead of silently reusing an old value.
Time-series observations and event proofs answer different questions.
Flare confirmation does not settle every later operational question.
Continuous values versus requested facts
The FTSO publishes decentralized time-series feeds such as asset prices through repeated provider submissions and aggregation. Delegated WFLR vote power helps determine provider weight under current protocol rules. Delegation does not transfer ownership of the wrapped tokens.
The FDC processes requests about supported external events, gathers provider agreement and commits a Merkle root that contracts can verify with a proof. Attestation support, data age and confirmation rules vary by type and source, so a proof should be interpreted within its documented scope.
Protocol output, application logic and represented assets should be verified independently.
Inspect the full dependency path
Confirm Flare mainnet, contract addresses and FLR gas. For an FTSO value, check feed identifier, round and freshness. For FDC, check attestation type, source, proof and data-age limits. Never rely only on a frontend number.
For WFLR delegation, verify the provider and understand that rewards and accuracy can vary. For FAssets, review collateral, agent, redemption and external-chain requirements. Track both Flare and the source-chain transaction where the workflow crosses networks.
Check the official destination, current network, asset representation, amount, recipient and requested permissions. The Flare Time Series Oracle aggregates time-series values, and the Flare Data Connector reaches provider consensus on supported external events. Applications verify protocol outputs on-chain, while FAssets use these data systems plus collateral and agent mechanisms. After confirmation, inspect the resulting balance or protocol state instead of relying only on a wallet success message.
Known Limitations
Data protocols and supported sources evolve.
The page does not validate a live proof.
FAssets add collateral and agent risks.
Market Data Methodology
The page uses a CoinGecko aggregated FLR/USD snapshot. No exchange chart is rendered for this entity.
Market Snapshot Source
CoinGecko aggregated market data (FLR/USD)
Cache
Snapshot cache is approximately 60 seconds.
Failure Handling
Verified cached data is labeled Cached or Delayed. Missing values remain unavailable.
