Die Vertrauensfalle offener Protokolle: Warum x402 eine zentralisierte Verantwortungsebene benötigt?

Das x402-Zahlungsprotokoll hat 31 neue Schwachstellen aufgedeckt, 99 % der Transaktionen sind einem Risiko des Vermögensdiebstahls ausgesetzt.

Verfasst von: @Jun__Yoo

Übersetzung: AididiaoJP, Foresight News

Akiba von CryptoSlate (@akibablade) veröffentlichte kürzlich einen Artikel mit dem Titel „31 neu entdeckte Schwachstellen setzen 99 % der x402-Kryptozahlungen einem Risiko von Vermögensdiebstahl und kostenlosem Einkaufen aus“.

Dieser Artikel basiert auf einer Arbeit mit dem Titel „Wenn HTTP 402 auf Blockchain trifft: Risiken des aufkommenden x402-Zahlungsprotokolls“. Diese Arbeit wurde angenommen und wird auf der USENIX Security 2026-Konferenz veröffentlicht.

Die Arbeit untersucht, wie x402 die Validierung von Zahlungsnachweisen und die On-Chain-Abwicklung an Dritte, sogenannte Facilitatoren, delegiert. Dieses Design konzentriert das Vertrauen und die Validierungslogik auf eine Zahlungsinfrastruktur, die von mehreren unabhängigen Händlern gemeinsam genutzt wird. Wenn ein Facilitator eine Schwachstelle aufweist, kann dies viele Dienste beeinträchtigen.

Die Forscher definierten auch acht Sicherheitsregeln, die Facilitatoren einhalten müssen. Verstöße gegen diese Regeln können vier Arten von Angriffen auslösen: kostenloses Einkaufen, Vermögensdiebstahl, Dienstverweigerung und Gasmissbrauch. Sie bewerteten 15 wichtige Facilitatoren und fanden 49 Regelverstöße und 31 zuvor unbekannte Schwachstellen. Die Ergebnisse wurden den betroffenen Betreibern vertraulich mitgeteilt. Einige Probleme wurden behoben, während an der Behebung anderer Probleme gearbeitet wird.

Diese Forschung konnte durchgeführt werden, weil x402 von Anfang an als offenes Protokoll entwickelt wurde. Die Protokollspezifikationen und das Referenz-SDK sind öffentlich, sodass die Forscher die Sicherheitsregeln des Zahlungsprozesses ableiten konnten. Sie verwendeten ein Open-Source-SDK und selbst eingerichtete Testhändler, um die Forschung abzuschließen.

Open Source kann Schwachstellen nicht beseitigen, bietet jedoch einen Weg, damit von außen entdeckte Mängel in gemeinsame Sicherheitsstandards umgewandelt werden können. Das x402-Protokoll wurde am 2. April an die Linux Foundation übergeben, und die x402 Foundation wurde am 14. Juli offiziell gegründet und hat 40 Mitglieder. Dies bietet ein offizielles Forum, um die Ergebnisse der Entdeckung auf der Ebene der Spezifikationen und Referenzimplementierungen zu diskutieren, anstatt sich auf Patches eines einzelnen Anbieters zu beschränken.

Die Forscher veröffentlichten auch eine öffentliche Version von x402scope, in der sensible Exploit-Codes entfernt wurden. Sie diskutieren mit Coinbase und anderen wichtigen Akteuren im Ökosystem, wie die Regelüberprüfung in den Entwicklungs- und Bereitstellungsprozess integriert werden kann.

Die Diskussion über die Reife des Protokolls endet hier. Ich möchte eine grundlegendere Frage aufwerfen, die sich aus diesen Entdeckungen ergibt.

Anstatt x402 selbst zu zentralisieren, benötigt ein offenes Protokoll eine zentralisierte Verantwortungsebene, um die Validierungsstandards durchzusetzen und die Kosten und Verluste von Sicherheitsvorfällen zu tragen?

Zentralisierung bedeutet nicht automatisch Sicherheit. Aber im Zahlungsbereich sollte diejenige Partei, die Macht ausübt, auch die Kosten des Scheiterns tragen.

Betrachten wir, wie x402 tatsächlich funktioniert. Jeder kann einen Server betreiben oder Facilitator werden. Aber das System ist nicht völlig vertrauenslos. Die Arbeit definiert den Facilitator auch als „vertrauenswürdigen Vermittler“. Sobald die Validierung und Abwicklung delegiert werden, müssen die Benutzer ein gewisses Maß an Vertrauen in den Facilitator investieren.

Das Problem ist, dass das Vertrauen konzentriert ist, das Protokoll jedoch keine entsprechenden Kapital-, Verantwortungs- oder Zahlungssicherheitsmechanismen verlangt. Diese Lücke zeigt sich in drei Aspekten des Designs.

Erstens, die Validierung (verify) ähnelt eher der Vorhersage „die Abwicklung ist zu diesem Zeitpunkt noch möglich“, als einer Kreditkartenautorisierung. Sie überprüft die Signatur, den Kontostand, die Nonce und das Ablaufdatum, sperrt jedoch weder Gelder noch verbraucht die Nonce.

Zweitens ist die Trennung von verify → Geschäftslogik → settle (Abwicklung) ursprünglich dazu gedacht, Verbraucher und Händler zu schützen. Das Protokoll hat keinen Mechanismus, um die Validierung und Abwicklung durch einen gemeinsamen Status zu verknüpfen. Wenn ein Händler auf der Grundlage der Validierungsergebnisse des Facilitators handelt und die nachfolgende Abwicklung fehlschlägt, trägt der Händler den gesamten Verlust.

Drittens werden viele Facilitatoren die Kosten der On-Chain-Abwicklung sponsern. Angreifer können den Ausführungsweg manipulieren und den Facilitator zwingen, die dadurch entstehenden Gasgebühren zu zahlen. Auf Solana könnte ein Angreifer sogar den Facilitator dazu bringen, Miete für ein vom Angreifer kontrolliertes Konto zu zahlen.

Kreditkartenzahlungen trennen ebenfalls Autorisierung und Abhebung. Der Unterschied besteht darin, dass die ausstellende Bank bei der Autorisierung einen Teil des Kreditlimits oder der Gelder des Karteninhabers reserviert. Die Netzwerkregeln bieten dem Händler dann ein gewisses Maß an Zahlungssicherheit. Wenn Probleme auftreten, stehen Autorisierungsrückzüge, Rückbuchungen, Händlerstrafe und Streitbeilegungsverfahren zur Verfügung.

x402 hat keine ausstellende Bank, die Gelder sperrt und Zahlungen garantiert. Der Server überprüft daher die Zahlungsfähigkeit durch verify, führt die Geschäftslogik aus und ruft dann settle auf. Das Problem ist, dass die beiden Enden keinen gemeinsamen Status haben. Nach der Validierung können sich Kontostand, Nonce oder Ablaufdatum ändern. Wenn der Server vor der Abwicklung irreversible Operationen durchführt, kann der Händler Verluste erleiden. Wenn der Facilitator manipulierte Transaktionen einreicht, kann er Gas oder eigene Vermögenswerte verlieren.

Das Kartennetzwerk hat diese Vertrauenskosten durch das Kapital und die Risikomanagementteams der ausstellenden Banken getragen und sie durch Gebühren zurückgeholt. x402 hat diese Rolle entfernt, aber die Kosten nicht beseitigt.

Daher stellt sich die Frage, ob es notwendig ist, eine Verantwortungsebene über dem offenen Protokoll zu schaffen?

Diese Zentralisierung bedeutet nicht, das gesamte x402-Protokoll einem einzigen Betreiber zu übergeben. Jede Zahlungsroute sollte einen klaren Verantwortlichen haben. Mehrere Betreiber können weiterhin unter demselben offenen Standard konkurrieren, und Benutzer können den Facilitator wechseln. Diese Struktur konzentriert die Betriebsverantwortung und bewahrt gleichzeitig die Offenheit des Protokolls und den Wettbewerb zwischen den Anbietern.

Cloudflares Monetization Gateway ist ein mögliches Beispiel. Es behält das programmierbare Zahlungsformat von x402 bei und behandelt gleichzeitig Zahlungsrichtlinien, Validierung und Zugriffskontrolle auf einer einzigen Kontrollschicht. Ein anderer Weg besteht darin, spezialisierte Facilitatoren zu verwenden, die Service-Level-Agreements, Gaslimits, Vorabvalidierung und Ereignisreaktion anbieten.

ERC-8004 und Reputation Systeme scheinen Alternativen zu bieten. Aber Reputation ist nur ein zusätzliches Signal zur Risikobewertung, es reserviert weder Gelder noch bietet Zahlungsgarantien. Ich glaube, dass Reputation allein die Verantwortungslücke nicht schließen kann.

Diese Perspektive erfordert auch eine Neubewertung der Rolle und Struktur der Entdeckungsebene. Diese Ebene kann über die bloße Auflistung verfügbarer Dienste hinausgehen und zu einer Vertrauens- und Routingebene werden, die filtert, welche Ressourcen und Facilitatoren den festgelegten Sicherheitsstandards entsprechen. Wenn Zahlungsgarantien erforderlich sind, kann sie klar zwischen zentralisierten Betreibern, die Garantien bieten, und Zahlungsrouten unterscheiden. Aus dieser Perspektive gibt es zwei wichtige Akteure, die es zu beachten gilt:

Die Integrationsstrategie von CDP (@CoinbaseDev) kombiniert Agentic Wallet, CDP Facilitator und Bazaar und bietet in einem Technologiestack Wallet-, Zahlungs-, Compliance- und Entdeckungsfunktionen.

Die Integrationsstrategie von Orthogonal (@orthogonal_sh) vereint Dienstentdeckung, API-Schlüsselpool, standardisierte Reaktionen und Abrechnung unter einem Konto, einem Saldo und einer Rechnung. Es unterstützt Credits, x402 und MPP. Dies bringt die Komplexität der Verwaltung mehrerer Anbieter und Zahlungsmethoden in ein zentrales Gateway.

Diese Strategien bieten derzeit noch keine Zahlungsgarantien oder Verlustübernahmen. Aber sie bringen fragmentierte Wallet-, Validierungs-, Abrechnungs- und Entdeckungsfunktionen unter einen einzigen Betreiber und schaffen eine Grundlage für eine zentralisierte Verantwortungsebene.

Wenn eine zentralisierte Verantwortungsebene allgemein wird, könnte sich auch die Zahlungsstruktur selbst ändern. Ein mögliches Modell wäre, verify → Geschäftslogik → settle durch verify → settle → Geschäftslogik zu ersetzen.

Die aktuelle Reihenfolge schützt den Verbraucher, vorausgesetzt, die Abwicklung ist irreversibel. Sobald der Betreiber die Verantwortung für Rückerstattungen und Streitbeilegungen übernimmt, wird diese Annahme geändert. Die Abwicklung könnte zuerst bestätigt werden, um das Risiko unbezahlter Rechnungen für den Händler zu beseitigen. Wenn die nachfolgende Ausführung fehlschlägt, kann der Betreiber dem Verbraucher eine Rückerstattung gewähren. Der Betreiber müsste dann die Liquiditätsanforderungen und Abwicklungspflichten vor der endgültigen Abwicklung tragen, was seine Kapital- und Verantwortungsstruktur wichtiger macht.

Dieses Modell folgt nicht dem aktuellen Abwicklungsprozess von x402. x402 wird weiterhin als offenes Interface zur Kommunikation von Zahlungsbedingungen und Autorisierungsdaten fungieren. Betreiber aggregieren die tatsächlichen Geldflüsse und führen die endgültige Abwicklung on-chain durch. Einzelne Zahlungsaufzeichnungen bleiben im internen Hauptbuch des Betreibers, während die Blockchain die aggregierte endgültige Abwicklung aufzeichnet. Da das interne Hauptbuch reversibel ist, verringert diese Struktur das Problem irreversibler Zahlungen. Betreiber können auch Rückerstattungen und Streitigkeiten wie ausstellende Banken behandeln.

Man könnte fragen:

Ist das nicht einfach, die Blockchain als gemeinsame Zahlungsdatenbank zu betrachten?

Ja.

Genauer gesagt, die Blockchain wird zu einem gemeinsamen Abrechnungsbuch, das die endgültigen Salden zwischen den Betreibern aufzeichnet. Einzelne Zahlungen bleiben außerhalb der Kette. Zumindest in diesem Markt könnte es ausreichend sein, diese Rolle zuverlässig zu übernehmen. Das System kann weiterhin die Vorteile niedriger Abwicklungskosten und programmierbarer Währungen nutzen.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.