Flare Confidential Compute
Offchain compute, verified onchain. Private where it needs to be.
Confidential data and logic stay sealed inside secure hardware. A smart contract still verifies exactly what ran before anything settles.
Offchain compute, verified onchain. Private where it needs to be.
Confidential data and logic stay sealed inside secure hardware. A smart contract still verifies exactly what ran before anything settles.
What is Flare Confidential Compute?
Flare Confidential Compute (FCC) lets a contract on Flare act on data and logic that cannot be public. Programs run inside registered Trusted Execution Environments (TEEs) and return signed results that contracts on Flare verify before acting on them.
FCC extends what Flare is built for: data and compute that expand what capital can do. Data that could never be published, such as reserve balances, credit data or proprietary models, stays unpublished. FCC computes over it and returns a signed result that contracts can price, collateralize and settle against.
Verified
Each TEE has its own identity, registered only after attestation shows it runs an approved code version. It signs every result with that identity
Secured
FCC is secured by the same data providers that secure Flare's data. TEEs only act on instructions signed by a weighted majority of them.
Private, where needed
Selected inputs, parameters, keys or logic stay hidden from the public chain, the machine host and Flare. The program itself doesn't have to be private.
Flare published the Flare 2.0 architecture in 2025 and deployed on Songbird first, ahead of Flare mainnet.TEE machines run on Google Confidential Compute. Flare's data providers verify each machine's hardware attestation, code version and keys onchain before it can serve an extension. More hardware platforms and machine providers can be added over time.
Why Flare Confidential Compute
Onchain demand has moved past cheaper, faster transactions. Institutions want to keep data and logic private and still verify that the right computation ran. On a public chain, those two goals pull against each other.
Onchain systems earn trust by being public. Every input and every step of a contract is visible, so anyone can check what happened. That openness is the whole point, until the data or the logic has to stay private.
A custodian's reserve balances or a fund's strategy logic cannot sit onchain for the world to read. The usual fix is to move the computation offchain, where the inputs and the logic are hidden. But offchain, nobody can see what actually ran. The result arrives as a number from a black box, and everyone downstream has to take it on faith.
That has been the tradeoff: stay public and give up privacy, or go offchain and give up verification.
Flare Confidential Compute at a glance
Flare Confidential Compute breaks that tradeoff by letting sensitive computation happen offchain without making the machine operator the source of trust.
Before a TEE machine can participate, hardware-backed attestation proves that it is a genuine trusted environment running an approved code version. That attestation also binds the machine to a public identity key, allowing the system to register exactly which machine and software configuration it is communicating with.
Sensitive computations then run inside that registered TEE, isolated from the machine operator. The results are cryptographically signed using keys held inside the TEE, so a contract on Flare can verify where it came from before acting on it. The inputs and logic can remain confidential without turning the computation into an unverifiable black box.
How Flare Confidential Compute work
- Instruction. A contract or user on Flare issues an instruction for a confidential workload.
- Relay. Data providers relay and sign the instruction under the network's signing policy, and can attach approved offchain data.
- Confidential execution. The workload runs inside an attested TEE. The inputs and the logic stay off the public chain.
- Signed result. The TEE returns a result signed with its registered identity.
- Onchain verification. A contract on Flare verifies the signature and the attestation, then acts on the result.
What's in the FCC stack
FCC is not a separate compute network bolted onto Flare. It extends Flare’s existing protocol stack from data into confidential compute.
Governance remains onchain. Smart contracts on Flare manage compute extensions, registered TEE machines, approved code and instructions. Authorization reuses the same Flare Systems Protocol signing policy that secures Flare’s data layer: instructions reach the TEEs only after they have received 50%+ signature weight from Flare’s data providers.
The result is one shared security model for data and compute, rather than a new trust set for each application.
Three parts make up the initial FCC stack:
- Flare Compute Extensions. The framework developers build on. An extension pairs a contract on Flare with a set of registered TEE machines and an approved code hashes, so a team can run confidential logic and have its output verified under the same relay-and-sign guarantees that secure the rest of the system. The framework is in the contracts from launch, and custom extensions switch on later in the bootstrap period.
- Protocol Managed Wallets. A protocol on Flare can hold and operate a wallet on another chain, controlled by protocol rules rather than a person or a backend. Keys are generated and held inside the TEEs, with the public identity then signed and relayed. The instruction first needs to be signed by the project owner on Flare. PMW supports XRPL at this stage.
- Flare Data Connector. Faster, individually handled signed attestations. It is the proof layer that makes wallets and extensions verifiable onchain, and a standalone upgrade to the Flare Data Connector that any Flare builder can use.
Full architecture and build guides are on the Flare Dev Hub.
What Flare Confidential Compute is for
Use Cases
The pattern fits anywhere a result has to be trusted without exposing the data behind it. A custodian can prove a stablecoin is fully backed without publishing the individual balances that add up to the number. A fund can run a strategy onchain and let others verify the output while the strategy logic stays private.
FCC is built for that category: institution-grade onchain products where dataset privacy and verifiable proofs are both required.
USDX Proof of Reserves
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.
Weather Insurance
A parametric rainfall policy can settle automatically from weather data processed inside a TEE. Settlement is driven by a verifiable result rather than a manual claims process.
Automated Curation
An asset-management strategy is written once as a registered model and runs inside attested hardware. Every reallocation carries proof that the model produced it, so an allocator can verify the strategy was followed while the scoring logic itself stays private.
