Titel: X402 erklärt: HTTP-native Mikrozahlungen für KI-Agenten

Die X402-Spezifikation nutzt den Standard-HTTP-Status „402 Payment Required“ neu, um einen regulären API-Aufruf in eine On-Chain-Mikrozahlung zu verwandeln. KI-Agenten können nun Gebühren für LLM-Abfragen oder Datenfeeds ohne menschliches Eingreifen begleichen, und Anbieter können pro Anfrage abrechnen, ohne ein eigenes Rechnungssystem aufbauen zu müssen.

Warum KI-Agenten ein Zahlungsprotokoll benötigen

Autonome Agenten verknüpfen Sprachmodelle, Websuchwerkzeuge und proprietäre Datenquellen miteinander. Jeder dieser Schritte verursacht Kosten – etwa Token-Gebühren für ein Modell oder Gebühren pro Aufruf für eine Marktdaten-API. Heutige Geschäftsmodelle basieren auf API-Schlüsseln, die an Abonnement-Konten gebunden sind, manuellen Aufladungen von Guthaben oder einer nachträglichen Abrechnung. Diese Methoden widersprechen dem Versprechen der „menschfreien“ Autonomie von Agenten und erhöhen den betrieblichen Aufwand für die Anbieter.

X402 bietet einen Mittelweg: einen Request-Response-Ablauf, der wie jeder andere HTTP-Aufruf aussieht, aber einen integrierten Zahlungsschritt enthält, der auf einer öffentlichen Blockchain aufgezeichnet wird. Die einzige Voraussetzung ist, dass der Client eine Transaktion auf der vom Server angegebenen Chain signieren und senden kann.

Der X402-Handshake im Detail

  1. Initialer Request – Der Agent sendet ein normales GET oder POST an einen kostenpflichtigen Endpunkt. Es sind keine speziellen Header erforderlich.
  2. Server antwortet mit 402 – Die Antwort enthält den Status 402 und einen JSON-Body, der Folgendes auflistet:
    • amount – die vom Server erwartete Gebühr in der kleinsten Token-Einheit;
    • token – die ERC-20 (oder gleichwertige) Contract-Adresse;
    • chain – die Blockchain-Kennung, auf der die Zahlung aufgezeichnet werden muss;
    • optional nonce – ein eindeutiger Wert, der Replay-Angriffe verhindert.
  3. Client bereitet Zahlung vor – Der Agent prüft die Token-Adresse und die Chain anhand seiner Richtlinien (z. B. nur vertrauenswürdige Chains). Er erstellt dann eine Transaktion, die den erforderlichen Betrag an die vom Server bereitgestellte Adresse überträgt, signiert diese mit seinem privaten Schlüssel und sendet sie ab.
  4. Übermittlung des Payment-Hashs – Sobald der Transaktions-Hash verfügbar ist, wiederholt der Client den ursprünglichen Request und fügt diesmal einen X-Payment-Header hinzu, der den Hash enthält. Der Payload bleibt unverändert.
  5. Server verifiziert On-Chain – Der Server sucht in der Blockchain nach einer bestätigten Überweisung, die mit dem Betrag, dem Token, der Chain und dem Nonce übereinstimmt. Wenn er eine Übereinstimmung findet, gibt er die angeforderten Daten mit dem Status 200 OK zurück.

Jede HTTP-Client-Bibliothek, die benutzerdefinierte Header unterstützt und ein Blockchain-SDK aufrufen kann, ist in der Lage, diese Schritte auszuführen. Es ist kein neues Transportprotokoll oder ein benutzerdefinierter Socket-Layer erforderlich.

Abwägungen, die man beachten sollte

  • Latenz – Die Bestätigung auf einer öffentlichen Chain verursacht Verzögerungen.
  • Gas-Gebühren – Selbst günstige Chains erheben Gas-Gebühren; Zahlungen unter 0,001 $ können unwirtschaftlich sein.
  • Komplexität – Agenten müssen fehlgeschlagene Transaktionen und Chain-Reorganisierungen handhaben; eine robuste Retry-Logik ist unerlässlich.
  • Sicherheit – Der Nonce verhindert Replay-Angriffe, aber Agenten müssen dennoch ihre privaten Schlüssel schützen und vermeiden, diese für nicht zusammenhängende Dienste wiederzuverwenden.