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.

FTSOBest analysis

Context & purpose

• Problem: Smart contracts can only act on data they can verify. Public market data is already covered by the Flare Time Series Oracle (FTSO) and cross‑chain / Web2 events by the Flare Data Connector (FDC). Institutional data such as reserve balances, NAVs, or compliance information is deliberately kept private, so contracts cannot directly use it.
• Solution: Flare Confidential Compute (FCC) introduces a confidential execution layer. Private inputs are processed inside a registered Trusted Execution Environment (TEE). The TEE outputs a signed result – e.g., a boolean indicating whether reserves cover supply – that any contract can verify. The raw inputs never leave the enclave.

First concrete deployment – USDX Proof of Reserves

• Asset: USDX, a 1:1 USD‑referencing stablecoin issued by Hex Trust.
• Data sources:
  1. Public reserve amount (visible on‑chain).
  2. Restricted cash reserve amount (private, supplied only to the TEE).
• Computation: Inside the TEE the two amounts are summed and compared to the total USDX supply across the ecosystem.
• Published output: A signed flag indicating whether the combined reserves meet or exceed the supply (i.e., 1:1 coverage). No individual balances are revealed.
• Integration: USDX is used as collateral in the FAssets system on Songbird. The feed there is being migrated to rely on this reserve‑based result, giving DEXs a stronger basis for pricing.
• Live view: The result can be inspected via the Songbird System Explorer at the URL provided in the source.

Verification pipeline

1. Network‑authorized execution – Data providers (the same set that powers FTSO/FDC) sign each instruction. The TEE runs the instruction only after a weighted majority of signatures is collected.
2. Code pinning – Every supported code image is represented by an on‑chain hash. Only code that has been approved on‑chain may be run; upgrades are themselves on‑chain events.
3. Machine registration – A TEE registers by presenting a hardware attestation that it is running a pinned code version. The attestation is verified through the Flare Data Connector and recorded on‑chain. The enclave generates a signing key internally that never leaves the hardware.
4. Result signing & on‑chain check – The enclave signs the aggregated result. A verifier contract (the TEE registry) checks the signature against the registered enclave identity before accepting the data.
5. Public + private inputs – The Proof‑of‑Reserves extension merges public reserve components, the private cash reserve, and the total token supply, then applies a coverage rule. Only the final conclusion is stored on‑chain.

Position within Flare’s data stack

• FTSO provides public price feeds.
• FDC attests events from other chains and Web2 services.
• FCC adds confidential data handling, using the same provider set and signing policy as the other two layers. This unified approach means developers can source public, cross‑chain, and private data from a single, network‑level protocol.

Practical impact for the ecosystem

• For users: Greater confidence when transacting with USDX or any future asset that adopts FCC, because the on‑chain proof of reserve is cryptographically verifiable.
• For builders: A reusable primitive for any scenario where raw data must stay confidential but its effect (e.g., “coverage satisfied”) must be trusted. Potential use‑cases mentioned include:
  • Lending markets that need private collateral coverage checks.
  • Tokenised funds that want to publish a verified NAV without revealing holdings.
  • Credit‑scoring or compliance checks that depend on private client data.
• For the network: Expands the utility of Flare’s oracle ecosystem without sacrificing privacy, and does so with minimal additional plumbing – the same provider set manages instructions, code approvals, and attestation verification.

Dependencies & rollout status

• Trusted Execution Environment hardware that can produce attestation receipts accepted by the Flare Data Connector.
• Provider set – the same entities that operate FTSO/FDC must sign instructions. Their composition and weighting are governed by Flare’s existing policies.
• On‑chain code‑hash registry – a mechanism to pin container images for each FCC extension.
• STP.13 – proposal accepted in July 2026, enabling FCC on Songbird. A separate deployment to the main Flare network is forthcoming.
• Developer tooling – documentation and sample contracts are available on the Flare Dev Hub.

Open questions

• Scalability – How many concurrent FCC instructions can the provider set sign and the TEEs execute without bottlenecking the network?
• Cost model – What are the gas or fee implications for submitting instructions, registering TEEs, and publishing results?
• TEE ecosystem – Which hardware vendors are supported, and how is supply‑chain trust in those devices maintained?
• Governance – How are updates to the provider set, code‑pinning policies, or attestation standards decided?
• Latency – What is the typical time from data submission to on‑chain result finalisation, especially for time‑sensitive applications like fast‑moving price feeds?
• Security boundaries – While the TEE protects raw inputs, what mitigations exist for side‑channel attacks or compromised enclaves?

This analysis presents the factual content of the source and a reasoned interpretation of its technical and ecosystem implications. No future commitments, performance guarantees, or investment advice are asserted.