Flare Confidential Compute votes to launch on Songbird

FCC is the first delivery of the Flare 2.0 vision set out in March 2025, which extends Flare's consensus beyond its own chain by combining Trusted Execution Environments (TEEs) with Flare's data protocols. The launch happens in stages. This first stage brings two of the vision's pillars to a live canary network: Protocol Managed Wallets (PMW), which give protocols controlled execution on external chains starting with XRPL, and a compute-extension framework for verifiable and confidential compute. An upgraded Flare Data Connector (FDC V2) supplies the fast, signed proofs that tie the two together.

This is the architecture Flare published a year ago, now reaching builders.

The origin

Flare 2.0 set out three things Flare wanted to expand without giving up decentralization: cross-chain execution, high-integrity data, and substantial compute. It names two ways to deliver them, both built on TEEs and Flare's data protocols. Protocol Managed Wallets would handle cross-chain execution. Verifiable Compute would handle the compute side.

FCC delivers both. The Songbird launch ships PMW for the cross-chain execution pillar and the compute-extension framework for the verifiable compute pillar, with FDC V2 as the upgraded data layer between them. The architecture announced in March 2025 is now coming to a live canary network.

What FCC is

FCC is a layer that sits above Flare. It gives on-chain applications access to Trusted Execution Environments: secure, hardware-isolated compute environments that hold secrets privately and can prove they are running the correct code. That lets developers build things that a public smart contract cannot support on its own, including confidential logic, heavier computation, secure key management, and actions that reach other chains.

Because private keys are generated and managed inside those TEEs, this layer lets protocols on Flare execute on external chains under Flare's consensus. FCC is not a single product. It is the system around TEEs: the smart contracts, the relaying, the verification, and the applications built on top.

What goes live on Songbird

A governance vote is required because the deployment adds new on-chain contracts and new responsibilities for Songbird's data providers. The vote is an STP, which is rejection-based: it passes unless the 75% quorum threshold is reached and at least half of the votes are against it.

If it passes, three components go live, and together they are the working system described above.

1. Smart contracts on Songbird. These govern TEE machine registration, receive user instructions, and verify results. The protocol relays instructions to the TEEs but does not publish results back on-chain. Consumers fetch the signed results from the TEE and submit them.
2. Data providers as relayers. This is the new responsibility. Each participating provider runs a relay client and an FDC V2 verifier server. They carry instructions from Songbird to the TEEs and sign what they relay. A TEE only executes once a weighted majority of providers has signed, and that consensus step is what makes a command legitimate. Providers also handle augmentation, packaging the user's instruction with any additional data it needs, on-chain or off-chain, before submitting it.
3. TEE machines. These run the extension code inside confidential VMs and return signed results. At launch on Songbird they are hosted on Google Confidential Compute and run by the Flare Foundation. That is the bootstrap starting point. The design is built to diversify across operators and hardware vendors over time, and this is not the end state.

Rewarding starts simple. Rather than introduce new token emission, the launch compensates participating data providers from a participation pool funded by the Flare Foundation and by attestation fees during the bootstrap period, with a permanent rewarding system to follow once there is operating data to design it against. And because this is Songbird, it ships the way canary deployments are meant to: on a live network, before a final audit, with interim audit reports published as they come in. Songbird is where the system gets proven; a Flare deployment follows from there.

Why it matters now

This lands during a period of consolidation across the industry and renewed interest in on-chain privacy. It also lands as XRPL establishes itself as a major venue for real-world asset issuance, drawing institutional capital with fast settlement, low fees, and native compliance features. But XRPL was built to issue and move assets, not to program them. That gap is the opening: assets can be issued on XRPL and then put to work through Flare, which supplies the logic, verification, and execution layer that XRPL does not have on its own.

What people are asking for has moved past cheaper or faster transactions. They want infrastructure that keeps sensitive logic and keys confidential and can still prove that the right thing happened. Confidentiality and verifiability together are what FCC is built to provide, by pairing TEEs with Flare's data protocols.

What the launch enables

Flare Data Connector V2. The current FDC validates external events on Flare by batching attestation requests into rounds of roughly 90 seconds, signing a Merkle root, and posting it on-chain. FDC V2 drops that round latency by handling each request on its own through FCC. A TEE signs the attestation response once it has enough signed confirmations, and the user fetches and submits it. FDC V2 launches with four attestation types covering TEE availability and PMW payment verification. At the Songbird launch it means faster, individually handled attestations, and it serves as the proof layer that makes Protocol Managed Wallets trustworthy.

Protocol Managed Wallets. PMW lets a protocol on Flare create and operate a wallet on an external chain, controlled by protocol rules rather than by a person or a backend server. Keys are generated and held inside the TEEs, and they sign only when a weighted majority of data providers relays the instruction. The wallet is therefore secured by Flare's consensus and the TEE's hardware guarantees together, and safety-conscious users can add cosigners to a PMW account, requiring the TEEs to collect signatures from both data providers and cosigners before signing. This goes further than existing interoperability schemes and moves toward chain abstraction: the user interacts only with Flare, and the protocol executes everywhere else. At this stage, PMW launches with support for XRPL.

The two work as one capability: acting on external chains from Flare, with proof that the action happened. PMW does the acting and FDC V2 supplies the proof. As Flare 2.0 put it, every usage model of PMW leans on the Flare Data Connector to prove that a given transaction occurred. That is why three of FDC V2's four launch attestation types serve PMW. FDC V2 is not a separate product that happens to ship alongside PMW. But FDC V2 is more than PMW's proof layer. It is an upgraded version of the Flare Data Connector in its own right — faster, individually handled attestations available to anyone building on Flare, not only to FCC.

What it opens up

PMW and FDC V2 are the first applications, not the whole point. They run on a framework whose mechanisms are in place from the start. At launch the TEE machines serve only these system applications, and the ability for builders to deploy their own TEE machines and register custom extensions is present in the contracts but switched on later in the bootstrap period. When it is, a builder will define an extension with an instruction-receiving contract, a set of registered TEE machines, and a list of supported code versions, and run their own confidential logic with the same relay-and-sign guarantees that secure PMW.

PMW's first job is the clearest example of why this matters. It lets a protocol on Flare hold and operate an XRPL account directly, which is the groundwork for bringing XRP into DeFi on Flare without asking users to bridge. That is one application of the framework. The same machinery  — sealed keys, approved code, signed and verified results — is what any future extension inherits. Songbird is where it gets proven end to end on the Flare mainnet.

Developers can find the full technical breakdown, architecture, and step-by-step build guides at the Flare Dev Hub.

Voting details

Notice period: 29 June - 5 July, 2026

Voting period: 6 July - 13 July, 2026

View the STP.13 proposal at: https://proposals.flare.network/STP/STP_13.html

FTSOBest analysis

What is being added?

• Three on‑chain contract groups on Songbird:
  1. TEE registration & verification contracts – manage machine identities and validate signed results.
  2. Data‑provider relayer contracts – each provider runs an FDC V2 verifier and a relay client; a weighted majority of signatures is required before a TEE will execute.
  3. Extension‑framework contracts – expose the instruction‑receiving API used by the compute layer.
• TEE machines – confidential VMs hosted initially on Google Confidential Compute, operated by the Flare Foundation.
• FDC V2 – replaces the 90‑second batch attestation model with per‑request signing, reducing latency for proofs.
• Protocol Managed Wallets (PMW) – allow a Flare protocol to own and spend from an XRPL wallet, with keys generated inside the TEEs and signing gated by the relayer consensus.
• Reward pool – funded by the Flare Foundation and attestation fees; no new token emission in the bootstrap phase.

Technical dependencies

• Trusted Execution Environments – hardware isolation is essential for key confidentiality and proof generation.
• Flare Data Connector (FDC) V2 – provides the proof‑of‑execution layer; its verifier servers must be run by data providers.
• Weighted‑majority relayer consensus – ensures that a command is only executed when enough providers have signed, tying execution to Flare’s consensus.
• Google Confidential Compute (initially) – serves as the first TEE operator; future diversification will require additional hardware partners and contract updates.

Practical implications

• For users: assets on XRPL can be utilized in Flare DeFi apps without bridging; private keys never leave the TEE, reducing attack surface.
• For developers: the Dev Hub (https://dev.flare.network/fcc/overview) contains the full architecture and step‑by‑step guides. Builders can later register their own TEE machines and custom extensions once the bootstrap period lifts the contract switches.
• For the network: the new contracts increase the number of on‑chain calls (registration, attestation verification, reward distribution). However, the design keeps gas usage similar to existing FDC calls because each request is handled individually rather than in large batches.

Risk considerations

• The system’s security hinges on the correctness of the TEE hardware and the honesty of the relayer set during the bootstrap. Any compromise of the initial Google Confidential Compute nodes could affect early proofs.
• The weighted‑majority rule requires a reliable set of data providers; insufficient participation could stall execution.
• Audits are still interim. Final security audits will occur after Songbird validation, so there remains an audit‑risk window.

Roadmap hints (not commitments)

• After successful validation on Songbird, Flare plans a main‑net rollout using the same contracts.
• Future phases will enable builders to deploy their own TEE operators and extensions, expanding beyond XRPL support.

Key take‑aways

1. FCC brings confidential, verifiable compute to Flare via TEEs.
2. PMW provides on‑chain‑controlled wallets on XRPL, bridging the asset‑issuance gap.
3. FDC V2 offers faster, per‑request attestations, improving proof latency for all applications.
4. The launch is a canary test; its success will inform the main‑net deployment and the broader Flare 2.0 vision.