Intents und Solver-Netzwerke: So funktioniert Intent-Bridging

2026-08-12

Ein Intent ist eine Order, die sagt, welches Ergebnis Sie haben wollen, und nicht, welche Transaktionen zu senden sind. Sie signieren ihn, konkurrierende Solver bieten darum, das Ergebnis zu liefern, und eine Abwicklungsschicht bezahlt denjenigen, der es getan hat. Routing, Gas und die Wartezeit zwischen Chains wandern damit vom Nutzer zu einer professionellen Gegenpartei, und es entsteht ein anderer Satz Fragen: Wer darf bieten, woran wird gemessen, was steht hinter dem Versprechen, und was passiert mit Ihrem Geld, wenn niemand bietet.

Deklarative Order: Was ein Intent wirklich ist

Eine normale Transaktion ist imperativ. Sie nennt Vertrag, Funktion, Argumente und Gas, und die Signatur autorisiert genau einen Rechenpfad auf einem gegebenen Zustand. Alles ist vor der Unterschrift entschieden, und alles, was nicht vorhergesehen wurde, ist Ihr Problem.

Ein Intent ist deklarativ. Er ist ein signierter Satz von Bedingungen, der das Ergebnis beschreibt, das Sie akzeptieren, und er erlaubt jeden Ausführungspfad, der diese Bedingungen erfüllt. Die Transaktion sagt: „mach A, dann B, zahle genau C und erhalte X”; der Intent sagt: „ich will X und zahle dafür höchstens C”. In dieser Lesart ist die Transaktion der Sonderfall eines Intents, der genau einen Zustandsübergang zulässt.

Die praktische Folge: Wer einen Intent signiert und weitergibt, erteilt einem Dritten die Erlaubnis, den Rechenpfad für ihn zu wählen. Daher kommt der Komfort, und daher kommt auch jedes Risiko in diesem Artikel.

Neu ist das der Art nach nicht. Limit-Orders, das Bezahlen von Gebühren mit einem Token, den man ohnehin hält, Aggregatoren, die den besten Weg über mehrere Handelsplätze versprechen — all das hat die Form eines Intents: Der Nutzer nennt eine Bedingung, jemand anderes wählt die Ausführung. Neu ist, dass daraus allgemeine Infrastruktur gebaut wird und dass dieselbe Order mehrere Chains umspannen kann.

Die vier Rollen in einem Intent-System

Als Lebenszyklus geschrieben hat das Muster vier Teile. Ein Nutzer äußert einen Intent gegenüber einer Anwendung; die Anwendung macht daraus eine Order für ein bestimmtes Protokoll; die Order geht in einen Order-Strom, in dem Solver sie sehen; ein Solver bewertet sie, führt die nötigen Schritte aus, und ein Abwicklungsprozess bezahlt den Solver.

Das Vokabular lohnt sich, denn es steht inzwischen in einem Standard. Eine Order ist ein Zahlungsangebot im Tausch gegen die Erfüllung einer Reihe von Anforderungen. Ein Solver, auch Filler genannt, ist der Akteur, der diese Anforderungen erfüllt. Die Zahlung schließt den Kreis: Der Solver arbeitet zuerst und wird bei der Abwicklung bezahlt.

Der Standard heißt ERC-7683, chainübergreifende Intents (Cross Chain Intents). Es ist ein ERC der Kategorie Standards Track, angelegt im April 2024, und zum Zeitpunkt dieses Textes steht er weiterhin auf Draft, also Entwurf. Er wurde außerdem deutlich umgebaut: Ein früherer Entwurf standardisierte die Kodierung von Orders, einen Order-Strom auf der Chain, die Verwahrung und die Fill-Funktion, während der aktuelle Text nur noch die Schnittstelle standardisiert, über die Solver eine Order lesen, und den Protokollen Freiheit bei Ordererzeugung, Autorisierung, Preisbildung und Abwicklung lässt. Er baut auf ERC-7930 auf, dem Format für chainübergreifende Adressen, das auf Review steht.

Der Entwurfsstatus wiegt hier schwerer als sonst, denn es ist nicht der einzige Vorschlag im Feld: ERC-7521 beschreibt allgemeine Intents für Smart-Contract-Wallets und ist ebenfalls ein Entwurf. Halten Sie nichts davon für entschieden. Das Statusfeld jedes ERC steht am Anfang seiner Seite im Ethereum-ERCs-Repository, und die laufende Diskussion hängt in dem dort angegebenen Thread bei Ethereum Magicians, also prüfen Sie den aktuellen Stand selbst.

Warum der Solver das Geld vorstreckt

Unter chainübergreifenden Intents liegt eine unbequeme Tatsache: Zwei Chains können nicht atomar abwickeln, jemand muss zuerst gehen. Im verbreiteten Entwurf werden die Mittel des Nutzers beim Anlegen der Order in einem Vertrag auf der Ursprungs-Chain gesperrt, damit der Solver Gewissheit hat, dass das Geld existiert, bevor er auf der anderen Seite eigenes Kapital einsetzt.

Danach liefert der Solver das Ergebnis aus eigenem Bestand: Er hält das Zielasset, schickt es Ihnen und wird erst später über den Abwicklungsprozess aus den gesperrten Mitteln erstattet. In einem produktiven Entwurf werden Fills zu Bündeln zusammengefasst und in einem Rhythmus erstattet, der in Stunden statt in Sekunden gemessen wird — deshalb braucht ein Solver Betriebskapital und nicht nur einen schnellen Bot.

Die Transaktionen sendet ebenfalls der Solver, also zahlt er das Gas. Das ist der Mechanismus hinter Intent-Abläufen, die als gaslos beworben werden: Die Kosten sind nicht verschwunden, sie stecken im Preis, den der Solver Ihnen nennt.

Genau in der Lücke zwischen Auslage und Bezahlung sitzt das Solver-Risiko. Der Sicherheitsteil des Standards sagt es direkt: Ein Solver ist von dem Moment an exponiert, in dem er Kapital, Freigaben oder Transaktionen einsetzt, bis seine erwartete Zahlung endgültig und verfügbar ist. Alles, was in diesem Fenster schiefgehen kann, von Reorganisationen der Chain über die Nachrichtenzustellung bis zu einem Protokoll, das seinen Zustand ändert, ist in dem Kurs bereits eingepreist, den Sie sehen.

Wie der Wettbewerb Ihren Preis bestimmt

Weil der Nutzer den Weg nicht mehr vorgibt, muss der Preis aus Wettbewerb entstehen. Die Entwürfe unterscheiden sich darin, wie: Manche fahren holländische Auktionen, bei denen die zu schlagende Marke über die Zeit wandert, manche nehmen den Preis aus einem Orakel, manche setzen die Gebühr fest und lassen die Solver nur über Geschwindigkeit konkurrieren.

Batch-Auktionen sind die ausdrücklichste Variante. Orders werden in einem kurzen Fenster gesammelt, Solver reichen vollständige Lösungen ein, jede Lösung wird ungefähr danach bewertet, wie viel Überschuss sie den Nutzern des Bündels bringt, und die Lösung mit der höchsten Bewertung gewinnt. Gewinner werden nach einer Zweitpreisregel bezahlt, die Belohnung hängt also am Abstand zum nächstbesten Gebot und nicht daran, was der Gewinner selbst behauptet hat.

Wettbewerb hilft nur mit einem Maßstab. Ein veröffentlichtes Regelwerk verlangt, dass die Preise eines Solvers nicht schlechter sind als das, was der Nutzer bei einer definierten Liste von Basis-Liquiditätsquellen bekommen hätte, und verlangt einheitliche Abrechnungspreise: Zwei Orders im selben Paar und in derselben Richtung müssen denselben Preis erhalten. Ohne so etwas heißt beste Ausführung das, was der siegreiche Solver darunter versteht.

Das ist zugleich die ehrliche Antwort darauf, warum Intents manuelles Routing schlagen können. Ein Solver kann Ihre Order gegen die gegenläufige Order eines anderen Nutzers verrechnen, mehrere Fills in eine Transaktion packen und für die Erstattung die Chain wählen, die ihn am wenigsten kostet. Die Ersparnis ist echt, sie erreicht Sie aber nur so weit, wie Wettbewerb und Bewertungsregel sie herausdrücken.

Was das Versprechen des Solvers tatsächlich absichert

Einen Intent zu signieren heißt, jemandem Spielraum zu geben. Missbrauch verhindert nicht die Signatur, sondern die Rechenschaftsschicht rund um die Solver-Menge, und die sieht in jedem System anders aus, was die meisten Erklärungen überspringen.

Die erste Kontrolle ist üblicherweise der Zugang. In einem veröffentlichten Regelwerk muss ein Solver auf einer Whitelist stehen, bevor er überhaupt eine Abwicklung einreichen darf; die Betreiber lassen ein Monitoring laufen, das jede Abwicklung auf der Chain prüft und auffällige markiert; systematische Regelverstöße können sanktioniert werden, bis hin zum Slashing.

Die zweite Kontrolle ist Prüfung mit Einspruchsfenster. Statt jeden Fill auf der Chain zu beweisen, lässt ein Abwicklungsentwurf einen Akteur ein Bündel von Ergebnissen zusammen mit einer Sicherheitsleistung vorschlagen, das angenommen wird, wenn niemand innerhalb einer festen Frist widerspricht. Der Nutzer bekommt zuerst Geschwindigkeit, der Beweis kommt danach.

Die dritte Kontrolle ist die Vertrauensgrenze selbst, und der Standard sagt ungewöhnlich deutlich, wo sie endet. ERC-7683 standardisiert, wie eine Order Solvern beschrieben wird; er standardisiert und garantiert nicht die Sicherheit des Protokolls, das sie am Ende abwickelt. Von Solvern wird erwartet, dass sie den Vertrag prüfen, der Orders für sie übersetzt, und die Annahmen validieren, die dieser nicht selbst prüfen kann. Dem Nutzer verspricht der Standard über das darunterliegende Abwicklungssystem nichts.

So funktioniert Intent-Bridging: Der Nutzer signiert ein Ergebnis, Solver bieten und strecken Kapital vor, die Abwicklung erstattet sie

Konzentration, Zensur und der Weg zurück zu Ihrem Geld

Das strukturelle Risiko des Intent-Modells ist, dass der Kreis derer, die Ihre Order sehen und ausführen können, klein wird. Ist der Zugang zum Intent-Fluss erlaubnispflichtig und die Liste nachlässig zusammengestellt, konzentriert sich der Orderfluss, und wer einen großen Teil davon kontrolliert, kann Renten abschöpfen und im Extremfall zensieren.

Offene Verbreitung löst das nicht von selbst. Ein Knoten, der einen Intent profitabel ausführen kann, hat kein Interesse daran, ihn an Konkurrenten weiterzugeben, und ein vollständig öffentlicher Intent-Pool setzt Orders derselben Extraktion aus wie ein öffentlicher Mempool. Deshalb landen viele Systeme bei erlaubnispflichtigen oder hybriden Entwürfen, und deshalb lautet die praktische Frage nicht, ob es dezentral ist, sondern wer auf der Liste steht und wer darüber entscheidet.

Der zugehörige Preis ist Undurchsichtigkeit. In der schlimmsten Fassung signieren Sie etwas, es verschwindet und taucht als Transaktion wieder auf, ohne dass erkennbar wäre, wer sie gebaut und welche Alternativen er verworfen hat. Ausführungsqualität, die man nicht prüfen kann, ist Ausführungsqualität auf Vertrauensbasis.

Dann gibt es den schlichten Fehlerfall, der häufiger ist als die exotischen: Niemand bietet. Orders tragen eine Ausführungsfrist. Verstreicht sie ohne Fill und ohne Teilausführung, läuft die Order ab, und die gesperrten Mittel gehen zurück, in der Regel an die in der Order genannte Adresse und standardmäßig auf der Ursprungs-Chain. Die Gründe sind unspektakulär: eine ungewöhnlich große Summe, ein seltenes Tokenpaar oder kurzzeitig ausgefallene Solver.

Sofort ist diese Rückzahlung allerdings nicht. Das Geld kommt über denselben gebündelten Abwicklungsprozess zurück, der auch die Solver bezahlt, deshalb dauert ein normaler Fill Sekunden und ein Ablauf womöglich Stunden. Wer eine Ordergröße festlegt oder ein Produkt auf Intents baut, sollte Ausführungsfrist und Rückzahlungsweg vor der Gebühr lesen.

Fazit

Intents verschieben die Ausführungsarbeit vom Nutzer zum Bieter: Sie signieren das gewünschte Ergebnis, Solver konkurrieren darum, es zu liefern, sie strecken Kapital und Gas vor, und eine Abwicklungsschicht bezahlt denjenigen, der geliefert hat. Der Effizienzgewinn ist echt und der Tausch ebenso, denn Sie geben einem Dritten Ermessen darüber, wie Ihre Order ausgeführt wird, und was Sie schützt, sind nicht die Signatur, sondern die Auktionsregeln, der Maßstab, an dem diese Gebote gemessen werden, Zugangsregeln und Monitoring rund um die Solver-Menge sowie die Frist, die Ihr Geld zurückgibt, wenn niemand bietet. Der Standard für chainübergreifende Orders, ERC-7683, ist weiterhin ein Entwurf und wurde bereits einmal neu entworfen, also behandeln Sie jede Beschreibung davon, auch diese, als Momentaufnahme und prüfen Sie das Statusfeld, bevor Sie darauf bauen.

Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand August 2026; maßgeblich sind die aktuellen offiziellen Informationen.