Flare brought Flare Confidential Compute (FCC) to Songbird, its canary network, on 1st October, 2026. Hex Trust’s USDX became the first stablecoin to prove its reserves through the system, with only the conclusion published onchain.
What Happened?
- Flare launched Flare Confidential Compute on Songbird after the network accepted proposal STP.13 in July 2026.
- Hex Trust’s USDX is the first stablecoin to use the new system for a Proof of Reserves check.
- The check compares USDX reserves with total supply and publishes only whether backing sits at 1:1 or better.
- Google Cloud confidential computing machines, operated by the Flare Foundation, run the first deployment on Songbird.
USDX reserves stay private while the result goes public
Hex Trust supplies USDX reserve data from two sources: a public reserves amount and a restricted cash reserves amount. The FCC extension reads both inside a registered Trusted Execution Environment (TEE), a sealed hardware enclave. It then checks the combined total against USDX supply across the ecosystem. The signed result shows whether the stablecoin is backed 1:1 or better. Neither balance appears onchain.
That result already has work to do. USDX is a collateral asset in the FAssets system on Songbird, and its feed is migrating to this reserve-based reference. Decentralized exchanges get a basis for pricing USDX from the same output. Feed metadata also shows, at each update, whether reserves meet the required coverage threshold.
Private institutional data, usable onchain without being published.
— Flare ☀️ (@FlareNetworks) October 1, 2026
First case: Stablecoin Reserves.@Hex_Trust's USDX Proof of Reserves oracle using Flare Confidential Compute.
Private financial data in an attested TEE, signed result on Songbird. @FlareNetworks mainnet to… pic.twitter.com/nBj9ebPUh4
Ben Usinger, Head of Stablecoins at Hex Trust said:
The design targets a gap that periodic attestation reports leave open. A report is a document, and a smart contract can’t read it. Reserve quality already drives stablecoin risk ratings from agencies like S&P. A check that collateral contracts can read directly moves that question to where lending decisions actually happen.
A code hash decides which machines can sign
Flare built FCC so a contract can verify the answer and the conditions that produced it. The process runs in four steps:
- Songbird data providers relay and sign each instruction under Flare’s signing policy. The TEE acts only after a weighted majority of provider signatures arrive.
- Each approved FCC code version is the hash of a reproducible container image approved onchain, so a machine running unapproved code can’t register.
- A TEE joins by presenting a hardware attestation, which the Flare Data Connector (FDC) verifies and records onchain. Its signing key is generated inside the enclave at boot and never leaves.
- A verifier contract called the TEE registry checks each signed output before other contracts can store or use it.
The provider set that signs FCC instructions is the same one that runs the Flare Time Series Oracle (FTSO) and the FDC. Code upgrades become onchain events, because every new version must pass the same approval process.
The boundary matters here. The signature proves that approved code ran on attested hardware against the inputs Hex Trust supplied. It doesn’t independently confirm the restricted cash figure at its source, since Hex Trust still provides that input. Three questions stay open: what numeric threshold USDX must clear, how often the feed updates, and when outside operators can run TEE machines.
The Bottom Line
USDX holders and FAssets participants on Songbird can watch the coverage flag in the feed metadata rather than wait for a periodic report. Flare also listed uses beyond reserves: lending markets could pair public asset prices with private coverage data.
Tokenized funds could calculate verifiable net asset values from undisclosed holdings. Credit or compliance apps could reach a checkable conclusion without exposing the records behind it.
FCC stays on Songbird for now, and a deployment on Flare’s main network will follow separately. The extension framework opens to outside builders later in the bootstrap period. Documentation on architecture, extension development, registration and onchain verification is already posted on the Flare Dev Hub.
