Flare Confidential Compute Makes Private Institutional Data Usable Onchain, Starting with Hex Trust's USDX
Smart contracts act on what they can verify. Public data is well served on Flare. Prices come through the Flare Time Series Oracle (FTSO), and events on other chains and Web2 systems are attested through the Flare Data Connector (FDC). The data that institutions run on is different. Reserve balances, fund NAV, collateral positions, credit and compliance data stay private and off the chain for good reasons. A contract cannot verify a number it is never shown.
Flare Confidential Compute (FCC) is built for that data. It processes private inputs inside a registered Trusted Execution Environment (TEE) and returns a signed result that any contract can verify before relying on it. The source data stays private. Only the result reaches the chain. For an asset whose value rests on private data, that result can give protocols a verifiable reserve status to build into pricing and risk parameters. The result carries only the aggregate, such as whether reserves cover supply, and none of the balances behind it.
First application: Proof of Reserves for USDX
The FCC Proof of Reserves extension is built for assets whose backing is partly public and partly private. Hex Trust is using it for USDX, its 1:1 USD-referencing stablecoin.
Hex Trust provides USDX reserve assets data from two sources: a public reserves amount and a restricted cash reserves amount. The extension reads both inside the TEE, checks their combined total against USDX supply across the ecosystem, and signs a result showing whether USDX is backed 1:1 or better. Only that result is published.
USDX is a collateral in the FAssets system on Songbird, and its feed there is migrating to this reserve-based reference. The same result gives DEXs a more robust basis for pricing USDX. Feed metadata shows whether reserves meet the coverage requirement at each update. The live result is at Songbird System Explorer.
“Integrating Flare Confidential Compute enhances the trust layer for institutional adoption by enabling real-time, onchain verifiability of USDX reserves and thus manifesting its position as a trusted stablecoin in the Flare ecosystem” said Ben Usinger, Head of Stablecoins at Hex Trust.
How the result is verified
A signed result is only useful if a contract knows what produced it. FCC answers that at each step from instruction to the final onchain result.
Execution is authorized by the network
Songbird data providers relay and sign each instruction under Flare's signing policy. The TEE executes only once an instruction carries a weighted majority of provider signatures. This is the same provider set that runs the FTSO and FDC.
The code is pinned
Each supported code version is the hash of a reproducible container image, approved onchain. The workload that runs is the one that was approved. A new version has to pass the same approval before a machine running it can register. That makes every upgrade an onchain event. A machine running unapproved code cannot register, so nothing it signs will be accepted.
The machine is registered
A TEE joins an extension by presenting a hardware attestation showing it runs a supported code version. That attestation is verified through the Flare Data Connector and recorded onchain. The machine's signing key is generated inside the enclave at boot and never leaves it.
The result is checked onchain
The TEE signs the result with that registered identity. A verifier contract (TEE registry) checks the signature before the result is stored or used by other contracts.
Public and private inputs meet in one calculation
The Proof of Reserves extension combines public reserve components, private reserve records and supply. It then applies a coverage rule, which can range from a single threshold to a multi-condition policy. Only the conclusion is published. The private figure contributes to the result without appearing in it.
One stack for public and private data
FCC sits alongside the FTSO and FDC as a data protocol of the network itself. The FTSO brings public market data. FDC and FDC verify facts from other chains and Web2 systems. FCC adds confidential data and computation, and run through the same provider set and signing policy. Applications on Songbird and Flare get all of it from one network, verified and ready to use.
The applications that have been hardest to build onchain are the ones that depend on data no one can publish. Stablecoin reserves are the first case because the question is easy to state and the value is obvious: is the token backed?
The extension framework opens to builders later in the bootstrap period. From there, the same pattern extends to any application that needs a verified result from data that cannot be disclosed. A lending market can price collateral through the FTSO and check a borrower's private coverage through FCC. A tokenized fund can publish a NAV any contract can verify, computed from holdings it does not disclose. Credit scoring and compliance checks follow the same path.
Start building
FCC is now live on Songbird, Flare's canary network, following the acceptance of STP.13 in July 2026. A Flare deployment follows separately.
The architecture and developer guides are on the Flare Dev Hub. They cover how an extension is defined, developed, registered, and how its results are verified onchain.
If your application depends on data that cannot go onchain as it is, we want to hear from you.