Was ist x402
Einführung
x402 ist ein offener Zahlungsstandard, der im Jahr 2025 eingeführt wurde und darauf abzielt, den HTTP-Statuscode 402 offiziell zu aktivieren und ihn zu einem nativen Zahlungsmechanismus im Internet zu machen
Ein technischer Standard, der von der Netzwerkinfrastrukturfirma Cloudflare und der Kryptowährungsbörse Coinbase gemeinsam vorangetrieben wird.
Im Gegensatz zum traditionellen Modus, bei dem Konten erstellt, Kreditkarten gebunden oder Guthaben vorab aufgeladen werden müssen, integriert x402 die Zahlungsanforderung direkt in die HTTP-Antwort, sodass der Client (egal ob Mensch, Roboter oder AI-Agent) die Zahlungsinformationen automatisch erkennen und die Abwicklung durchführen kann.
x402 ermöglicht, dass eine einzelne HTTP-Anfrage gleichzeitig die Eigenschaften „Datenübertragung“ und „Wertübertragung“ hat.
Sobald die Zahlung abgeschlossen ist, wird der Zugriffsbereich sofort freigeschaltet – ohne Konto oder manuelle Bedienung.
Ursprüngliche Designidee
Löst die Anforderungen an häufige, kleine, automatisierte Zahlungen, wenn Maschinen-zu-Maschine (M2M) und KI-Agenten auf Netzwerkdienste (z. B. APIs) zugreifen.
Zum Beispiel könnte ein KI-Programm pro Sekunde tausendmal Daten-APIs aufrufen; jede Zahlung kostet 0.001 Dollar. Herkömmliche Zahlungsarten (z. B. Kreditkarten) können das nicht handhaben, und x402 zielt darauf ab, eine standardisierte Lösung zu bieten.
Historischer Kontext
Der HTTP-Standard hat seit den frühen Standardisierungen den Statuscode 402 „Payment Required“ vorgesehen, wurde aber nie wirklich genutzt.
Der Grund liegt in: dem Zusammenwirken von Technik, Geschäft und Nutzergewohnheiten
Keine einheitliche Spezifikation, keine einheitliche Abwicklungsweise usw. (z. B. passende Felder): wie die Nachrichtenformate aussehen sollen, an wen man bezahlt, wie viel, wie man es beweist usw. – all das ist unklar.
Kein öffentlicher gemeinsamer Pfad, z. B. eine Blockchain: Dann können alle keinen Konsens erreichen.
Mikrozahlungen sind unökonomisch: selbst bei Transaktionen im Cent-Bereich muss man dieselbe feste Gebühr von 30 Cent zahlen – Verlust (aus Sicht des Designs der Kreditkartenfirmen).
Traditionelle Transaktionen haben Chargebacks, Rückerstattungen, Compliance-Prüfungen usw.; das kann leicht schiefgehen.
Teilnehmer von x402
Client: der Benutzer, die App oder der KI-Agent, der die Anfrage auslöst
Server (Backend)/Provider: die Stelle, die Daten oder Dienste bereitstellt (API, Website usw.)
Facilitator (Settlement-Partei): verantwortlich dafür zu prüfen, ob die Zahlung abgeschlossen ist. Die meisten aktuellen Implementierungen basieren zwar auf der Blockchain, aber theoretisch kann jedes System mit verifizierbarer Abwicklungsfähigkeit angebunden werden.
Enger und weiter gefasste Rollen
Eng gefasst: Provider für Ressourcen, verstanden als Server, der 402-Rechnungen ausstellt
Weiter gefasst: Anbieter für begleitende Dienste; Micro-x402 stellt die Basis und passende Beteiligte bereit
Tools: SDKs, Wallet-Plugins usw.
Plattform: Agentenbereitstellung, Hosting usw.
Infrastruktur: RPC, Indexing usw.
Facilitator
Das ist im Grunde ein Middleware, die eine Brücke zwischen Web und Blockchain bildet
Angenommen, der Server sendet einem KI eine 402-Rechnung und fordert die Zahlung von 1 USDC. Auf welcher Kette wird bezahlt? Wie weiß der Server, dass wirklich bezahlt wurde?
Der Facilitator ist im Grunde wie ein Outsourcing-Dienst: Er prüft On-Chain-Daten und bestätigt, dass die Transaktion echt ist.
Zertifikat erstellen und an den Server senden
Der Server vertraut dem festgelegten Facilitator – damit ist die Transaktion abgeschlossen.
Die Rolle, die der Facilitator typischerweise übernimmt, umfasst im Allgemeinen Coinbase CDP; CloudFlare könnte es ggf. eingebettet haben.
Web3-Zahlungs-Gateway, z. B. USDC
Anbieter von Knotendiensten
Zahlungs-Giganten: Paypal, Visa
Self-Hosting: der API-Anbieter selbst
In der Praxis: Es könnte KYT oder Risk-Control geben, gezielt für den Facilitator
Grundablauf
Client (Client) → Server (Provider): Ressourcen anfordern. Zum Beispiel fordert ein KI-Agent bei einem Server eine bezahlte Ressource an (API-Schnittstelle).
Server (Provider) → Client (Client): Der Server gibt HTTP 402 zurück und fügt Zahlungsbedingungen hinzu (Zahlungsasset, Betrag, Empfängeradresse usw.). Das entspricht einer standardisierten Rechnung und macht deutlich, welche Menge, Währung, Adresse usw. bezahlt werden müssen.
Client (Client) → Blockchain: Der Client initiiert die Zahlung mit einem Stablecoin (z. B. USDC). Die Blockchain führt die Zahlung aus und fügt einen Nachweis hinzu.
Client (Client) → Koordinator (Facilitator): Der Client nimmt den txHash und fordert die Verifikationsadresse des Facilitators an (d. h. die Adresse, die in Schritt 2 angegeben ist).
Koordinator (Facilitator) → Blockchain: Der Facilitator prüft, ob der txHash echt und gültig ist und ob der Betrag stimmt.
Koordinator (Facilitator) → Client (Client): Nachdem der Facilitator die Verifizierung bestanden hat, stellt er dem Client einen zeitlich gültigen „neuen Ausweis“ aus (z. B. ein JWT-Token).
Client (Client) → Server (Provider): Der Client fordert die Ressource erneut an und fügt in den Request-Header diesen „neuen Ausweis“ hinzu, den der Facilitator ausgestellt hat.
Server (Provider): Der Server überprüft nur, ob dieser Ausweis von dem von ihm vertrauten Facilitator ausgestellt wurde. Verifizieren
Der gesamte Prozess ist programmierbar und kann ohne manuelle Beteiligung oder ein Kontensystem auskommen.
Vergleich und Unterschiede
Warum wurde es derzeit überhaupt erwähnt
KI-Agenten müssen pro Vorgang bezahlen; das passt: häufig, klein, automatisiert.
Technisch ausgereift: Blockchain, Stablecoins
Andere Statuscodes
401: nicht authentifiziert, Authentifizierung fehlt, z. B. Benutzername/Passwort
403: Zugriff verboten, nicht genügend Berechtigung
404: Inhalt nicht gefunden
500: Fehler auf der Serverseite
Zu lösende Probleme
Zahlungsproblem von KI-Agenten
Häufige, reibungsintensive Mikrozahlungen
Vor x402: Angenommen, ein KI muss 100 verschiedene APIs aufrufen, um eine Aufgabe zu erledigen
Dann muss man zuerst manuell bei 100 verschiedenen Websites die API registrieren
Zahlungsinformationen zu diesen 100 Websites hinzufügen
Je nach Zahlungsanforderung binden, z. B. monatlich, pro Vorgang etc.
100 Rechnungen erhalten
relevante ERCs
EIP-3009: „Transfer ERC-20s with a signature“
Wird zuerst von USDC (v2) umgesetzt und beworben
Lasst den Tokeninhaber erst einmal offline eine „Überweisungsautorisierung“ signieren. Jede Vermittlerpartei oder der Empfänger kann dann diese Autorisierung auf die Kette bringen und die eigentliche Überweisung durchführen. Ziel: Gas kann übernommen werden, atomare Abwicklung, Vermeidung von Allowance-Lücken; geeignet für „Push-Zahlungen“ pro Vorgang.
Agent (Client) signiert lokal mit seinem eigenen privaten Schlüssel (oder einem Session-Schlüssel) eine Nachricht im EIP-3009-Format; Inhalt: „Autorisierung: Überweise 0.01 USDC von meinem Wallet an das Wallet des Providers.“ Dieser Vorgang ist sofort und verbraucht kein Gas. Der Agent sendet diese Signatur als „Zahlungsnachweis“ an den Facilitator.
Normaler Handel ist: Der Agent erstellt selbst, signiert und broadcastet eine Transaktion und hält dabei ETH als Gas. Angenommen, der Agent hat nur USDC – dann wird es umständlich. EIP-3009: Generiere lokal eine Signatur: ich, autorisiere, dass 100 USDC an B übertragen werden.
Der Agent muss unter Umständen kein Gas benötigen; er kann auch durch jemanden bezahlen lassen – der Facilitator übernimmt die Zahlung.
Das Ergebnis der Übernahme ist: Der Facilitator nimmt sich aus dieser Zahlung seine Vergütung zurück: ein Abzug/Anteil.
Oder der Provider übernimmt die Zahlung, um Marktanteile zu gewinnen und die Nutzererfahrung zu verbessern.
Kernvorteil: Die Wallet des KI-Agents muss nicht ETH halten, um Gas zu bezahlen, und muss auch keine komplexen On-Chain-Transaktionen verwalten (z. B. Nonce, Gas Price). Man muss nur signieren können.
EIP-2612: Permit: signaturbasierte ERC-20-Zuweisungen " (autorisierung über Signatur)
Ermöglicht es, dass Nutzer ERC-20-Token durch **„Signatur Off-Chain“ (Off-chain Signature)** für das approve() (Autorisierung) verwenden können, ohne dafür separat Gasgebühren zahlen zu müssen.
Vor 2612:
USDC – Umtausch von ETH: Autorisierung – Tausch: dafür sind zwei Schritte und Signaturen nötig, gleichzeitig werden zwei Gaszahlungen fällig.
Nach 2612:
Autorisierung wird zu einer Off-Chain-Signatur: kostenlos, schnell „Ich autorisiere Uniswap (Spender), von mir (Owner) 100 USDC (Value) zu nehmen. Diese Signatur ist gültig bis (Deadline)“.
Uniswap führt nach Erhalt der Signatur zwei Dinge der Reihe nach aus: Die Signatur an USDC senden; nachdem USDC verifiziert hat, ist die Autorisierung erledigt.
Transaktion aufrufen und den Tausch abschließen
EIP-2612 sagt dem Smart Contract: „Du bist berechtigt, hier bei mir Geld abzuholen.“
Zum Beispiel: eine Vollmacht unterschreiben, die dem Kurier (DApp) erlaubt, morgen ein Paket abzuholen.
EIP-3009 sagt dem Smart Contract: „Überweise bitte sofort mein Geld an B.“
Zum Beispiel: Man schickt einen Gutschein. Jeder (Relayer), der ihn abholt, kann ihn sofort einlösen.
Im x402-Szenario werden typischerweise 3009-Anwendungen breiter verwendet, weil es direkt effizient ist. Wenn jedoch bestimmte Stablecoins eingeschränkt sind, könnte man stattdessen 2612 nutzen.
Privatsphäre-Probleme
x402: Da die Zahlung auf der Blockchain stattfindet, ist im Grunde alles öffentlich – einschließlich Zahler, Empfänger, Betrag, Zeit usw.
Für den Facilitator kann es IP-Adressen sehen und Hashes verifizieren. Um es böse zu sagen: Der Facilitator kann Off-Chain-IP und On-Chain-Identität miteinander verknüpfen.
Für den Provider gilt außerdem: Er kann die IP-Adresse des Clients sehen sowie die konkreten Ressourcen, die der Client anfragt (z. B. eine bestimmte API usw.).
Angenommen, Facilitator und Provider arbeiten zusammen (oder sie sind dasselbe Unternehmen; das ist im Cloudflare/Coinbase-Ökosystem sehr wahrscheinlich). Dann haben sie vollständige Überwachungsfähigkeiten: wer (IP/Wallet) hat wann und warum (API-Pfad) wie viel bezahlt.
Wie löst man das Problem
ZK: z. B. auf einem privaten Layer-2 bezahlen, etwa Azetc?
Zum Beispiel: private Zahlungskanäle – ähnlich wie das Lightning Network: öffentliche Kette vermeiden, nur das Endergebnis wird schließlich auf der Kette gespeichert.
Zentralisiert, hat nicht viel Bedeutung – aber natürlich kann es so ein Setup geben, z. B. wenn der Client 100 Dollar im Voraus auf deren „Coinbase Agent“-Konto einzahlt (über die Kette oder per Kreditkarte).
Jedes Mal, wenn der Provider 402 zurückgibt, muss der Facilitator nur in seiner eigenen Datenbank die Guthaben des Clients abziehen und das Guthaben beim Provider verbuchen.
FHE:
Die gewünschte Ressource verschlüsseln und an den Provider senden. Der Provider kann direkt auf den verschlüsselten Daten Berechnungen durchführen.
und 402-Rechnungen zurückgeben
Verschlüsselt: datenbezogene Informationen
Nicht verschlüsselt: zahlungsbezogene Informationen
Persönliche Ansicht
x402 ist zwar nützlich, aber nicht so großflächig; eher eine Lösung für einen vertikalen Bereich als ein allgemeines Paradigma.
Aktuell entwickelt sich x402 vor allem im Web3-Bereich. Aber um hier wirklich große Ergebnisse zu erzielen, braucht man mehr Unterstützung aus Web2.
Ein KI-Agent hat eigentlich klare Grenzen; man kann darauf fokussieren. Im Grunde gehört es zu einem Teilbereich des Payment, aber es hat nicht so eine große Wirkung. Payment und Privatsphäre sind eher auf einer tieferen Ebene.
Aber basierend auf dem Konzept „Fette Anwendungen, dünne Protokolle“ könnte es gut sein, dass ein paar große Player auftauchen.
Kurzfristig positiv, langfristig jedoch Vorbehalte; nicht weil das Konzept unpassend wäre, sondern weil die Umsetzung (hängt).
Referenz: https://mp.weixin.qq.com/s/gEu1c7WYx2oOFF5uyludpQ