opML 2026: Wenn der KI-Beweis zum Plug-in wird

Im Sommer 2026 klang die Frage noch sauber: Welches Verfahren setzt sich durch, um KI-Berechnungen on-chain beweisbar zu machen? zkML mit kryptografischen Beweisen, opML mit Betrugsbeweisen, TEE mit Hardware-Attestierung oder die krypto-ökonomische Variante mit Einsatz und Slashing? Ende 2026 ist diese Frage überholt. Niemand kauft opML mehr als Produkt. Man schaltet es als Modus zu, als eines von fünf Backends hinter einer gemeinsamen Schnittstelle.

Der Auslöser ist ein nüchternes Stück Ethereum-Standardisierung: ERC-8274, ein Entwurf, der zkML, opML, TEE, Oracle-Netze und AVS-Lösungen hinter eine gemeinsame verify()-Funktion stellt. Das klingt technisch, und das ist es auch. Aber es verändert, wie man opML überhaupt betrachten sollte, und es wirft eine unbequeme Frage auf: Wenn jeder Beweis am Ende gleich aussieht, heißt das noch lange nicht, dass jeder Beweis dasselbe garantiert.

Was 2026 mit opML passiert ist

ERC-8274 trägt den Titel „AI Inference Proof Verification“ und wurde am 26. März 2026 vom Pseudonym JimmyShi22 als Entwurf eingereicht (Pull Request #1771 im ERCs-Repository). Der Status ist bis heute Draft, also kein verabschiedeter Standard, sondern ein Vorschlag, über den die Ethereum-Community diskutiert. Trotzdem ist er aufschlussreich, weil er ein Problem benennt, das 2026 real geworden ist, und weil er opML eine sehr bestimmte Rolle zuweist.

Das Problem heißt im Entwurf das „N mal M“-Integrationsproblem. Es gibt fünf grundverschiedene Verfahren, eine KI-Berechnung beweisbar zu machen, und eine wachsende Zahl von Anwendungen, die so einen Beweis prüfen wollen. Ohne gemeinsamen Standard muss jede Anwendung für jedes Verfahren einen eigenen Adapter schreiben. Bei fünf Verfahren und vielen Konsumenten explodiert die Zahl der Integrationen. ERC-8274 löst das, wie ERC-20 einst das Problem der Token gelöst hat: mit einer gemeinsamen Schnittstelle, gegen die alle bauen.

Konkret definiert der Entwurf zwei Schnittstellen. IProofVerifier verlangt eine Funktion verify(inputHash, outputHash, metadata, proof), die ein schlichtes true oder false zurückgibt, dazu Angaben zu Name, Version und Beweisprofil. IVerificationMethod ergänzt eine getVerifier()-Funktion und ein VerifierUpdated-Ereignis, damit ein Vertrag den hinterlegten Prüfer austauschen kann. Für opML bedeutet das eine stille Degradierung: Es ist nicht mehr der Ansatz, um den herum man seine Anwendung baut, sondern ein Wert, den eine Funktion zurückgibt. Eines von fünf. Austauschbar.

opML in einem Satz: optimistische KI mit Betrugsbeweisen

Bevor opML zum Steckmodul wird, lohnt der Blick darauf, was es eigentlich tut. Der Begriff steht für optimistic Machine Learning. Ein Knoten rechnet ein KI-Modell off-chain, veröffentlicht das Ergebnis und eine kryptografische Zusammenfassung (einen Merkle-Commitment) on-chain und erklärt es nach einem Einspruchsfenster für endgültig, falls niemand widerspricht. Wer das Ergebnis anzweifelt, kann es mit einem Betrugsbeweis anfechten. Der Name ist kein Zufall: opML ist den Optimistic Rollups nachempfunden, die Arbitrum, Optimism und Base bekannt gemacht haben.

Das ursprüngliche opML-Paper (arXiv 2401.17555, veröffentlicht Ende Januar 2024 vom Team hinter Hyper Oracle, dem heutigen Ora) beschreibt den Kern als ein interaktives Betrugsbeweis-Protokoll, das an die Optimistic-Rollup-Systeme erinnert. Die Idee ist älter als die Rollups selbst: Sie geht auf Truebit von Jason Teutsch und Christian Reitwiessner zurück, das das Verifikationsspiel mit interaktiver Bisektion einführte. Bei einem Streit halbieren Ankläger und Verteidiger die Berechnung so lange, bis genau der eine Schritt gefunden ist, an dem sie sich uneinig sind; diesen Schritt führt die Kette in einer schlanken virtuellen Maschine selbst aus und entscheidet.

Technisch steckt hinter diesem Nachrechnen die Fraud Proof Virtual Machine. Im einphasigen Modus wird jeder Rechenschritt in einer eingeschränkten VM wiederholt, was einfach, aber langsam ist. Der mehrphasige Modus lässt die unstrittige Berechnung nativ auf der GPU laufen und zieht nur den einen umstrittenen Mikroschritt in die VM, was die Komplexität des Merkle-Baums drastisch senkt. Oras eigene Benchmarks sprachen von Modell-Inferenz im Sekundenbereich und einem vollständigen Anfechtungszyklus in Minuten, gemessen allerdings an kleinen Modellen im Testnetz, nicht unter realer Last.

Der Sicherheitsmodus lautet also: annehmen, dass das Ergebnis stimmt, und jedem erlauben, eine Lüge anzufechten. Das funktioniert nur unter einer Bedingung, die man leicht überliest: Mindestens ein ehrlicher Wächter muss die Berechnung nachrechnen und bereit sein, Einspruch einzulegen. Diese Bauweise teilt opML mit jeder optimistischen Konstruktion, und wie bei der Debatte darüber, was einen echten Layer 2 ausmacht, steckt der Teufel nicht im Marketing, sondern in der Frage, ob der Anfechtungspfad je wirklich benutzt wird.

Die fünf Backends hinter verify()

ERC-8274 nennt die fünf Verfahren beim Namen und ordnet jedem konkrete Projekte zu. Das ist nützlich, weil es die Landschaft 2026 ehrlich abbildet: Es gibt nicht den einen Gewinner, sondern fünf Familien mit je eigener Vertrauensannahme. Wer zkML sagt, meint kryptografische Gewissheit; wer TEE sagt, meint Vertrauen in einen Chiphersteller; wer opML sagt, meint ökonomische Abschreckung plus einen wachsamen Dritten. Dieselbe verify()-Funktion, fünf grundverschiedene Versprechen.

Der Entwurf stellt opML damit genau zwischen die beiden Pole, die 2026 am meisten Fortschritt gemacht haben. Auf der einen Seite zkML, das die lange unüberwindbare Mauer der großen Sprachmodelle angekratzt hat und zu einem eigenen Markt für Beweise geworden ist. Auf der anderen Seite TEE, das in der Praxis die höchsten Durchsätze liefert. opML sitzt in der Mitte, und genau das wird 2026 zum Problem.

Dieselbe Schnittstelle, nicht dieselbe Garantie

Hier liegt der wunde Punkt des ganzen Ansatzes. verify() gibt true zurück, aber was dieses true bedeutet, hängt völlig davon ab, welches Backend dahinter steckt. Ein true von zkML heißt: Es gibt einen mathematischen Beweis, dass die Berechnung korrekt war, und wer rechnen kann, kann ihn prüfen. Ein true von opML heißt etwas ganz anderes: Innerhalb des Einspruchsfensters hat niemand widersprochen. Das kann bedeuten, dass das Ergebnis ehrlich war, oder dass schlicht niemand hingeschaut hat. Ein true von einem TEE heißt: Vertrauen Sie Intel oder NVIDIA und gehen Sie davon aus, dass kein Seitenkanal die Enklave ausgehebelt hat. Ein true vom Oracle heißt: Ein Quorum hat sich geeinigt. Vier Rückgabewerte, die identisch aussehen und vier verschiedene Dinge versprechen.

Genau diesen Einwand hat die Diskussion unter dem Entwurf aufgegriffen. Der Teilnehmer Damonzwicker hält im Ethereum-Magicians-Forum fest, dass die Verifikation weiterhin systemvermittelt bleibt: Der Standard mache die Prüfung nicht unabhängig vom erzeugenden System, er standardisiere nur den Zugriff auf eine systemspezifische Prüfung. Echte Portabilität, so das Argument, hieße: selbst nachrechnen, vergleichen, Einschluss bestätigen. Eine einheitliche Schnittstelle liefert das nicht, sie verbirgt die Unterschiede nur hinter demselben Rückgabewert.

Für Entwickler ist das eine Falle mit freundlichem Gesicht. Eine gemeinsame Schnittstelle lädt dazu ein, Backends zu behandeln, als wären sie beliebig austauschbar: heute opML, morgen TEE, per getVerifier() umgestellt. Technisch stimmt das. Beim Vertrauen stimmt es nicht. Wer ein Oracle gegen opML tauscht, tauscht ein Quorum-Versprechen gegen ein Wächter-Versprechen; wer opML gegen zkML tauscht, tauscht Latenz gegen Rechenkosten. Der Rückgabewert bleibt ein schlichtes true und sagt über diesen Tausch kein Wort.

Von ERC-7007 zu ERC-8274: der Standard verlässt sein Elternhaus

Die Pointe liegt in der Reihenfolge. opML taucht nicht zum ersten Mal in einem Standard auf. Bereits ERC-7007, der Standard für verifizierbare KI-generierte Inhalte (Status: Final), nennt opML und zkML in einem Atemzug als die beiden gängigen Beweisarten, Betrugsbeweise und Gültigkeitsbeweise. Geschrieben wurde ERC-7007 von genau den Gründern, die hinter Ora stehen, darunter Cathie So, Xiaohang Yu, KD Conway und Kartin Wong. Mit anderen Worten: Ora hat selbst den Standard mitverfasst, der die eigene Methode als eine von zwei austauschbaren Optionen einordnet.

ERC-8274 geht einen Schritt weiter, und zwar aus einer anderen Feder. JimmyShi22 gehört nicht erkennbar zum Ora-Umfeld, und der Entwurf macht aus zwei austauschbaren Optionen deren fünf. Das ist die eigentliche Verschiebung: Die Standardisierung der verifizierbaren KI hat das Haus verlassen, das opML erfunden hat. Erst reiht Ora die eigene Methode selbst in eine Liste ein, dann übernimmt jemand von außen die Liste und verlängert sie. Für ein Verfahren, das einmal als die pragmatische Antwort auf teure Zero-Knowledge-Beweise angepriesen wurde, ist das ein Abstieg vom Protagonisten zur Fußnote in einer Schnittstellendefinition.

Die Plattformen haben andere Defaults gewählt

Ein Standard sagt, was möglich ist. Was die großen Plattformen tatsächlich einschalten, sagt mehr. Und hier fällt auf, dass opML 2026 fast überall die zweite Wahl ist. 0G Labs, ein auf dezentrale KI ausgelegtes Layer-1, hat im März 2026 Sealed Inference vorgestellt: KI-Inferenz in einer Hardware-Enklave (Intel TDX plus NVIDIA Confidential Computing), bei der ein in der Enklave erzeugter Schlüssel jede Antwort signiert. Der Default ist also TEE. opML und zkML stehen laut Ankündigung erst in aktiver Entwicklung, sind also Roadmap, nicht ausgeliefertes Produkt.

Noch deutlicher wird es bei Chainlink, dem größten Oracle-Netz. Dessen Stack für verifizierbare KI rund um die Chainlink Runtime Environment koordiniert KI-Rechenlast off-chain und verifiziert sie über den dezentralen Oracle-Konsens; getestet wurde das gemeinsam mit mehreren großen Finanzinstituten bei Unternehmensereignissen (Corporate Actions). In der gesamten Darstellung kommt opML nicht ein einziges Mal vor. Die Antwort des größten Oracle-Netzes auf verifizierbare KI heißt eben nicht opML.

Und dann ist da EigenAI aus dem EigenCloud-Umfeld, das bit-exakte, deterministische LLM-Inferenz auf dem Mainnet verspricht. Technisch ist das besonders bitter für opML, denn EigenAI übernimmt praktisch dessen Ablauf (Ergebnis veröffentlichen, Einspruchsfenster, bei Betrug den Einsatz slashen), repariert aber zwei Löcher, die opML offen ließ: Es macht die GPU-Ausführung reproduzierbar und gibt dem Wächter über krypto-ökonomische Anreize einen bezahlten Grund, hinzuschauen. Dieselbe Idee, ähnlich wie beim privaten KI-Gateway von Render, bloß mit den Schwachstellen ausgebessert, die opML nie geschlossen hat.

Dass selbst die opML-nahe Forschung inzwischen auf Mischformen setzt, ist das vielleicht deutlichste Signal. Oras eigenes opp/ai kombiniert opML mit zkML, um Effizienz und Privatsphäre zu verbinden. Ein akademischer Vorschlag namens zk-OPML nutzt Zero-Knowledge-Beweise, um opMLs Einspruchsfenster zu verkürzen. Und das bereits erwähnte OTR stapelt TEE, Betrugsbeweise und stichprobenartige ZK-Prüfungen übereinander. Jeder dieser Ansätze leiht sich bei den Nachbarn, was opML allein fehlt. Ein Verfahren, das seine Schwächen nur noch im Verbund mit den Konkurrenten ausgleicht, ist kein eigener Pol mehr, sondern eine Zutat.

Latenz lässt sich nicht wegabstrahieren

Die Schnittstelle verbirgt die Vertrauensannahme. Sie verbirgt aber nicht die Uhr. opMLs Einspruchsfenster ist kein Beiwerk, es ist die Sicherheit selbst: Je länger das Fenster, desto mehr Zeit haben ehrliche Wächter zum Anfechten, aber desto länger bleibt das Ergebnis vorläufig. verify() kann nur dann sofort true liefern, wenn das Ergebnis bereits endgültig ist. Bei opML ist es das erst nach Ablauf des Fensters. Eine einheitliche Funktionssignatur ändert daran kein Jota.

Das OTR-Paper (Optimistic TEE-Rollups, arXiv 2512.20176) von Aaron Chan und Kollegen bringt es auf den Punkt: Optimistische Ansätze erzwingen prohibitiv lange Einspruchsfenster und verhindern damit Echtzeit-Interaktivität. Die Autoren formulieren ein Verifizierbarkeits-Trilemma, wonach ein System hohe Integrität, niedrige Latenz und niedrige Kosten nicht gleichzeitig haben kann. opML opfert die Latenz. Der eigene hybride Ansatz der Autoren beansprucht 99 Prozent des Durchsatzes eines zentralen Systems bei rund 0,07 US-Dollar Zusatzkosten je Abfrage und einer vorläufigen Finalität im Sekundenbruchteil.

Das kollidiert frontal mit dem Teil des Marktes, auf den Ora seine Wette gesetzt hat: die Agenten-Ökonomie. Autonome KI-Agenten, die Werte transferieren, auf Prognosemärkten wetten oder Orakel-Ergebnisse auflösen, brauchen schnelle Finalität, nicht ein Fenster von Minuten oder Stunden. Wer gesehen hat, wie KI-Agenten bei den Midterms 2026 Prognosemärkte bespielten, erkennt das Muster: Diese Systeme leben von Geschwindigkeit. Ein Beweisverfahren, dessen Sicherheit buchstäblich aus dem Warten besteht, passt schlecht zu einer Welt, die auf sofortige Abwicklung getrimmt ist.

Ein Beispiel macht das greifbar. Ein Handelsagent fragt ein Modell, ob er eine Position eröffnen soll, bekommt das Ergebnis, und ein zweiter Agent will darauf aufbauen. Bei opML darf der zweite Agent streng genommen erst handeln, wenn das Einspruchsfenster des ersten Ergebnisses abgelaufen ist, sonst baut er auf einem noch anfechtbaren Resultat auf. Wer stattdessen sofort weiterhandelt, nimmt in Kauf, dass eine spätere Anfechtung die ganze Kette umstößt. Diese Verkettung vorläufiger Ergebnisse, in der jedes Glied auf das Fenster des vorigen wartet, ist in schnellen DeFi-Abläufen kaum tragbar.

Wer schaut eigentlich zu?

Die Schnittstelle kann noch etwas nicht abstrahieren: die Ökonomie des Hinschauens. opMLs Sicherheit steht und fällt mit der Annahme, dass mindestens ein ehrlicher Wächter eine Lüge anficht. Nur kostet dieses Hinschauen Geld, denn der Wächter muss die KI-Inferenz nachrechnen, und es zahlt sich nur dann aus, wenn tatsächlich ein Betrug vorliegt, den man melden kann. Solange alle ehrlich sind, rechnet der Wächter umsonst. Dieses Problem trägt in der Fachliteratur den Namen Verifier’s Dilemma: Rationale Prüfer hören irgendwann auf zu prüfen.

Die Struktur ist dieselbe wie bei einer Debatte, die Bitcoin seit Jahren begleitet. Auch dort lautet die Frage, wer am Ende dafür bezahlt, das System ehrlich zu halten, wenn die Belohnung schrumpft. Genau wie beim Sicherheitsbudget und den leeren Blöcken gilt: Ein Sicherheitsversprechen, für dessen Einlösung niemand bezahlt wird, ist ein Versprechen auf Kredit. Bei opML hängt dieser Kredit am Token. Ist der Token wertlos, fehlt die Belohnung, die den Wächter überhaupt erst an seinen Posten bringt.

Das Tückische daran: Das Ausbleiben von Anfechtungen sieht von außen aus wie perfekte Ehrlichkeit. In Wahrheit ist es mit zwei völlig verschiedenen Welten vereinbar. In der ersten rechnen alle korrekt, und es gibt nichts anzufechten. In der zweiten schaut schlicht niemand hin, und ein Betrug würde nie bemerkt. Von der Kette aus lassen sich beide nicht unterscheiden, solange man nicht nachsieht, wer überhaupt als Wächter aktiv ist und ob er einen wirtschaftlichen Grund dazu hat.

Das tote Terminal: was die Kette über Ora sagt

An dieser Stelle lohnt der Blick auf die Kette statt auf die Hochglanzbroschüre. Eine unabhängige On-Chain-Auswertung von Ownyourmind kommt zu ernüchternden Zahlen. Das Onchain AI Oracle (OAO), Oras Vorzeigeprodukt, verzeichnet über seine gesamte Lebensdauer rund 4.615 Anfragen auf Ethereum. Der Zähler blieb am 26. September 2025 stehen; die letzte beantwortete Anfrage (Nummer 4.610) datiert auf den 29. April 2025, die folgenden blieben unbeantwortet. Ein Betrugsbeweis ist in dieser Historie nie ausgelöst worden. Nicht ein einziges Mal.

Das steht in scharfem Kontrast zu den Marketingzahlen, die in Projektprofilen kursieren: von 180.000 Inferenzaufrufen und 500 und mehr Knoten ist dort die Rede. Die Auswertung konnte diese Zahlen nicht mit dem On-Chain-Verkehr in Einklang bringen. Die Dokumentationsdomain docs.ora.io löst inzwischen nicht mehr auf (NXDOMAIN). Und obwohl der ORA-Token eine Governance-Funktion tragen soll, wurde nie eine DAO, ein Vorschlagsregister oder ein Abstimmungsraum eingerichtet; die Kontrolle blieb beim Team. Insgesamt hat Ora rund 23 Millionen US-Dollar eingesammelt (3 Millionen Pre-Seed im Januar 2023, 20 Millionen strategisch im Juni 2024 von Polychain, HF0 und HashKey).

Man muss daraus nicht schließen, dass opML als Idee gescheitert ist, denn die Idee lebt in Standards und in EigenAI weiter. Aber es relativiert die Bedeutung, die ein Standard einem Backend verleiht. ERC-8274 führt opML als Beispiel-Backend und nennt namentlich das ORA Protocol. Dahinter steht ein Produkt, dessen öffentlich nachvollziehbarer Betrieb vor über einem Jahr verstummt ist. Das Verfahren ist in der Spezifikation präsent, der Referenzbetreiber in der Praxis kaum noch.

Zur Einordnung gehört, dass selbst die großen Optimistic Rollups Jahre brauchten, um ihre Betrugsbeweise scharf und erlaubnisfrei zu schalten; Arbitrum, Optimism und Base gelten 2026 als Stage 1, mit einem Sicherheitsrat als Rückfallebene, nicht als vollständig vertrauensminimiert. Wenn die größten und bestfinanzierten optimistischen Systeme den Anfechtungspfad nur vorsichtig produktiv setzen, ist die Erwartung unrealistisch, ein kleines KI-Orakel hätte dasselbe im Stillen gelöst. Die Lücke zwischen dem Versprechen eines Betrugsbeweises und seiner tatsächlichen, geübten Auslösung ist eine Konstante der ganzen optimistischen Familie.

Der blinde Fleck: geschlossene Modelle

Es gibt eine Grenze von opML, die keine Schnittstelle kaschiert, weil sie in der Methode selbst liegt. Ein Betrugsbeweis funktioniert nur, wenn ein Ankläger das Modell unabhängig nachrechnen kann. Bei offenen Gewichten (Llama, Stable Diffusion und ähnlichen) geht das. Bei geschlossenen APIs wie GPT-4o geht es nicht. Oras OAO bindet zwar auch solche geschlossenen Modelle ein, aber sie werden dann nur weitergereicht und attestiert, nicht im opML-Sinn verifiziert. Niemand außerhalb des Anbieters kann GPT-4o nachrechnen, also gibt es nichts anzufechten.

Das ist heikler, als es klingt, denn die stärksten Modelle für autonome Agenten sind heute geschlossen. opML kann also ausgerechnet die Modelle am schlechtesten absichern, die man am ehesten einsetzen möchte. Für Oras eigene Agenten-Plattform, den seit Anfang 2025 angekündigten Onchain Perpetual Agent (opAgent), ist das ein strukturelles Problem: Ein Agent, der ein geschlossenes Spitzenmodell ruft, erhält ein verify()-true, das in Wahrheit nur eine Attestierung ist. Die Schnittstelle sagt nicht, dass dieses true weniger wert ist als das true eines offenen Modells. Es sieht identisch aus.

Wohin das Geld ging

Wenn opML zu einem von fünf Steckern wird, stellt sich die unromantische Frage, wem die Standardisierung nützt. Der Markt hat darauf eine klare Antwort gegeben, und sie lautet: dem, der die Steckdose betreibt, nicht dem, der den Stecker erfunden hat. Ordnet man die fünf Backends ihren prominentesten Token zu und schaut auf die Bewertungen (Stand 10. November 2026, CoinGecko), ergibt sich ein brutales Gefälle.

Das Oracle-Backend ist mehrere Milliarden wert, das AVS-Backend immerhin Hunderte Millionen, zkML und TEE jeweils im zweistelligen Millionenbereich. opMLs Erfinder liegt bei rund 635.000 Euro, mehr als 99,9 Prozent unter seinem Allzeithoch, bei einem Tagesumsatz im niedrigen vierstelligen Bereich. Die wilden Prozentsprünge, die der ORA-Kurs zeitweise zeigt, sind bei so dünnem Handel reines Rauschen; man sollte ihnen keine Geschichte andichten. Das eigentliche Signal ist der Pegel, nicht der Ausschlag: Standardisierung nimmt dem Einzelverfahren die Preismacht.

Dahinter steckt eine strukturelle Logik. Verifikation ist ein Merkmal, keine eigenständige Firma. Sie erzeugt Vertrauen, aber kaum laufende Erträge, die einen Token tragen könnten; wer prüft, verdient nur dann, wenn er die Prüfung in ein Produkt mit echter Nachfrage einbettet, so wie Chainlink seine Oracle-Dienste oder EigenCloud sein Restaking-Geschäft. Ein Token, dessen einziger Zweck darin besteht, das eine Verfahren zu sein, hat nach der Standardisierung keinen Hebel mehr: Die Anwendung kann das Backend hinter verify() tauschen, ohne den Token je anzufassen. Das ist der nüchterne Grund, warum der Markt die Betreiber der Steckdose bezahlt und die Erfinder des Steckers leer ausgehen.

Zugleich ist das Geld, das in der verifizierbaren KI noch bewegt wird, flussaufwärts gewandert, vom Beweisen der Inferenz zum dezentralen Training. Prime Intellect sammelte Mitte 2026 rund 130 Millionen US-Dollar bei einer Milliardenbewertung ein, Nous Research kurz darauf rund 90 Millionen bei 1,5 Milliarden. Gensyns Verde-Protokoll trägt opMLs Bisektions-Idee sogar direkt flussaufwärts ins Training und schließt dabei das Determinismus-Loch, das opML offen gelassen hatte. Unter den dezentralen KI-Token ist Bittensors TAO der einzige mit robuster Bewertung. Verifikation als eigenständiger Markt hat sich dagegen nicht durchgesetzt.

Stimmen aus der Forschung

Die Vision hinter opML war nie klein. Kartin Wong, Mitgründer von Ora (vormals Hyper Oracle), begründete die 20-Millionen-Runde 2024 gegenüber CoinDesk damit, man wolle den Gestaltungsraum für KI-Dapps öffnen und dezentrale KI ins Ethereum-Ökosystem bringen. Der Anspruch lautete, KI-Berechnung so beweisbar zu machen, dass Smart Contracts ihr vertrauen können. Von diesem Anspruch ist die Idee geblieben, der kommerzielle Betrieb nicht.

Warum der rein kryptografische Weg so schwer ist, hat Vitalik Buterin früh umrissen. In seinem Essay zu Krypto und KI beziffert er den Mehraufwand für die nichtlinearen Schichten eines Modells auf rund das Zweihundertfache und merkt an, dass das Erzeugen eines ZK-Beweises Stunden dauern kann, während die Ethereum-Blockverifikation in Sekundenbruchteilen erledigt ist. Genau diese Lücke war opMLs Daseinsberechtigung: Statt alles zu beweisen, nur im Streitfall nachrechnen. Buterin warnt im selben Text aber auch, man solle KI als Regelgeber (als das Herz der Spielregeln) nur mit größter Vorsicht einsetzen.

Elena Burger von a16z crypto hat die technische Kernhürde benannt, die zkML lange zum Nischenverfahren machte. In ihrer Analyse hält sie fest, dass sich 32-Bit-Gleitkommaoperationen nicht ohne massiven Mehraufwand in das arithmetische Schaltkreisformat der Zero-Knowledge-Beweise pressen lassen. Dass zkML diese Mauer 2026 trotzdem anzukratzen begann, ist einer der Gründe, warum opMLs einstiger Kostenvorteil schrumpft, und damit Teil derselben Zange, in der das Verfahren heute steckt.

BaFin, MiCA und die Howey-Grauzone

Für deutsche Leser bleibt die regulatorische Einordnung. Hier gilt die vertraute Trennung: MiCA und die BaFin regulieren Dienstleister und Emittenten (die Kryptowerte-Dienstleister, CASPs), nicht das Protokoll selbst. Das hält die BaFin in ihrem Merkblatt zu Kryptowerte-Dienstleistungen fest. Ein opML-Netz, das Betrugsbeweise prüft, ist als solches kein beaufsichtigtes Finanzprodukt. Der ORA-Token, der die Rechenleistung bezahlt, fällt dagegen in eine Grauzone.

Deutschland hat die MiCA-Übergangsfrist früher beendet als der EU-Rahmen es verlangt: Der Bestandsschutz für Altanbieter lief zum 31. Dezember 2025 aus (geregelt in § 50 des Kryptomärkteaufsichtsgesetzes, Teil des Finanzmarktdigitalisierungsgesetzes). Seit dem 1. Januar 2026 dürfen nur noch MiCA-lizenzierte CASPs anbieten, und die BaFin gehört bei der Lizenzvergabe zu den aktivsten Behörden der Union. Für die reine Infrastruktur verifizierbarer KI ändert das wenig, für jeden, der darauf ein Geschäft mit Kundengeldern baut, sehr viel.

In den USA ordnete die gemeinsame Auslegung von SEC und CFTC vom März 2026 sechzehn Kryptowerte (darunter LINK) als digitale Rohstoffe ein, sagt aber nichts über KI-Oracle- oder Verifikations-Token wie ORA. Heikler wird es dort, wo opMLs Umfeld in die Tokenisierung von Modellumsätzen hineinreicht: Oras Standard ERC-7641 beschreibt einen Token, der laut Spezifikation faktisch Anteile verkörpert und seinen Haltern einen Anteil am Umsatzpool verspricht. Ein solches Konstrukt sieht einem Wertpapier verdächtig ähnlich und würde in Europa eher unter MiFID II als unter MiCA fallen. Verifizierbare KI passt in keine der Schubladen sauber hinein.

Was das für 2026 bedeutet

Zieht man die Fäden zusammen, hat opML einen eigentümlichen Sieg errungen. Als Idee hat es sich durchgesetzt: Es steht in zwei Ethereum-Standards, sein Ablauf (veröffentlichen, anfechten, slashen) lebt in EigenAI weiter, und seine Bisektionslogik taucht flussaufwärts im dezentralen Training wieder auf. Als Produkt und als Token hat es verloren. opML ist 2026 ein Verb geworden, keine Firma: etwas, das man einschaltet, nicht etwas, das man kauft.

Für Entwickler im deutschsprachigen Raum ist die praktische Lehre unspektakulär, aber wichtig. Wählen Sie das Backend hinter verify() nicht nach dem Ticker, sondern danach, was das true bedeuten muss. Geht es um echtes Geld und stehen ehrliche Wächter mit Anreiz bereit, kann opML genügen. Braucht die Anwendung sofortige Finalität, führt an TEE oder krypto-ökonomischen Verfahren kaum ein Weg vorbei. Verlangt der Fall mathematische Gewissheit und ist das Modell klein genug, ist zkML die Antwort. Eine gemeinsame Schnittstelle nimmt Ihnen diese Entscheidung nicht ab; sie macht es nur leichter, sie aus Versehen zu übergehen.

Die eigentliche Nachricht von ERC-8274 ist deshalb weniger eine über opML als eine über die ganze Kategorie. Verifizierbare KI reift von einem Wettbewerb der Verfahren zu einer Infrastruktur mit austauschbaren Teilen. Das ist gesund für die Anwendungen und hart für die Token, die einst darauf wetteten, das eine Verfahren zu sein. Der Wert fließt zu dem, der die Steckdose betreibt. Wer nur den Stecker erfunden hat, bleibt in der Spezifikation, als Beispiel in einer Liste.

Häufig gestellte Fragen

Was ist opML einfach erklärt?

opML (optimistic Machine Learning) ist ein Verfahren, um KI-Berechnungen auf der Blockchain beweisbar zu machen. Ein Knoten rechnet das Modell außerhalb der Kette, veröffentlicht das Ergebnis mit einer kryptografischen Zusammenfassung und erklärt es nach einem Einspruchsfenster für gültig, falls niemand es mit einem Betrugsbeweis anficht. Das Prinzip ist von den Optimistic Rollups entlehnt: erst vertrauen, im Streitfall nachrechnen.

Was ist ERC-8274?

ERC-8274 ist ein im März 2026 eingereichter Ethereum-Standardentwurf mit dem Titel AI Inference Proof Verification. Er definiert eine gemeinsame verify()-Schnittstelle, hinter der fünf verschiedene Beweisverfahren stecken können: zkML, opML, TEE, Oracle und Multisig/AVS. Der Status ist bislang Draft. Für opML bedeutet der Standard, dass es von einem eigenständigen Ansatz zu einem von fünf austauschbaren Backends wird.

Ist opML besser als zkML?

Keines ist pauschal besser; sie tauschen unterschiedliche Dinge. zkML liefert mathematische Gewissheit, ist aber bei großen Modellen rechnerisch teuer. opML ist günstiger und flexibler, erkauft das aber mit einem Einspruchsfenster (Latenz) und der Annahme, dass mindestens ein ehrlicher Wächter nachrechnet. Wo sofortige Finalität zählt, ist opML schwach; wo Kosten und offene Modelle im Vordergrund stehen, kann es passen.

Warum ist der ORA-Token so stark gefallen?

Der ORA-Token notiert mehr als 99,9 Prozent unter seinem Allzeithoch und bei einer Marktkapitalisierung von rund 635.000 Euro (Stand 10. November 2026). Der Handel ist extrem dünn, weshalb einzelne Kurssprünge wenig aussagen. Strukturell spiegelt der Verfall, dass Oras On-Chain-Betrieb weitgehend verstummt ist und dass Standardisierung dem einzelnen Verfahren die Preismacht nimmt: Der Wert fließt zu Oracle- und AVS-Netzen, nicht zu opMLs Erfinder.

Reguliert die BaFin opML?

Nein, nicht das Protokoll selbst. MiCA und die BaFin beaufsichtigen Kryptowerte-Dienstleister und Emittenten, nicht die zugrunde liegende Infrastruktur. Ein opML-Netz ist kein beaufsichtigtes Finanzprodukt. Sobald aber ein Token wie ORA gehandelt wird oder ein Dienst Kundengelder berührt, greifen die MiCA-Regeln; in Deutschland lief der Bestandsschutz für Altanbieter bereits Ende 2025 aus.

Marcus Okafor schreibt für HOGE Wire über die Schnittstelle von Krypto und künstlicher Intelligenz.