ERC-7683 nach dem Redesign 2026: wie ein Resolver eine Cross-Chain-Order beschreibt

Ein Protokoll für Cross-Chain-Intents nimmt Orders der Art „Ich liefere 1.000 USDC in diesem Netzwerk, wenn mir jemand den Gegenwert in jenem anderen liefert“ entgegen und ist darauf angewiesen, dass Dritte, die Solver, sie mit eigenem Kapital ausführen. Das praktische Problem: Jedes Protokoll kodiert seine Orders, Fristen und Zahlungen in einem eigenen Format, und ein Solver, der mit zehn Protokollen arbeiten will, muss zehn Integrationen schreiben und pflegen.ERC-7683schlägt eine gemeinsame Leseschnittstelle vor, damit eine einzige Integration für jedes Protokoll genügt, das sie übernimmt.

Was diese gemeinsame Schnittstelle heute definiert, ist nicht das, was die 2024 geschriebenen Tutorials beschreiben. Am 13. Mai 2026 hat eineÄnderung im ERC-Repositoryden Vorschlag um sogenannte Resolver herum neu aufgebaut: Er standardisiert nicht mehr, wie eine Order eröffnet und ausgeführt (fill) wird, sondern wie sie beschrieben wird. Jedes Protokoll behält sein Format und seinen Settlement-Contract, veröffentlicht einen Resolver, der die Order in Schritte, Variablen, Zahlungen und Annahmen übersetzt, und der Solver liest diese Übersetzung mit einem eth_call-Aufruf. Der Vorschlag befindet sich weiterhin im Status Draft, und die Sicherheit der Abwicklung bleibt in der Verantwortung des jeweiligen Protokolls.

Von open und fill zum Resolver: Was ERC-7683 im Mai 2026 geändert hat

Der Vorschlag wurde am 11. April 2024 erstellt und im Oktober desselben Jahres wesentlich erweitert, so dieHistorie der Datei. Diese Fassung definierte konkrete Ordertypen (OnchainCrossChainOrder und GaslessCrossChainOrder), Funktionen zum Eröffnen der Orders im Ursprungsnetzwerk (open und openFor in IOriginSettler), eine Funktion zum Ausführen im Zielnetzwerk (fill in IDestinationSettler) und eine aufgelöste Order mit den Feldern maxSpent und minReceived, anhand derer der Solver seine Marge berechnen konnte.

Deraktuelle Text von ERC-7683ersetzt all das und begründet dies. Die Ordertypen hingen von implementierungsspezifischen Feldern ab, sodass der Solver weiterhin für jedes Protokoll eine eigene Unterstützung brauchte; die Gewinngrenzen konnten so weit gefasst sein, dass sie für eine Entscheidung nichts taugten; das Design setzte einen Escrow pro Order voraus, der nicht zu Protokollen passt, in denen der Solver zuerst liefert und später bezahlt wird; und es verursachte zusätzliche Gaskosten für Calldata und Events. Für ein Team, das den Entwurf von 2024 implementiert hat, ist die Folge eindeutig: Sein Contract und sein Solver sind mit dem aktuellen Text nicht kompatibel, und der Vorschlag verlangt weder einen gemeinsamen Escrow noch einen gemeinsamen Settlement-Contract noch eine gemeinsame Fill-Funktion.

Was resolve zurückgibt: Schritte, Variablen, Zahlungen und Annahmen

Die Schnittstelle beschränkt sich auf einen Contract, IResolver, mit einer reinen Lesefunktion: resolve(bytes payload) gibt eine ResolvedOrder mit vier Listen zurück, steps, variables, payments und assumptions. Der Payload ist die Order im protokolleigenen Format und für den Solver opak; der Resolver dekodiert sie, prüft, ob sie korrekt aufgebaut ist, und gibt eine Beschreibung zurück, die jeder Solver interpretieren kann. Da der Solver ihn off-chain per eth_call aufruft, unterliegt der Resolver nicht den Gaskosten einer On-Chain-Ausführung.

Ein Schritt ist ein Aufruf (Call) an eine Adresse mit einem 4-Byte-Selektor, Argumenten, die Konstanten oder Variablen sein können, und Attributen, die ihn an Bedingungen knüpfen: NeedsStep und NeedsVariable legen Abhängigkeiten fest, die keine Zyklen bilden dürfen; SpendsERC20 kündigt an, dass der Aufruf Token per transferFrom abziehen wird, sodass der Solver Guthaben und Allowance sicherstellen muss; SpendsGas legt das Mindestgas fest; TimingBounds begrenzt Blocknummer oder Zeitstempel, und RevertPolicy gibt an, ob ein Revert ignoriert wird oder die Order abbricht. Ein Aufruf darf nicht ohne eine Policy revertieren, die diesen Fall vorsieht.

Variablen sind die Werte, die erst während der Ausführung feststehen: wo und in welchem Netzwerk der Solver bezahlt werden will (PaymentRecipient und PaymentChain), wer einen Schritt aufruft, ein bei der Ausführung beobachteter Wert, das Ergebnis einer Abfrage oder bestimmter Events oder ein off-chain beschaffter Nachweis (Witness). Zahlungen gibt es vorerst nur in einer Art, ERC20; sie verknüpft einen Betrag mit der Ausführung eines bestimmten Schritts (onStepIdx) und enthält eine Schätzung der Zahlungsverzögerung in Sekunden. Zur Kodierung der Adressen dientERC-7930, das jeder Adresse Typ und Referenz ihres Netzwerks hinzufügt, und Werte werden untypisiert mit einer gerahmten ABI-Kodierung übergeben, die die Spezifikation selbst definiert.

Eine USDC-Order zwischen Arbitrum und Base aus Sicht eines Solvers

In einem hypothetischen Protokoll hinterlegt ein Nutzer 1.000 USDC auf Arbitrum, um innerhalb einer Stunde 999 USDC auf Base zu erhalten. Der Solver bezieht den Payload dieser Order und ruft resolve im Resolver des Protokolls auf. Die Antwort enthält einen Schritt: einen Aufruf des Fill-Contracts des Protokolls auf Base, mit dem Attribut SpendsERC20 für 999 Einheiten USDC auf Base und dem Nutzer als Empfänger sowie mit TimingBounds auf block.timestamp, das die Frist festlegt. Sie enthält zwei Variablen, PaymentRecipient und PaymentChain, über die der Solver selbst entscheidet, und eine ERC20-Zahlung von 1.000 USDC auf Arbitrum aus dem Contract, der die Einlage verwahrt, gekoppelt an die Ausführung dieses Schritts und mit geschätzter Verzögerung. Außerdem enthält sie eine benannte Annahme, etwa das Messaging-System, über das das Protokoll Arbitrum mitteilt, dass der Schritt auf Base ausgeführt wurde.

Mit dieser Antwort muss der Solver das interne Format des Protokolls nicht kennen, hat aber vor dem Einsatz von Kapital einiges zu tun. Er muss den Resolver auf einer selbst geprüften Adressliste führen, denn laut Spezifikation vertrauen Solver den Anweisungen eines Resolvers, nachdem sie ihn untersucht haben; er muss jede benannte Annahme validieren, was die Spezifikation ausdrücklich verlangt, etwa anhand einer Liste akzeptierter Messaging-Systeme; und er muss auf Base Guthaben und Allowance bereitstellen, damit der Fill-Contract die 999 USDC abziehen kann. Die Differenz von 1 USDC und die geschätzte Zahlungsverzögerung sind die Daten, anhand derer er entscheidet, ob sich die Order für ihn lohnt.

Am schwersten wiegt in diesem Fall die zeitliche Folge. Der Solver liefert zuerst auf Base und wird später auf Arbitrum bezahlt, sobald der Mechanismus des Protokolls die Ausführung bestätigt. In diesem Zeitraum ist der Solver laut den Sicherheitshinweisen des Vorschlags selbst dem Risiko ausgesetzt, und zwar von dem Moment an, in dem er Kapital, Freigaben oder Transaktionen bindet, bis die Zahlung final ist. Versagt die Messaging-Annahme oder enthält der Settlement-Contract einen Fehler, schützt die gemeinsame Darstellung den Solver nicht: Sie hat ihm die Order korrekt beschrieben, garantiert aber nicht, dass die Zahlung eintrifft.

Was der Resolver garantiert und welches Risiko der Solver trägt

Die Spezifikation weist dem Resolver eine dreifache Rolle zu: Er dekodiert, validiert und garantiert. Seine wichtigste Garantie lautet, dass eine Order nur in den Fällen abbrechen kann, die ihre Revert-Policies deklarieren, und dass die Order korrekt aufgebaut und sicher ist, abgesehen von den benannten Annahmen. Liveness und Zensurresistenz der beteiligten Netzwerke und Token dürfen ohne Deklaration vorausgesetzt werden, und der Resolver kann weitere implizite Annahmen dokumentieren, die der Solver prüfen muss. Ein Audit des Systems sollte laut Vorschlag bestätigen, dass die Sicherheitsanforderungen des Solvers erfüllt sind oder als Annahmen ausgewiesen werden und dass die Zahlungswege nicht mehr ungültig werden können, nachdem der Solver Kosten getragen hat.

Was der Standard ausklammert, steht in seinem Text: Er standardisiert und garantiert nicht die Sicherheit des Protokolls, das die Order abwickelt, und schreibt keinen gemeinsamen Escrow, keinen gemeinsamen Settlement-Contract und keine gemeinsame Fill-Funktion vor. Zwei Protokolle, die kompatible Resolver veröffentlichen, können unterschiedliche Garantien bieten, je nachdem, wie sie die Ausführung im Zielnetzwerk verifizieren, wie sie Orders autorisieren und welcheBridgeoder welches Messaging-System sie nutzen. Die Bewertung eines Intent-Protokolls richtet sich daher weiterhin auf seine Abwicklung; der Resolver ist der Teil, der das Lesen der Orders erleichtert.

ERC-7683 senkt die Kosten der Solver-Integration und verlagert das Audit auf den Resolver

Das Redesign von 2026 löst ein reales Problem mit einer richtigen Entscheidung: Statt allen Protokollen ein Escrow- und Fill-Modell vorzuschreiben, standardisiert es nur die Beschreibung der Order, also das, was ein Solver für ihre Bewertung braucht. Ein Protokoll kann seine Logik beibehalten, einschließlich der Modelle, in denen der Solver zuerst liefert, und seine Orders dennoch jedem Solver zugänglich machen, der die Schnittstelle liest. Für ein Solver-Team bestehen die Kosten der Integration eines neuen Protokolls dann darin, dessen Resolver und Annahmen zu prüfen.

Die Grenzen betreffen Reife und Reichweite. ERC-7683 hat den Status Draft und ERC-7930, von dem es abhängt, den Status Review; die Schnittstelle kann sich also erneut ändern, wie schon im Mai, und jede Implementierung muss die Textfassung festschreiben, auf deren Grundlage sie geschrieben wurde. Die Sicherheitsprüfung wird dadurch auch nicht einfacher: Sie verlagert sich vom Orderformat auf den Resolver, die von ihm deklarierten Annahmen und den Smart Contract, der die Abwicklung vornimmt.

Für Teams, die aufEthereumund seinen Layer-2-Netzwerken aufbauen, entwickeln und auditieren wir bei MetlabsSmart Contracts. Wenn Sie ein Intent-Protokoll oder einen Solver entwerfen,erzählen Sie uns davonwelche Netzwerke, welches Abwicklungsmodell und welches Messaging-System Sie nutzen, und wir prüfen gemeinsam mit Ihnen, welcher Teil sich über einen Resolver abbilden lässt und welcher ein eigenes Audit braucht.