Woher ein Smart Contract seine Daten bekommt

Die Vorstellung ist bestechend. Eine Anleihe liegt als Token auf einer Blockchain, der Kupon wird am Zinstermin automatisch ausgezahlt, ohne Zahlstelle, ohne Abstimmung zwischen Verwahrstellen, ohne die Abfolge aus Bestätigungen und Abgleichen, die heute zwischen Emittent und Endinvestor liegt. Der Smart Contract, der das erledigt, ist überschaubar. Er prüft ein Datum, liest einen Zinssatz, berechnet einen Betrag, schreibt Guthaben um.

Dass dieser Fall wirtschaftlich zählt, ist gut belegt. Eine quantitative Untersuchung zum Einsparpotenzial DLT-gestützter Kapitalmarktinfrastrukturen rechnet eine achtjährige Unternehmensanleihe entlang von neun Prozessen durch und kommt zu einem deutlichen Ergebnis. Das Potenzial liegt fast vollständig im Middle und Back Office. Dort entfallen 62 Prozent auf einen einzigen Prozessblock, nämlich Kapitalmaßnahmen und Asset Servicing, 75,1 von 120,4 Basispunkten (Bauer et al., 2023). Genau dieser Block ist es, in dem Kupon- und Tilgungszahlungen ohne Zahlstelle und Clearingsystem laufen sollen. Zwei Bedingungen gehören zu dieser Rechnung dazu. Sie gilt für das Szenario mit ausländischen Investoren, in dem das Bestandssystem besonders teuer ist. Zudem setzt sie voraus, dass auch die Geldseite auf der Chain liegt, andernfalls fallen die zentralen Effekte weg. Der Primärmarkt bleibt in der Untersuchung ausgeklammert, obwohl er 40 bis 60 Prozent der Gesamtkosten ausmacht.

Genau an dieser Stelle beginnt aber auch das Problem, über das in der Diskussion um die Tokenisierung erstaunlich selten gesprochen wird. Ein Smart Contract kann rechnen, aber er kann nichts wissen. Eine Blockchain ist ein geschlossenes System. Sie kennt ihren eigenen Zustand, also welche Adresse welches Guthaben hält und welche Transaktion in welchem Block steht. Über alles, was außerhalb dieser Grenze liegt, weiß sie nichts. Der Referenzzinssatz von heute Morgen, der Kurs eines Wertpapiers, die Frage, ob ein Emittent seinen Zahlungsverpflichtungen nachgekommen ist, all das steht nicht auf der Chain. Es muss jemand hineinschreiben. Die Instanzen, die das tun, heißen Oracles.

Die Fachliteratur führt diese Schwierigkeit unter dem Begriff Oracle-Problem. Sie behandelt sie auffällig stiefmütterlich. Eine systematische Durchsicht von 142 Fachaufsätzen zu realen Blockchain-Anwendungen ergab, dass nur 15 Prozent die Rolle von Oracles überhaupt berücksichtigten und weniger als 10 Prozent auf deren Grenzen hinwiesen (Caldarelli, 2020). Derselbe Beitrag formuliert eine Einsicht, die für die Finanzwelt unmittelbar praktisch ist. Je vertrauenswürdiger ein System ohnehin ist, desto weniger schlägt das Oracle-Problem durch. Umgekehrt heißt das, wer die Technologie gerade wegen ihrer Vertrauensunabhängigkeit wählt, trifft das Problem mit voller Wucht.

Warum das kein technisches Detail ist

Die Blockchain-Architektur verdankt ihre Anziehungskraft einem Versprechen. Zwei Parteien können sich auf einen gemeinsamen Zustand einigen, ohne einer dritten Instanz vertrauen zu müssen. Jeder kann selbst nachrechnen, ob ein Block gültig ist. Die Korrektheit ist nicht behauptet, sie ist überprüfbar.

Für alles, was von außen kommt, gilt das nicht. Das Netzwerk kann prüfen, ob eine Nachricht korrekt signiert wurde und von der vereinbarten Adresse stammt. Ob ihr Inhalt stimmt, kann es nicht prüfen, weil die Antwort darauf außerhalb liegt. Das Architekturpapier eines führenden Anbieters formuliert das mit bemerkenswerter Offenheit. Die Korrektheit eines Oracle-Berichts sei eine Eigenschaft externer Daten und deshalb protokollintern nicht feststellbar (Breidenbach et al., 2021).

Damit verschiebt sich das Vertrauensproblem lediglich. Es verschwindet nicht, es wandert an den Rand des Systems, dorthin, wo die Daten eintreten. Wer die Datenzufuhr kontrolliert, kontrolliert im Ergebnis den Smart Contract, unabhängig davon, wie sauber der Smart Contract programmiert ist.

Der Angriff auf den Dateneingang

Dass dies keine theoretische Sorge ist, hat der Markt für dezentrale Finanzanwendungen mehrfach erfahren. Im Oktober 2022 trieb ein Händler auf einer dezentralen Handelsplattform den Preis eines wenig liquiden Tokens innerhalb weniger Minuten um mehr als 1.300 Prozent nach oben, indem er auf beiden Seiten des Marktes gleichzeitig handelte. Die Plattform bezog ihren Preis aus eben diesem Markt. Der aufgeblähte Kurs wurde als Sicherheit anerkannt, gegen die sich Kredite aufnehmen ließen. Rund 110 Millionen US-Dollar verließen das Protokoll. Der Smart Contract hatte fehlerfrei gearbeitet. Er hatte lediglich eine Zahl verarbeitet, die nicht der Wirklichkeit entsprach.

Bemerkenswert ist der juristische Nachlauf. Ein Bundesrichter hob die Schuldsprüche im Mai 2025 auf, unter anderem wegen fehlender örtlicher Zuständigkeit und weil die Beweislage wesentliche Falschdarstellungen nicht trage. Wer den Vorgang für einen erledigten Präzedenzfall hält, irrt also. Die Frage, wann die Ausnutzung einer Preisquelle Manipulation ist und wann aggressives Handeln im Rahmen der Regeln, ist rechtlich weiterhin unbeantwortet. Für ein Finanzsystem, das auf Rechtssicherheit angewiesen ist, ist das ein ernüchternder Befund.

Das zweite Problem: Konzentration

Die Antwort der Branche auf verwundbare Datenquellen lautet Dezentralisierung. Statt einer Quelle fragt man viele ab, statt einer Node melden mehrere, der Median entscheidet. Das ist wirksam gegen einzelne Ausreißer und heute Stand der Technik.

Es löst das Problem allerdings nur eine Ebene tiefer, denn die Frage, wer diese Netzwerke betreibt, bleibt. Nach öffentlich zugänglichen Marktdaten entfielen im Mai 2026 rund zwei Drittel bis drei Viertel des gesamten über Oracle-Dienste abgesicherten Werts auf einen einzigen Anbieter, mit deutlichem Abstand zu allen weiteren. Ein Markt, in dem ein Anbieter mehrere hundert Anwendungen versorgt und die Nummer zwei weniger als ein Viertel davon erreicht, ist in seiner Struktur weniger ein Wettbewerbsmarkt als eine Infrastruktur mit einem dominierenden Betreiber.

Das ist an sich kein Vorwurf, Infrastrukturmärkte tendieren zur Konzentration. Es steht nur in einem auffälligen Verhältnis zu dem Argument, mit dem für die Technologie geworben wird. Wer zentrale Abhängigkeiten überwinden will und dabei eine neue zentrale Abhängigkeit aufbaut, hat die Abhängigkeit verlagert, nicht beseitigt.

Die Finanzaufsicht denkt in genau diesen Kategorien bereits. Die europäische Verordnung zur digitalen operationalen Resilienz verlangt von Finanzunternehmen in Artikel 29, vor Vertragsschluss zu bewerten, ob eine Abhängigkeit von einem nicht leicht ersetzbaren Dienstleister entsteht. Alternativen sind dabei gegenzurechnen (Verordnung (EU) 2022/2554). Ob ein Oracle-Netzwerk unter diesen Begriff fällt, ist nicht geklärt und wird bislang kaum diskutiert. Die Frage drängt sich aber auf, sobald aus Pilotprojekten regulierte Abwicklung wird.

Was der traditionellen Finanzwelt konkret fehlt

Für die Finanzindustrie liegt die eigentliche Schwierigkeit noch vor dieser Diskussion. Die Daten, die ein tokenisiertes Wertpapier braucht, existieren. Referenzkurse, Kapitalmaßnahmen, Zinssätze, Ratingänderungen, all das wird seit Jahrzehnten erhoben, geprüft und geliefert. Wer diese Daten bezieht, weiß, von wem er sie bezieht. Im Fehlerfall gibt es einen benennbaren Vertragspartner, selbst wenn Datenlizenzen die Haftung für Richtigkeit regelmäßig eng begrenzen.

Nur liegt nichts davon in einer Form vor, die ein Smart Contract unmittelbar verwerten könnte. Diese Daten werden über Schnittstellen ausgeliefert, gegen Lizenz, meist ohne kryptografische Signatur der Quelle. Die heute übliche Transportverschlüsselung über TLS sichert den Weg, aber sie erzeugt keinen Nachweis darüber, wer die Angabe verantwortet. Wer die Zahl auf die Chain bringt, bürgt damit faktisch selbst für sie, obwohl er sie nur weiterreicht.

Das genannte Architekturpapier beschreibt diesen Zustand und schlägt vor, Datenanbieter ihre eigenen Angaben signieren zu lassen. Dort steht allerdings auch, in aller Deutlichkeit, dass dies eine Absicht ist und kein verfügbares Produkt. Zugleich benennt es eine Schwierigkeit, die dabei bislang ungelöst bleibt. Sobald mehrere Quellen zu einem Wert zusammengeführt werden, was gegen Manipulation gerade notwendig ist, ist die Signatur der einzelnen Quelle wertlos, denn der aggregierte Wert stammt von keiner von ihnen. Man kann Herkunftsnachweis haben oder Manipulationsresistenz durch Aggregation. Beides zugleich ist Gegenstand laufender Forschung, etwa zu Signaturverfahren, die eine Rechnung über signierte Eingaben selbst beweisbar machen.

Hinzu kommt die kaufmännische Seite, die in technischen Debatten gern untergeht. Ein Datenhaus lebt davon, dass seine Daten nicht frei verfügbar sind. Wer Kursdaten unverschlüsselt auf eine offene Chain schreibt, verschenkt sein Produkt. In genehmigungspflichtigen Netzen ist der Kreis der Mitleser kleiner, das Problem ist damit aber nur verkleinert und nicht gelöst, denn auch dort sehen alle zugelassenen Teilnehmer denselben Eintrag. Welche Art von Chain sich durchsetzt, ist ohnehin offen und hängt an einer Frage, die mit Daten nichts zu tun hat. Nach Auffassung des Digitalverbands Bitkom können offene Chains die Kriterien des Baseler Standards für die günstigere Eigenmittelklasse technisch nicht erfüllen, was eine Emission dort für Banken prohibitiv teuer machen würde, obwohl ein erheblicher Teil der in Deutschland begebenen DLT-Wertpapiere bislang gerade offene Chains nutzt (Bitkom, 2024). Das ist eine Verbandsposition in einer laufenden Kontroverse, keine entschiedene Frage. Die diskutierten Auswege, etwa signierte Aussagen über einen Wert statt des Wertes selbst, sind konzeptionell überzeugend und praktisch kaum verbreitet.

Was daraus folgt

Die Automatisierung, die sich die Finanzindustrie von Smart Contracts verspricht, ist real. Sie greift überall dort, wo der Smart Contract nur Informationen braucht, die ohnehin auf der Chain liegen, etwa bei der Abwicklung zweier tokenisierter Vermögenswerte Zug um Zug, also nach dem Prinzip Delivery versus Payment. Ein europäischer Förderinstitut-Emittent hat 2022 in diese Richtung gezeigt, mit einer digital nativen Anleihe über 100 Millionen Euro, die taggleich gegen tokenisiertes Zentralbankgeld zweier nationaler Notenbanken abgewickelt wurde (Europäische Investitionsbank, 2022). Der Fall trägt allerdings weniger weit, als er oft zitiert wird. Tokenisiertes Zentralbankgeld floss nur zwischen Emittentin und Konsortialbanken, die Anleger zahlten weiterhin in konventioneller Währung. Die Zentralbanken bezeichneten ihren Token zudem selbst als experimentell. Soweit beide Seiten eines Geschäfts tatsächlich auf derselben Chain liegen, muss nichts von außen hereingereicht werden. Genau dann greift die Automatisierung. Das ist kein kleiner Anwendungsfall, die Verkürzung von Abwicklungszeiten und der Wegfall des Risikos, dass eine Seite liefert und die andere nicht, sind handfeste Vorteile.

Diese Fälle sind allerdings die Ausnahme. Bei nahezu jedem Instrument mit variabler Verzinsung, bei jeder Kapitalmaßnahme und bei jeder Bewertung braucht der Smart Contract eine Information, die von außen kommt. Sobald das der Fall ist, hängt die Verlässlichkeit an einer Komponente, die die Eigenschaften der Blockchain gerade nicht besitzt. An dieser Stelle ist nichts überprüfbar, sondern wieder jemandem zu glauben. Es ist derselbe Vertrauensmechanismus wie zuvor, nur mit weniger Erfahrung, dünnerer Regulierung und ungeklärter Haftung.

Wer die Technologie in der regulierten Finanzwelt ernsthaft einsetzen will, kommt deshalb an drei Aufgaben nicht vorbei. Datenanbieter müssten ihre Angaben an der Quelle signieren, statt die Verantwortung an die Transportschicht abzugeben. Die Forschung müsste das Aggregationsproblem lösen, also Verfahren praxisreif machen, die Herkunftsnachweis und Zusammenführung mehrerer Quellen zugleich erlauben. Und die Aufsicht müsste klären, unter welchen Bedingungen eine Datenbrücke zur kritischen Infrastruktur wird, bevor die Abhängigkeit entstanden ist und nicht danach.

Wie weit der Weg dorthin ist, zeigt ein Blick auf das europäische Pilotregime für DLT-Marktinfrastrukturen. Ein Jahr nach Anwendungsbeginn war keine einzige Infrastruktur zugelassen, weshalb die europäische Wertpapieraufsicht auf ihren gesetzlich vorgesehenen Jahresbericht verzichtete und stattdessen an die Gesetzgebungsorgane schrieb (ESMA, 2024). Bis Anfang 2026 sind es drei zugelassene Infrastrukturen geworden. Die Aufsicht selbst hält fest, dass sich aus dieser geringen Zahl kaum belastbare Schlüsse ziehen lassen. Wo so wenig im Wirkbetrieb läuft, ist auch wenig über die Belastbarkeit der Datenzufuhr gelernt worden.

Solange diese Punkte offen sind, bleibt die Tokenisierung in der Breite das, was sie derzeit ist, ein überzeugendes Konzept mit einer unbesetzten Stelle an einer entscheidenden Position. Man kann diese Stelle ignorieren und auf Pilotprojekte verweisen, in denen sie noch nicht schmerzt. In der Fläche wird sie schmerzen. Es lohnt aus meiner Sicht, darüber intensiver zu sprechen, solange die Architekturen noch entworfen werden.

Quellen

• Bauer, M., Sturz, D., Liebscher, S., Ludwig, M., Scheungraber, B., Censkowsky, S. (2023). Cost Savings Potential of DLT-based Capital Market Infrastructures. A Quantitative Analysis. Gemeinschaftsstudie, Dezember 2023.
• Bitkom (2024). Risikogewichtung von tokenisierten Wertpapieren. Positionspapier.
• Breidenbach, L., Cachin, C., Chan, B., Coventry, A., Ellis, S., Juels, A. u. a. (2021). Next Steps in the Evolution of Decentralized Oracle Networks. Version 1.0, 15. April 2021.
• Caldarelli, G. (2020). Understanding the Blockchain Oracle Problem. A Call for Action. Information, 11(11), Artikel 509.
• Europäische Investitionsbank (2022). Project Venus. Digital native Anleihe über 100 Mio. EUR, begeben am 29. November 2022.
• ESMA (2024). Letter to the European Commission, European Parliament and Council on the DLT Pilot Regime. März 2024.
• Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor, insbesondere Artikel 29.
• United States District Court, Southern District of New York (2025). Entscheidung vom 23. Mai 2025 im Verfahren gegen den Beteiligten des Marktmanipulationsfalls von Oktober 2022, Aufhebung der Schuldsprüche.
• DefiLlama (2026). Oracle Rankings nach Total Value Secured, Stand Mai 2026.