How Flare uses data to expand what capital can do

For most of the last cycle, blockchains competed on execution: faster blocks, lower fees, and higher throughput. That race has largely run its course. Blockspace is now abundant across dozens of L1s and L2s, and adding more of it is no longer enough to differentiate a network. Chains that relied on execution performance alone are now facing that reality, with many struggling to retain activity once incentives end, as recently illustrated by Blast.

The constraint has moved. A smart contract is only as useful as the information it can act on, and most of what onchain finance needs still sits outside the chain running it: market prices, events on other networks, assets on chains built for settlement, and institutional data that can't be made public.

Part of that need is well served. Oracle networks such as Chainlink, Pyth and RedStone deliver price feeds at scale, and messaging protocols such as LayerZero, Wormhole and Axelar move tokens and instructions between chains. Both were built around two questions, what an asset is worth and how a message gets from one chain to another, and both run alongside the chains they serve, with their own operators, security models and fees.

Three needs remain much less served. Contracts can't easily verify that something happened on another network or in a Web2 system. Large assets such as XRP and BTC sit largely outside onchain finance because their native chains were designed to settle value, not to run applications. And contracts have few ways to act on private data without exposing it. All three matter more as institutions move onchain.

Flare was designed around those gaps, on the bet that data should be part of the chain rather than an add-on to it. This report looks at how that architecture works, where it is already producing results, and what would show it scaling.

Flare: built for data from day one

Flare is an EVM-compatible Layer 1, but it doesn't compete on execution. Its design starts from the problem described above: giving smart contracts reliable access to information that lives outside the chain.

It does this by enshrining data in the protocol. On most chains, data comes from middleware, meaning an oracle network or a bridge that runs alongside the chain with its own operators, security model and fees. On Flare, about 100 staked  independent validators who propose and confirm blocks of  the network also provide price feeds and verify external events. Their weight comes from the FLR staked and delegated to them, and they're rewarded for accurate data through the network's inflation. Data becomes a native service of the chain.

This creates three practical benefits for builders. First, applications can access price feeds directly from the chain without integrating or paying a separate oracle provider. Second, Flare's data services share the same underlying provider infrastructure. This makes it easier to combine prices, cross-chain proofs and confidential computation, even if each comes with its own security assumptions. Third, the same infrastructure can support new data services without having to build a provider network from scratch.

Flare has built five products on this foundation, each answering a different question a smart contract might ask.

FTSO: What is the price? The Flare Time Series Oracle delivers decentralized market and time-series data directly to applications on Flare. Independent data providers submit estimates that are aggregated into feeds, with block-latency feeds updating roughly every 1.1 seconds. FTSOv2 is designed to support up to 1,000 feeds across crypto, equities, commodities and other data types. It provides the pricing layer used across Flare applications, including for valuing assets within the FAssets system.

FDC: Did something happen elsewhere? The Flare Data Connector allows smart contracts to verify events and data originating outside Flare, such as a payment on the XRP Ledger or a transaction on another blockchain. A contract requests an attestation, independent data providers verify the event, and the result becomes usable onchain once more than 50% of provider weight reaches consensus. FDC is particularly important to Flare's cross-chain architecture: for example, FAssets uses it to verify that the corresponding transaction actually occurred on the asset's native chain

FAssets: How do you make external assets programmable? FAssets combines FTSO and FDC to bring assets from non-smart-contract chains onto Flare. FDC verifies that the underlying transaction occurred on the native chain, while FTSO provides the price data used to value collateral that backs redemptions. Once the transaction is verified, Flare smart contracts mint a 1:1 representation of the original asset that can be used across DeFi. FXRP, live since September 2025, is the first FAsset and the subject of the next section.

FCC: What if the data can't be made public? Flare Confidential Compute extends the model to private data and computation. It processes sensitive inputs inside trusted execution environments (TEEs), secure hardware designed to keep data isolated even from the machine operator, and returns a signed result that smart contracts can verify without exposing the underlying information. FCC reuses the same data-provider set and signing policy that underpin FTSO and FDC. It is now live on Songbird, Flare's canary network, with proof of reserves for Hex Trust's USDX stablecoin as its first application.

FSA: How does the user interact with all this? Flare Smart Accounts let users of the XRP Ledger access vaults and other DeFi opportunities on Flare from the wallet they already use. The user signs a transaction on their native chain that carries an instruction, FDC proves that transaction onto Flare, and a smart account mapped to the user's address executes it. Each external address controls exactly one account on Flare, so the flow stays non-custodial and doesn't require a new wallet, a gas token or a bridging step. Because the model depends on FDC being able to verify the source chain, it isn't tied to a single ecosystem and can expand. XRPL is the first live implementation.

Read in order, these products steadily expand what smart contracts can work with: public prices first, then verified external events, then assets from other chains, and finally private data. Smart Accounts close the loop by connecting that stack to the people who hold the assets. Each product builds on the layers beneath it, which is why the suite is best read as a single architecture.

To understand where that architecture creates the most value, the next two sections focus on FAssets and Confidential Compute. The first shows how large assets that were never built for DeFi can become productive capital through Flare. The second shows how Flare can serve as a trust layer for institutional products that depend on private data, where trust comes from signed results verified onchain rather than from publishing the underlying data.

FAssets: from idle XRP to working capital 

XRP is one of the largest assets in crypto, with roughly 63B tokens in circulation worth close to $96B at current prices. Yet only a small share is used in DeFi. The XRP Ledger was built to issue and settle value quickly and cheaply, but it doesn’t support general-purpose smart contracts. As a result, XRP holders seeking lending, borrowing or yield opportunities have historically had to rely on custodians or move XRP into other ecosystems.

That's the broader problem FAssets addresses: how to bring assets from non-programmable chains into DeFi without reducing them to a custodial wrapper. Wrapped versions of XRP existed before, but they relied on a single custodian and saw limited traction. FAssets takes a different route, using Flare's data protocols to make the asset programmable while keeping it backed by XRP on its native chain.

How FAssets works

Minting starts with a single payment on the XRP Ledger. The user sends XRP to the Core Vault, with their Flare address encoded in the destination tag or memo. An executor then submits the FDC proof of that payment to Flare, and the FAssets contracts mint FXRP to the user, minus minting fees. Nobody has to rely on a custodian's word that the XRP arrived, because the payment is verified by the same data providers that secure the network.

The backing is secured by agents, independent operators who post collateral worth more than the XRP they back, partly in stablecoins and partly in FLR. FTSO prices that collateral continuously, and if its value falls below the required level, the agent's position can be liquidated. Redemption works in reverse. The user burns FXRP, the agent has to send XRP back on the XRP Ledger within a set window, and FDC confirms the payment. If the agent fails to pay, the user is compensated from the agent's collateral.

The XRP backing FXRP sits in the Core Vault, an XRPL multisig account, operated by authorized signers who act on instructions derived from Flare, with excess XRP time-locked in native XRPL escrows that release one batch per day. FAssets v1.3, live since May 2026, turned minting into a single XRPL payment, the format exchanges and custodians already use for withdrawals. That change is what allowed venues and regulated custodians such as Hex Trust to integrate minting directly.

From programmable to productive

FXRP went live on Flare mainnet on September 24, 2025. Its first-week cap of 5M FXRP filled in about four hours, and supply passed 90M by the end of January and 155M by late April. As of late September, about 145M FXRP was in circulation, roughly 0.23% of circulating XRP.

Supply alone says little about whether XRP is becoming productive capital. The more useful measure is deployment: how much FXRP is actually lent, staked, traded or used as collateral. Here the figure stands out. Out of roughly 145M FXRP outstanding, 129M is deployed in DeFi, close to 90%. Almost every FXRP minted is doing something beyond sitting in a wallet.

Where it goes shows how XRP is being used. Lending markets hold about 52% of deployed FXRP, across Morpho and Kinetic on Flare, Morpho on Ethereum and Euler on Monad. Most of it serves as collateral, letting holders borrow against their XRP instead of selling it. The clearest example is Sentora's RLUSD vault on Morpho, on Ethereum, where 10.6M FXRP was posted as collateral against $7.9M of RLUSD supplied in late September.

Firelight holds another 39%. It's the first staking layer for XRP: holders deposit FXRP and receive stXRP, a liquid position that stays usable across Flare while it accrues. On October 6, Firelight launched its onchain cover product, putting staked FXRP to work protecting DeFi vaults against defined risks, including smart contract exploits, oracle failures and bad debt. DEX liquidity on SparkDEX, Enosys and BlazeSwap, along with smaller venues, makes up the remaining 8%.

Beyond the incentive period

Between July 2025 and July 2026, Flare allocated 2.2B FLR to its FAssets Incentive Program to bootstrap liquidity. The end of that program was the first real test of whether FXRP demand would hold without subsidies.

It largely did. FXRP in DeFi peaked at 142M in May and stood at 136M on July 9, just before the program ended. By October, it was at 129M, a 5% decline since the incentives stopped.

The composition shifted more than the total. On July 9, 132M FXRP sat in DeFi on Flare and 4M on other chains. By October, the split was 109M on Flare and 20M elsewhere, five times more off-Flare than three months earlier. The reason is simple: part of the holder base moved FXRP to the chains where credit markets are deepest, mainly Ethereum and Monad.

That mobility is built into the design. FXRP is issued as a LayerZero OFT and now reaches Ethereum, Base, BNB Chain, Monad, Katana, HyperEVM and HyperCore (where it became the first XRP spot pair in January 2026).

This is ultimately what FAssets were designed for: making XRP usable across DeFi, rather than confining it to a single network.

Beyond XRP

None of the FAssets machinery is specific to XRP. FDC can verify payments on other chains, FTSO can price other collateral, and the agent model applies to any asset whose native chain lacks smart contracts. Flare has announced FBTC, which would bring Bitcoin into the same system, while Protocol Managed Wallets and FAssets v2 are in development. None are live yet, but they point toward the same goal: turning FAssets from an XRP success into general infrastructure for non-programmable assets.

In the meantime, Flare is also working on keeping the full XRPFi flow on the XRP Ledger itself: signing from an XRPL wallet, borrowing RLUSD against XRP, and receiving it at an XRPL address, an exchange or a bank deposit address.

The question is whether Flare can become the execution and liquidity layer for assets that were previously hard to use in DeFi. For XRP, the answer is already visible in the data. Bitcoin will show whether the model scales.

Confidential compute: making private data usable onchain

Public blockchains are good at verifying public information. A price, a transfer or a balance can be checked by anyone, and smart contracts can act on it with confidence. Institutional finance runs on a different kind of data: reserve balances, fund NAVs, borrower financials, collateral positions and compliance records stay private for good reasons, whether commercial, legal or regulatory.

That creates a gap. A smart contract can't verify a number it's never shown, and an institution can't publish sensitive records just to satisfy a contract. Traditional oracles answer questions like "what is ETH worth?" but institutional applications increasingly need to answer a different one: “does this institution meet a condition, without revealing the data behind it?”

Today, that question is mostly answered offchain. Proof of reserves, for example, usually takes the form of a periodic attestation from an accounting firm, published as a document no contract can read. Flare Confidential Compute is designed to turn that kind of check into a signal smart contracts can verify and act on.

How FCC works

FCC relies on trusted execution environments, or TEEs: protected areas inside a processor where sensitive data can be processed without being visible to the machine’s operator. A TEE can also prove which code it’s running through a hardware attestation. In simpler words: the private data goes in, the computation happens inside the enclave, and only the result comes out.

The problem is that a TEE alone still requires users to trust the machine running it. FCC reduces that trust by connecting the TEE to Flare’s existing network infrastructure.

First, the network decides what the TEE is allowed to execute. Instructions are signed by Flare’s data providers, the same participants involved in FTSO and FDC, and the TEE only acts once enough of them have approved the request.

Second, the code itself is fixed and publicly identifiable. Each approved software version has a specific hash recorded onchain, so a machine running different or modified code cannot participate unnoticed.

Third, the machine must prove that it’s running that approved code. It does so through a hardware attestation, which is verified through FDC and registered onchain. Its signing key is generated inside the enclave and never leaves it.

Finally, when the computation is complete, the TEE signs the result. A smart contract checks that signature against the registered machine before allowing other applications to use the output.

The result is that users don’t need to trust a single machine operator. They can verify that the computation was authorized by the network, was executed on approved code inside registered hardware, and produced a result that can be checked onchain.

First application: proof of reserves for USDX

FCC launched on Songbird, Flare's canary network, after governance approval in July 2026. Its first institutional application is a proof of reserves extension, and Hex Trust's USDX is the first stablecoin to use it.

USDX is a 1:1 USD-referencing stablecoin whose backing is partly public and partly private. Hex Trust supplies two inputs: a public reserves figure and a restricted cash reserves amount. Inside the TEE, the extension combines both, compares the total with USDX supply across the ecosystem and applies a coverage rule. It then publishes a single signed result showing whether USDX is backed 1:1 or better. 

That result can then be used directly by onchain applications without exposing the underlying private data. A DEX, lending market or other DeFi protocol could, for example, incorporate the live reserve status into its pricing, collateral parameters or risk controls.

Beyond reserves

Proof of reserves came first because the question is simple: is the token backed? The same pattern extends to any application that needs a verified answer from data that can't be disclosed.

A lending market could price collateral through FTSO and check a borrower's private coverage through FCC. A tokenized fund could publish a NAV any contract can verify, computed from holdings it doesn't disclose. Private credit, eligibility and compliance checks, and insurance follow the same path, with sensitive inputs staying private and only the conclusion reaching the chain.

This matters most for real-world assets and as more of them are issued onchain, the data behind them has to remain confidential while still being verifiable, two requirements that have largely been a trade-off until now.

Verification is not truth

FCC proves that approved code ran correctly on a given set of inputs however it doesn't prove that those inputs reflect economic reality. In the USDX case, FCC guarantees the reserve check was performed correctly, while the restricted cash figure itself still comes from Hex Trust.

FCC is therefore best read as a trust stack: code pinning, hardware attestation, onchain registration and provider signatures make the computation verifiable, while two external dependencies remain: the quality of the source data and the hardware and its operator. During the current bootstrap phase, TEEs run on Google Cloud confidential computing and are operated by the Flare Foundation. Broadening that operator set over time would further reduce the trust required.

FCC considerably improves how private facts reach a smart contract but the accuracy of the underlying data remains the responsibility of the institution that provides it.

Outlook

FCC will be deployed on mainnet soon and its trajectory will depend on adoption beyond the first use case. If it stays limited to a few Flare-native applications, it remains a useful feature. If extensions for NAV, credit and compliance follow, it becomes closer to an oracle primitive for private data, playing the role for institutional information that FTSO plays for public prices. And that's the outcome that would make Flare relevant to institutional and RWA finance well beyond its current ecosystem.

Lower issuance, rising burn: FLR is now wired to usage

For most of its history, FLR's economics were driven by distribution more than by usage. Inflation funded data provider rewards, FlareDrops distributed tokens to holders for three years, and the link between network activity and the token stayed weak. FIP.16, approved in April 2026 with 98.06% of the vote, was designed to change that. We covered the proposal in detail in a previous spotlight and this section focuses on where FLR's economics stand today.

The model works through two levers: a faucet that controls how much new FLR enters circulation, and a siphon that removes FLR as the network is used.

The faucet: lower issuance

FLR's annual inflation has come down in steps, from around 10% in 2022 to about 5% by mid-2024. FIP.16 reduced it further to 3% on May 14, 2026, while lowering the annual issuance cap from 5B to 3B FLR. 

Meanwhile, the FlareDrop program, which distributed 24.2B previously allocated FLR over 36 months, ended in January 2026, removing another major source of tokens entering circulation. 

As of October 2026, around 87B FLR was in circulation, out of a total supply of roughly 106B.

Issuance is also being directed differently. The July 14 hard fork weighted P-chain stake five times more than delegation for vote power and raised validator capacity to 300M FLR. Holders responded quickly. Staking's share of all staked or delegated FLR rose from about 32% in April to roughly half today, reaching 22.6B FLR. Combined with delegation, around 47B FLR, approximately half of the circulating supply, is now committed to securing the network and supporting its data protocols.

The siphon: burn and FIRE

To balance emissions, FLR leaves circulation through two separate routes.

The first is the base-fee burn. Every transaction on Flare burns FLR, and the same July hard fork raised the base gas fee from 25 to 500 gwei. The effect was immediate: the average fee per transaction rose from around 0.05 FLR to about 0.21 FLR, and the burn accelerated with it. Cumulative burn reached about 22.7M FLR in early October, with roughly 17M of that burned in 2026 and because the burn is automatic, it scales directly with network activity.

The second mechanism is FIRE, the protocol revenue pool created under FIP.16. FIRE collects fees generated by Flare's infrastructure, with a primary mandate to reduce FLR supply and reliance on inflation. It has accumulated around $50k so far.

Today, most FIRE revenue comes from FAssets minting and FDC attestation fees, with smaller contributions from FAssets redemptions and destination-tag fees. Importantly, not every use of Flare generates revenue for FIRE: trading or lending FXRP does not, while minting, redemptions and data attestations do. Other potential sources, including MEV capture, Smart Accounts and Confidential Compute fees, are part of the design but are not yet fully live.

From usage to token economics

For now, the scale of these mechanisms remains modest relative to issuance. At the current price of $0.0067, annual FLR issuance is worth approximately $18M. FIRE revenue has stabilised at around $190k per month since September, equivalent to $2.3M annualised. Meanwhile, token burns are tracking toward the upper end of the projected 22.5-23M FLR for the year, worth roughly $154k at current prices.

The gap remains substantial, but both mechanisms scale with usage. More FAssets activity generates more fees, more data requests increase FDC revenue, and additional products can introduce new revenue streams as they launch.

Flare has therefore put the mechanics of a flywheel in place. What is missing now is scale: activity needs to grow substantially before these mechanisms can meaningfully offset issuance.

The numbers behind the architecture

If Flare's strategy holds, its clearest signals should come from the products built around data and external assets, more than from general network activity. The data is consistent with that: Flare's network activity is steady, its financial activity is concentrated in XRPFi, and its strongest numbers sit with the products the previous sections described.

Network activity: a steady base

Flare processes around 480,000 transactions a day, with data provider submissions to the FTSO and FDC protocols accounting for a significant share of this activity. That level  has held through 2025 and 2026, with a spike above 600,000 between April and July 2026. Account growth follows the same steady pattern. The number of accounts on Flare grew from about 738,000 to 839,000 over the past twelve months, an increase of 13.6%, with new accounts arriving at a consistent pace of around 8,000 a month. Around 4,000 addresses are active on a given day, and nearly 24,000 Smart Accounts have been created since February.

Because most of this traffic is the protocol producing data, transaction count says more about Flare’s data layer than about user demand. The product metrics that follow are the better guide to how the network is being used. 

Financial activity: concentrated in XRPFi

Flare's DeFi TVL grew sharply through 2025 as FXRP launched and the ecosystem around it formed. Like the rest of the market, it has declined in dollar terms in 2026 alongside lower XRP and FLR prices, reaching about $202M today, while protocol-reported Virtual TVL stands at $303M (the latter includes assets redeployed across protocols and outstanding loans). The composition matters more than the headline. Flare's five largest protocols by TVL, Clearstar, Firelight, Upshift, Morpho and Kinetic, are all XRPFi venues, which means Flare's DeFi activity is now largely built on its flagship product.

This also explains why USD TVL understates the underlying trend. As seen earlier, FXRP deployed in DeFi has remained around 129M since the incentive program ended, suggesting that usage has remained sticky even without those incentives.

Trading activity is building on top of that base. Flare's DEXs now handle about $38M in weekly volume, or roughly $5.5M a day, alongside another $4M a week in perpetuals volume. Stablecoin supply stands at around $49M, while applications on Flare generate roughly $20,000 in daily fees, or about $7M annualized. Together, these figures show an ecosystem increasingly generating activity beyond simply holding assets onchain.

Product activity: where the thesis shows up

The strongest evidence comes from the metrics tied directly to Flare's architecture. Close to 90% of FXRP is deployed in DeFi, and 95% of it stayed deployed after the incentive program ended. Since the FIP.16 fee changes took effect, FDC attestation fees have become FIRE's fastest-growing revenue source, now accounting for 45% of its total revenue. About half of circulating FLR is staked or delegated to the providers that run Flare's data protocols, with staking rising sharply after the July hard fork.

These are the figures that set Flare apart. A general-purpose chain would be judged mainly on TVL and volume. Flare's distinguishing activity sits in asset issuance, data attestations and the stake securing them, and those are the metrics moving in the right direction.

Reading the data

Taken together, the data points in a clear direction. Flare's differentiated products are being used, and the mechanisms linking that usage to FLR are in place. What hasn't happened yet is the scale that would make those mechanisms material for the token.

The milestones to watch are concrete: FXRP in DeFi moving back above its May peak of 142M, FDC fees continuing to grow as more applications request attestations, and the first non-XRP FAsset going live. Each would show the architecture scaling beyond its first use case.

Conclusion: From Data to Capital

Flare started from a simple idea: a blockchain could stand out by giving smart contracts native access to data, at a time when most networks were competing on execution. As blockspace becomes abundant, that idea looks increasingly well timed.

FAssets is the first major proof that it works. FXRP turned one of crypto's largest and least programmable assets into working capital, with close to 90% of its supply deployed in DeFi as of late September, demand that held after incentives ended, and a footprint that now extends from Flare to Ethereum, Monad and Hyperliquid. The machinery behind it, FDC verifying payments and FTSO pricing collateral, was never specific to XRP, and more assets are set to follow.

Confidential Compute extends the same architecture to information that can't be made public. Its first application, live proof of reserves for USDX, is narrow in scope, but it addresses one of the main obstacles to institutional and RWA finance onchain: proving financial facts without disclosing the records behind them. Deployment on Flare mainnet and new use cases should broaden its reach.

The products are live, and the economic model linking them to FLR is in place. The open question is now scale, and three things will show whether Flare gets there.

Scale. Can Flare's products move beyond their first use case? For FAssets, FBTC is the next test, and Bitcoin's size makes it the clearest signal of whether the model can become general infrastructure for non-programmable assets. For Confidential Compute, the test is moving from a single proof of reserves on Songbird to Flare mainnet, and on to new applications such as fund NAVs, private credit and compliance checks.

Demand. Can Flare's products attract partners beyond its own ecosystem? FAssets is already showing it can. FXRP serves as collateral on Morpho on Ethereum and Euler on Monad, trades on Hyperliquid, is minted directly by regulated custodians such as Hex Trust, and is managed in vaults by curators including Clearstar and Monarq. Confidential Compute starts from a similar position, with Hex Trust as its first institutional partner. The next step for both is wider adoption: more exchanges and custodians minting FXRP, more venues accepting it as collateral, and outside builders using FCC once its extension framework opens. 

Economics. Can activity generate enough fees, burn and protocol revenue to make the revised FLR model meaningful? With inflation at 3% and both the burn and FIRE live, every transaction, mint, redemption and attestation now feeds back into the token. 

The last year shows that Flare's architecture can turn stranded value into productive capital. The next phase will show whether Flare can turn that data advantage into a durable source of economic activity, carrying more assets, and eventually institutional data, onchain.