Flare flr

Flare Network is an EVM-compatible Layer 1 blockchain built around native access to external data. Its design targets data-intensive and interoperable applications rather than treating oracles and cross-chain messaging as purely external add-ons. The network uses FLR for transactions and its core data protocols are integrated into the Flare Systems Protocol, so their operation receives the network's economic security.

The principal native protocols are the Flare Time Series Oracle (FTSO), which supplies decentralized time-series data such as asset prices, and the Flare Data Connector (FDC), which lets applications obtain attestations about external blockchain events and real-world APIs. Flare also develops FAssets for bringing assets such as XRP, BTC and DOGE into EVM applications, and is adding confidential-compute capabilities based on trusted execution environments.

Flare is EVM-compatible and exposes Solidity/Ethereum tooling, making it possible to use familiar smart-contract workflows while consuming its native data services. The official developer hub identifies Flare mainnet as chain ID 14 and provides the mainnet RPC and explorer configuration. The public Flare Foundation GitHub organization maintains the node implementation, protocol contracts, SDKs, deployment tooling and starter projects.

Smart contracts cannot natively inspect another blockchain, a web API or a live market price. Applications that need that information traditionally depend on bridges, centralized APIs or separate oracle networks, creating additional trust assumptions, integration complexity and failure modes. This makes cross-chain finance and data-driven applications difficult to secure while preserving composability.

Flare addresses this by putting data acquisition mechanisms at protocol level. FTSO supplies economically incentivized price and time-series estimates, while FDC uses attestation requests and verification to make external events available on-chain. The approach is intended to let developers build applications that use external data without making every application operate its own bespoke data relay.

Flare runs as an EVM-compatible proof-of-stake network using Avalanche consensus. FLR is the native fee and spam-control token; FLR also carries vote power that can be delegated. WFLR is a one-to-one ERC-20 representation of FLR used for programmable delegation and governance functions, allowing holders to delegate votes without transferring the underlying tokens.

FTSO providers submit estimates for supported feeds. The original protocol paper describes commit/reveal submissions and a weighted-median calculation, with rewards for estimates inside the weighted interquartile range; in practice, token holders can delegate vote power to data providers. The current developer documentation presents FTSOv2 as an enshrined, fast price-feed protocol.

FDC lets users submit deterministic attestation requests concerning external chains or real-world data. Attestation providers gather proofs, commit and reveal responses, and the protocol verifies agreement before making the result available to contracts. The original State Connector design used request, commit and reveal phases and local/default provider sets; FDC is the current documented data-connector path.

Developers deploy ordinary EVM contracts through Flare's RPC using Hardhat, Foundry, JavaScript, Python, Go or Rust tooling, then call protocol interfaces such as the FTSOv2 contracts. FLR can also be used in proof-of-stake security, governance and application collateral; FAssets extend access to non-smart-contract assets through Flare protocols.