Flare Confidential Compute rend les données institutionnelles privées utilisables en chaîne, à commencer par le USDX de Hex Trust

Les contrats intelligents agissent sur ce qu'ils peuvent vérifier. Les données publiques sont bien servies sur Flare. Les prix proviennent de la Flare Time Series Oracle (FTSO), et les événements sur d'autres chaînes et systèmes Web2 sont attestés via le Flare Data Connector (FDC). Les données que les institutions utilisent sont différentes. Les soldes de réserves, la valeur liquidative (NAV) des fonds, les positions de collatéral, les données de crédit et de conformité restent privées et hors chaîne pour de bonnes raisons. Un contrat ne peut pas vérifier un nombre qui ne lui est jamais montré.

Flare Confidential Compute (FCC) est conçu pour ces données. Il traite les entrées privées à l'intérieur d'un Environnement d'Exécution Sécurisé (Trusted Execution Environment, TEE) enregistré et renvoie un résultat signé que tout contrat peut vérifier avant de s'y fier. Les données sources restent privées. Seul le résultat atteint la chaîne. Pour un actif dont la valeur repose sur des données privées, ce résultat peut fournir aux protocoles un statut de réserve vérifiable à intégrer dans les paramètres de prix et de risque. Le résultat ne contient que l'agrégé, tel que si les réserves couvrent l'offre, et aucun des soldes sous‑jacent.

Première application : Preuve de Réserves pour USDX

L'extension FCC Proof of Reserves est conçue pour les actifs dont le soutien est partiellement public et partiellement privé. Hex Trust l'utilise pour USDX, son stablecoin référencé 1:1 à l'USD.

Hex Trust fournit les données d'actifs de réserve USDX à partir de deux sources : un montant de réserves publiques et un montant de réserves de trésorerie restreintes. L'extension lit les deux à l'intérieur du TEE, vérifie leur total combiné par rapport à l'offre USDX dans l'écosystème, et signe un résultat indiquant si USDX est soutenu 1:1 ou mieux. Seul ce résultat est publié.

USDX est un collatéral dans le système FAssets sur Songbird, et son flux y migre vers cette référence basée sur les réserves. Le même résultat donne aux DEX une base plus robuste pour la tarification d’USDX. Les métadonnées du flux montrent si les réserves répondent au critère de couverture à chaque mise à jour. Le résultat en direct est disponible sur le Songbird System Explorer.

« Intégrer Flare Confidential Compute renforce la couche de confiance pour l'adoption institutionnelle en permettant la vérifiabilité en temps réel et on‑chain des réserves USDX, manifestant ainsi sa position de stablecoin fiable dans l’écosystème Flare », a déclaré Ben Usinger, Head of Stablecoins chez Hex Trust.

Comment le résultat est vérifié

Un résultat signé n’est utile que si un contrat sait ce qui l’a produit. FCC répond à cela à chaque étape, de l’instruction au résultat final on‑chain.

L’exécution est autorisée par le réseau

Les fournisseurs de données Songbird relaient et signent chaque instruction selon la politique de signature de Flare. Le TEE n’exécute que lorsqu’une instruction possède une majorité pondérée de signatures de fournisseurs. Il s’agit du même ensemble de fournisseurs qui gère le FTSO et le FDC.

Le code est épinglé

Chaque version de code prise en charge est le hachage d’une image de conteneur reproductible, approuvée on‑chain. La charge de travail qui s’exécute est celle qui a été approuvée. Une nouvelle version doit passer la même approbation avant qu’une machine l’exécutant puisse s’enregistrer. Cela fait de chaque mise à jour un événement on‑chain. Une machine exécutant du code non approuvé ne peut pas s’enregistrer, ainsi rien de ce qu’elle signe ne sera accepté**.**

La machine est enregistrée

Un TEE rejoint une extension en présentant une attestation matérielle montrant qu’il exécute une version de code prise en charge. Cette attestation est vérifiée via le Flare Data Connector et enregistrée on‑chain. La clé de signature de la machine est générée à l’intérieur de l’enclave au démarrage et ne quitte jamais celle‑ci.

Le résultat est vérifié on‑chain

Le TEE signe le résultat avec cette identité enregistrée. Un contrat de vérification (registre TEE) contrôle la signature avant que le résultat ne soit stocké ou utilisé par d’autres contrats.

Les entrées publiques et privées se rencontrent dans un même calcul

L’extension Proof of Reserves combine les composantes publiques de réserves, les enregistrements privés de réserves et l’offre. Elle applique ensuite une règle de couverture, pouvant aller d’un simple seuil à une politique multi‑condition. Seule la conclusion est publiée. Le chiffre privé contribue au résultat sans apparaître dans celui‑ci.

Une pile unique pour les données publiques et privées

FCC coexiste avec le FTSO et le FDC comme protocole de données du réseau lui‑même. Le FTSO apporte les données du marché public. Le FDC vérifie les faits provenant d’autres chaînes et des systèmes Web2. FCC ajoute des données confidentielles et le calcul, et fonctionne via le même ensemble de fournisseurs et la même politique de signature. Les applications sur Songbird et Flare obtiennent tout cela d’un seul réseau, vérifié et prêt à l’emploi.

Les applications les plus difficiles à construire on‑chain sont celles qui dépendent de données que personne ne peut publier. Les réserves de stablecoins sont le premier cas parce que la question est simple à formuler et la valeur évidente : le jeton est‑il adossé ?

Le cadre d’extension s’ouvre aux constructeurs plus tard dans la période de démarrage. À partir de là, le même schéma s’étend à toute application nécessitant un résultat vérifié à partir de données qui ne peuvent être divulguées. Un marché de prêts peut fixer le prix du collatéral via le FTSO et vérifier la couverture privée d’un emprunteur via FCC. Un fonds tokenisé peut publier une NAV que tout contrat peut vérifier, calculée à partir de participations non divulguées. Le scoring de crédit et les contrôles de conformité suivent le même chemin.

Commencez à construire

FCC est maintenant en ligne sur Songbird, le réseau canari de Flare, suite à l’acceptation du STP.13 en juillet 2026. Un déploiement Flare suivra séparément.

L’architecture et les guides développeur sont sur le Flare Dev Hub. Ils couvrent comment une extension est définie, développée, enregistrée, et comment ses résultats sont vérifiés on‑chain.

Si votre application dépend de données qui ne peuvent pas être mises on‑chain telles quelles, nous voulons vous entendre.

Analyse FTSOBest

Contexte et objectif

• Problème : les smart contracts ne peuvent agir que sur des données qu’ils peuvent vérifier. Les données de marché publiques sont déjà couvertes par le Flare Time Series Oracle (FTSO) et les événements cross‑chain / Web2 par le Flare Data Connector (FDC). Les données institutionnelles comme les soldes de réserves, les NAV ou les informations de conformité sont délibérément gardées privées, ce qui empêche les contrats de les utiliser directement.
• Solution : Flare Confidential Compute (FCC) introduit une couche d’exécution confidentielle. Les entrées privées sont traitées à l’intérieur d’un Trusted Execution Environment (TEE) enregistré. Le TEE produit un résultat signé – par exemple, un booléen indiquant si les réserves couvrent l’émission – que tout contrat peut vérifier. Les données brutes ne quittent jamais l’enclave.

Première mise en œuvre concrète – Preuve de réserves USDX

• Actif : USDX, une stablecoin indexée 1 : 1 sur le dollar américain émise par Hex Trust.
• Sources de données :
  1. Montant de réserve public (visible on‑chain).
  2. Montant de réserve de trésorerie restreint (privé, fourni uniquement au TEE).
• Calcul : à l’intérieur du TEE, les deux montants sont additionnés et comparés au total de l’émission d’USDX dans l’écosystème.
• Résultat publié : un drapeau signé indiquant si les réserves combinées atteignent ou dépassent l’émission (c’est‑à‑dire une couverture 1 : 1). Aucun solde individuel n’est révélé.
• Intégration : USDX est utilisé comme collatéral dans le système FAssets sur Songbird. Le flux y est en cours de migration pour s’appuyer sur ce résultat basé sur les réserves, offrant ainsi aux DEX une base de prix plus solide.
• Vue en direct : le résultat peut être consulté via le Songbird System Explorer à l’URL fournie dans la source.

Chaîne de vérification

1. Exécution autorisée par le réseau – Les fournisseurs de données (le même groupe qui alimente FTSO/FDC) signent chaque instruction. Le TEE exécute l’instruction uniquement après que la majorité pondérée des signatures a été collectée.
2. Épinglage de code – Chaque image de code prise en charge est représentée par un hachage on‑chain. Seul le code préalablement approuvé on‑chain peut être exécuté ; les mises à jour sont elles‑mêmes des événements on‑chain.
3. Enregistrement de la machine – Un TEE s’enregistre en présentant une attestation matérielle attestant qu’il exécute une version de code épinglée. L’attestation est vérifiée via le Flare Data Connector et enregistrée on‑chain. L’enclave génère une clé de signature en interne qui ne quitte jamais le matériel.
4. Signature du résultat & vérification on‑chain – L’enclave signe le résultat agrégé. Un contrat vérificateur (le registre TEE) contrôle la signature par rapport à l’identité de l’enclave enregistrée avant d’accepter les données.
5. Entrées publiques + privées – L’extension Proof‑of‑Reserves fusionne les composantes publiques de réserves, la réserve de trésorerie privée et le total de l’émission du token, puis applique une règle de couverture. Seule la conclusion finale est stockée on‑chain.

Position dans la pile de données de Flare

• FTSO fournit des flux de prix publics.
• FDC atteste des événements provenant d’autres chaînes et des services Web2.
• FCC ajoute la gestion de données confidentielles, en utilisant le même ensemble de fournisseurs et la même politique de signature que les deux couches précédentes. Cette approche unifiée permet aux développeurs de récupérer des données publiques, cross‑chain et privées via un seul protocole de niveau réseau.

Impact pratique pour l’écosystème

• Pour les utilisateurs : une confiance accrue lorsqu’ils effectuent des transactions avec USDX ou tout autre actif futur adoptant FCC, car la preuve de réserve on‑chain est vérifiable cryptographiquement.
• Pour les développeurs : une primitive réutilisable pour tout scénario où les données brutes doivent rester confidentielles mais où leur effet (par ex., « couver​ture satisfaite ») doit être fiable. Cas d’usage potentiels mentionnés :
  • Marchés de prêts nécessitant des vérifications privées de couverture de collatéral.
  • Fonds tokenisés souhaitant publier un NAV vérifié sans divulguer les avoirs.
  • Vérifications de crédit ou de conformité reposant sur des données privées de clients.
• Pour le réseau : étend l’utilité de l’écosystème d’oracles de Flare sans sacrifier la confidentialité, et le fait avec un minimum d’infrastructure supplémentaire – le même ensemble de fournisseurs gère les instructions, les approbations de code et la vérification des attestations.

Dépendances et état du déploiement

• Matériel Trusted Execution Environment capable de produire des reçus d’attestation acceptés par le Flare Data Connector.
• Ensemble de fournisseurs – les mêmes entités qui exploitent FTSO/FDC doivent signer les instructions. Leur composition et leur poids sont régis par les politiques existantes de Flare.
• Registre de hachage de code on‑chain – mécanisme d’épinglage des images de conteneur pour chaque extension FCC.
• STP.13 – proposition acceptée en juillet 2026, activant FCC sur Songbird. Un déploiement séparé sur le réseau principal Flare est prévu.
• Outils développeur – documentation et contrats d’exemple disponibles sur le Flare Dev Hub.

Questions ouvertes

• Scalabilité – Combien d’instructions FCC concurrentes le groupe de fournisseurs peut‑il signer et les TEEs exécuter sans créer de goulot d’étranglement réseau ?
• Modèle de coûts – Quelles sont les implications en gas ou frais pour la soumission d’instructions, l’enregistrement des TEEs et la publication des résultats ?
• Écosystème TEE – Quels fournisseurs de matériel sont supportés, et comment la confiance dans la chaîne d’approvisionnement de ces appareils est‑elle maintenue ?
• Gouvernance – Comment les mises à jour du groupe de fournisseurs, des politiques d’épinglage de code ou des standards d’attestation sont‑elles décidées ?
• Latence – Quel est le délai typique entre la soumission des données et la finalisation du résultat on‑chain, en particulier pour les applications sensibles au temps comme les flux de prix à haute fréquence ?
• Limites de sécurité – Bien que le TEE protège les entrées brutes, quelles mitigations existent contre les attaques par canaux auxiliaires ou les enclaves compromises ?

Cette analyse présente le contenu factuel de la source et une interprétation raisonnée de ses implications techniques et écosystémiques. Aucun engagement futur, garantie de performance ou conseil d’investissement n’est avancé.