Flare Confidential Compute macht private institutionelle Daten onchain nutzbar, beginnend mit Hex Trust's USDX

Smart Contracts reagieren auf das, was sie verifizieren können. Öffentliche Daten werden auf Flare gut bedient. Preise kommen über das Flare Time Series Oracle (FTSO) und Ereignisse auf anderen Chains und Web2‑Systemen werden über den Flare Data Connector (FDC) attestiert. Die Daten, auf denen Institutionen arbeiten, sind anders. Reserve‑Bilanzen, Fonds‑NAV, Sicherheiten‑Positionen, Kredit‑ und Compliance‑Daten bleiben aus guten Gründen privat und off‑chain. Ein Vertrag kann eine Zahl nicht verifizieren, die ihm nie gezeigt wird.

Flare Confidential Compute (FCC) ist für diese Daten konzipiert. Es verarbeitet private Eingaben innerhalb einer registrierten Trusted Execution Environment (TEE) und gibt ein signiertes Ergebnis zurück, das jeder Vertrag verifizieren kann, bevor er sich darauf verlässt. Die Quelldaten bleiben privat. Nur das Ergebnis gelangt onchain. Für ein Asset, dessen Wert auf privaten Daten beruht, kann dieses Ergebnis Protokollen einen verifizierbaren Reserve‑Status liefern, der in Preis‑ und Risikoparameter eingebaut werden kann. Das Ergebnis enthält nur die Aggregation, z. B. ob Reserven die Versorgung decken, und keine der zugrunde liegenden Salden.

Erste Anwendung: Proof of Reserves für USDX

Die FCC Proof of Reserves‑Erweiterung ist für Assets konzipiert, deren Deckung teilweise öffentlich und teilweise privat ist. Hex Trust nutzt sie für USDX, seinen 1:1 an den USD referenzierenden Stablecoin.

Hex Trust liefert USDX‑Reserve‑Asset‑Daten aus zwei Quellen: einen öffentlichen Reserven‑Betrag und einen eingeschränkten Bargeld‑Reserven‑Betrag. Die Erweiterung liest beide innerhalb der TEE, prüft deren kombinierte Summe gegenüber dem USDX‑Supply im gesamten Ökosystem und signiert ein Ergebnis, das zeigt, ob USDX 1:1 oder besser gedeckt ist. Nur dieses Ergebnis wird veröffentlicht.

USDX ist ein Collateral im FAssets‑System auf Songbird, und sein Feed dort migriert zu dieser reservenbasierten Referenz. Das gleiche Ergebnis bietet DEXs eine robustere Basis für die Preisfindung von USDX. Feed‑Metadaten zeigen, ob die Reserven bei jedem Update die Abdeckungsanforderung erfüllen. Das aktuelle Ergebnis ist unter Songbird System Explorer.

„Die Integration von Flare Confidential Compute verbessert die Vertrauensebene für die institutionelle Adoption, indem sie eine Echtzeit‑Onchain‑Verifizierbarkeit der USDX‑Reserven ermöglicht und damit ihre Position als vertrauenswürdiger Stablecoin im Flare‑Ökosystem manifestiert“, sagte Ben Usinger, Head of Stablecoins bei Hex Trust.

Wie das Ergebnis verifiziert wird

Ein signiertes Ergebnis ist nur nützlich, wenn ein Vertrag weiß, was es erzeugt hat. FCC beantwortet das in jedem Schritt von der Anweisung bis zum finalen onchain‑Ergebnis.

Ausführung wird vom Netzwerk autorisiert

Songbird‑Datenanbieter leiten jede Anweisung weiter und signieren sie gemäß Flare‑Signatur‑Policy. Die TEE führt nur aus, wenn eine Anweisung eine gewichtete Mehrheit von Anbieter‑Signaturen trägt. Dies ist derselbe Anbieterkreis, der FTSO und FDC betreibt.

Der Code ist fest verankert

Jede unterstützte Code‑Version ist der Hash eines reproduzierbaren Container‑Images, das onchain genehmigt wurde. Die auszuführende Arbeitslast ist die, die genehmigt wurde. Eine neue Version muss dieselbe Genehmigung durchlaufen, bevor eine Maschine, die sie ausführt, sich registrieren kann. Das macht jedes Upgrade zu einem onchain‑Ereignis. Eine Maschine, die nicht genehmigten Code ausführt, kann sich nicht registrieren, sodass nichts, was sie signiert, akzeptiert wird**.**

Die Maschine ist registriert

Eine TEE tritt einer Erweiterung bei, indem sie eine Hardware‑Attestierung vorlegt, die zeigt, dass sie eine unterstützte Code‑Version ausführt. Diese Attestierung wird über den Flare Data Connector verifiziert und onchain aufgezeichnet. Der Signaturschlüssel der Maschine wird beim Booten innerhalb der Enklave erzeugt und verlässt sie nie.

Das Ergebnis wird onchain geprüft

Die TEE signiert das Ergebnis mit dieser registrierten Identität. Ein Verifizierungs‑Contract (TEE‑Register) prüft die Signatur, bevor das Ergebnis gespeichert oder von anderen Contracts verwendet wird.

Öffentliche und private Eingaben treffen in einer Berechnung zusammen

Die Proof of Reserves‑Erweiterung kombiniert öffentliche Reserve‑Komponenten, private Reserve‑Datensätze und das Supply. Anschließend wird eine Abdeckungsregel angewendet, die von einem einzelnen Schwellenwert bis zu einer mehrstufigen Richtlinie reichen kann. Nur das Fazit wird veröffentlicht. Die private Kennzahl trägt zum Ergebnis bei, ohne darin zu erscheinen.

Ein Stack für öffentliche und private Daten

FCC befindet sich neben dem FTSO und FDC als Daten‑Protokoll des Netzwerks selbst. Der FTSO liefert öffentliche Marktdaten. FDC verifiziert Fakten von anderen Chains und Web2‑Systemen. FCC fügt vertrauliche Daten und Berechnungen hinzu und läuft über denselben Anbieterkreis und dieselbe Signatur‑Policy. Anwendungen auf Songbird und Flare erhalten alles von einem Netzwerk, verifiziert und sofort nutzbar.

Die Anwendungen, die am schwersten onchain zu bauen waren, sind jene, die von Daten abhängen, die niemand veröffentlichen kann. Stablecoin‑Reserven sind der erste Fall, weil die Frage einfach zu stellen und der Wert offensichtlich ist: Ist das Token gedeckt?

Das Erweiterungs‑Framework wird später in der Bootstrap‑Phase für Entwickler geöffnet. Von dort aus erstreckt sich das gleiche Muster auf jede Anwendung, die ein verifiziertes Ergebnis aus nicht offenbaren Daten benötigt. Ein Kredit‑Markt kann Sicherheiten über den FTSO bepreisen und die private Deckung eines Kreditnehmers über FCC prüfen. Ein tokenisierter Fonds kann ein NAV veröffentlichen, das jeder Contract verifizieren kann, berechnet aus Beständen, die nicht offengelegt werden. Kredit‑Scoring und Compliance‑Prüfungen folgen dem gleichen Weg.

Starten Sie mit dem Aufbau

FCC ist jetzt live auf Songbird, Flare's Canary‑Netzwerk, nach der Annahme von STP.13 im Juli 2026. Eine Flare‑Bereitstellung folgt separat.

Die Architektur und Entwickler‑Leitfäden finden Sie im Flare Dev Hub. Sie erklären, wie eine Erweiterung definiert, entwickelt, registriert wird und wie deren Ergebnisse onchain verifiziert werden.

Wenn Ihre Anwendung von Daten abhängt, die nicht unverändert onchain gehen können, möchten wir von Ihnen hören.

FTSOBest Analyse

Kontext & Zweck

• Problem: Smart Contracts können nur auf Daten reagieren, die sie verifizieren können. Öffentliche Marktdaten werden bereits vom Flare Time Series Oracle (FTSO) und Cross‑Chain / Web2‑Ereignissen vom Flare Data Connector (FDC) abgedeckt. Institutionelle Daten wie Reserve‑Bilanzen, NAVs oder Compliance‑Informationen werden bewusst privat gehalten, sodass Verträge sie nicht direkt nutzen können.
• Lösung: Flare Confidential Compute (FCC) führt eine vertrauliche Ausführungsschicht ein. Private Eingaben werden innerhalb einer registrierten Trusted Execution Environment (TEE) verarbeitet. Die TEE gibt ein signiertes Ergebnis aus – z. b. ein Boolescher Wert, der anzeigt, ob Reserven die Versorgung decken – das jeder Vertrag verifizieren kann. Die Rohdaten verlassen den Enclave nie.

Erste konkrete Implementierung – USDX Proof of Reserves

• Asset: USDX, ein 1:1 USD‑referenzierter Stablecoin, ausgegeben von Hex Trust.
• Datenquellen:
  1. Öffentlicher Reservenbetrag (sichtbar on‑chain).
  2. Beschränkter Bargeldreservebetrag (privat, nur an die TEE geliefert).
• Berechnung: Innerhalb der TEE werden die beiden Beträge addiert und mit dem gesamten USDX‑Supply im Ökosystem verglichen.
• Veröffentlichte Ausgabe: Ein signiertes Flag, das angibt, ob die kombinierten Reserven den Supply erreichen oder überschreiten (d. h. 1:1‑Deckung). Einzelne Salden werden nicht offengelegt.
• Integration: USDX wird als Sicherheit im FAssets‑System auf Songbird verwendet. Der Feed dort wird migriert, um dieses reservenbasierte Ergebnis zu nutzen, was DEXs eine robustere Preisgrundlage bietet.
• Live‑Ansicht: Das Ergebnis kann über den Songbird System Explorer unter der im Quelltext angegebenen URL eingesehen werden.

Verifizierungspipeline

1. Netzwerk‑autorisierten Ausführung – Datenanbieter (dieselbe Gruppe, die FTSO/FDC betreibt) signieren jede Anweisung. Die TEE führt die Anweisung erst aus, nachdem eine gewichtete Mehrheit von Signaturen gesammelt wurde.
2. Code‑Pinning – Jeder unterstützte Code‑Image wird durch einen on‑chain Hash repräsentiert. Nur Code, der on‑chain genehmigt wurde, darf ausgeführt werden; Upgrades sind ebenfalls on‑chain Events.
3. Maschinenregistrierung – Eine TEE registriert sich, indem sie eine Hardware‑Attestation vorlegt, dass sie eine gepinnte Code‑Version ausführt. Die Attestation wird über den Flare Data Connector verifiziert und on‑chain gespeichert. Der Enclave erzeugt intern einen Signierschlüssel, der die Hardware nie verlässt.
4. Ergebnis‑Signierung & on‑chain Prüfung – Der Enclave signiert das aggregierte Ergebnis. Ein Verifizierungs‑Contract (das TEE‑Register) prüft die Signatur gegen die registrierte Enclave‑Identität, bevor die Daten akzeptiert werden.
5. Öffentliche + private Eingaben – Die Proof‑of‑Reserves‑Erweiterung kombiniert öffentliche Reservebestandteile, die private Bargeldreserve und das gesamte Token‑Supply und wendet dann eine Deckungsregel an. Nur das endgültige Ergebnis wird on‑chain gespeichert.

Position im Daten‑Stack von Flare

• FTSO stellt öffentliche Preis‑Feeds bereit.
• FDC attestiert Ereignisse von anderen Chains und Web2‑Diensten.
• FCC fügt vertrauliche Datenverarbeitung hinzu, nutzt das gleiche Provider‑Set und die Signatur‑Policy wie die anderen beiden Schichten. Dieser einheitliche Ansatz ermöglicht es Entwicklern, öffentliche, cross‑chain und private Daten aus einem einzigen, netzwerk‑basierten Protokoll zu beziehen.

Praktische Auswirkungen für das Ökosystem

• Für Nutzer: Größeres Vertrauen beim Handel mit USDX oder jedem zukünftigen Asset, das FCC nutzt, da der on‑chain Nachweis der Reserve kryptografisch verifizierbar ist.
• Für Entwickler: Eine wiederverwendbare Primitive für jedes Szenario, bei dem Rohdaten vertraulich bleiben müssen, deren Effekt (z. b. „Deckung erfüllt“) jedoch vertrauenswürdig sein muss. Mögliche Anwendungsfälle umfassen:
  • Kredit‑Markt‑Plattformen, die private Collateral‑Deckungsprüfungen benötigen.
  • Tokenisierte Fonds, die einen verifizierten NAV veröffentlichen wollen, ohne Bestände preiszugeben.
  • Kredit‑Scoring‑ oder Compliance‑Prüfungen, die auf privaten Kundendaten basieren.
• Für das Netzwerk: Erweitert den Nutzen des Oracle‑Ökosystems von Flare, ohne die Privatsphäre zu opfern, und geschieht mit minimalem zusätzlichem Aufwand – das gleiche Provider‑Set verwaltet Anweisungen, Code‑Genehmigungen und Attestations‑Verifikation.

Abhängigkeiten & Rollout‑Status

• Trusted Execution Environment‑Hardware, die Attestations‑Quittungen erzeugen kann, die vom Flare Data Connector akzeptiert werden.
• Provider‑Set – dieselben Entitäten, die FTSO/FDC betreiben, müssen Anweisungen signieren. Ihre Zusammensetzung und Gewichtung werden von Flare’s bestehenden Richtlinien geregelt.
• On‑chain Code‑Hash‑Register – ein Mechanismus, um Container‑Images für jede FCC‑Erweiterung zu pinnen.
• STP.13 – Vorschlag, der im Juli 2026 angenommen wurde und FCC auf Songbird ermöglicht. Eine separate Bereitstellung im Haupt‑Flare‑Netzwerk steht bevor.
• Entwickler‑Tools – Dokumentation und Beispiel‑Contracts sind im Flare Dev Hub verfügbar.

Offene Fragen

• Skalierbarkeit – Wie viele gleichzeitige FCC‑Anweisungen kann das Provider‑Set signieren und die TEEs ausführen, ohne das Netzwerk zu verengen?
• Kostenmodell – Welche Gas‑ oder Gebühren‑Auswirkungen hat das Einreichen von Anweisungen, das Registrieren von TEEs und das Veröffentlichen von Ergebnissen?
• TEE‑Ökosystem – Welche Hardware‑Anbieter werden unterstützt und wie wird das Vertrauen in die Lieferkette dieser Geräte aufrechterhalten?
• Governance – Wie werden Aktualisierungen des Provider‑Sets, der Code‑Pinning‑Richtlinien oder der Attestations‑Standards entschieden?
• Latenz – Wie lange dauert typischerweise vom Daten‑Einreichung bis zur on‑chain Ergebnis‑Finalisierung, insbesondere für zeitkritische Anwendungen wie schnell bewegende Preis‑Feeds?
• Sicherheitsgrenzen – Während die TEE Rohdaten schützt, welche Gegenmaßnahmen gibt es gegen Side‑Channel‑Angriffe oder kompromittierte Enclaves?

Diese Analyse präsentiert den faktischen Inhalt der Quelle und eine begründete Interpretation ihrer technischen und ökosystem‑bezogenen Implikationen. Es werden keine zukünftigen Verpflichtungen, Leistungs‑Garantien oder Anlage‑empfehlungen angegeben.