Coinbase x402 vs. Google A2A: Zwei gegensätzliche Zahlungsreihenfolgen für Agent-zu-Agent-Zahlungen

Ein Entwickler, der einen Recherche-Agenten baut, der Arbeit an drei andere (Suche, Zusammenfassung, Übersetzung) delegiert, benötigt Maschine-zu-Maschine-Zahlungen im Sub-Cent-Bereich. Stripe mit einer Mindestgebühr von 0,30 $ bei einem 0,001 $-Aufruf ist ein 300-facher Overhead; On-Chain-L1-Gas ist ähnlich; Abonnements erfordern menschliche Vorverhandlung. Er fand x402, Coinbases Implementierung von HTTP 402 „Payment Required“ – einen zustandslosen Vermittler für Sub-Cent-Zahlungen auf Base, der in etwa 2 s für etwa 0,0001 $ über EIP-3009-vorab-signierte Authentifizierungen als Header abrechnet.

Die Kernfrage: Zahlungsreihenfolge

Wenn man prüfen (schnell, off-chain), abrechnen (langsam, on-chain) und die eigentliche Arbeit (LLM-Aufruf) hat, sind drei Reihenfolgen möglich:

• A: prüfen → ausführen → abrechnen
• B: prüfen → abrechnen → ausführen
• C: prüfen → reservieren → ausführen → erfassen (Kreditkarten-Halte-Muster – nicht möglich mit EIP-3009s Einmal-Design)

Coinbases Middleware verwendet A; Googles A2A-x402-Erweiterung verwendet B. Der Unterschied hängt von der Arbeitsdauer ab: Coinbases Aufrufer ist ein schneller API-Endpunkt (unter 500 ms), daher ist die Lücke zwischen Prüfen und Abrechnen vernachlässigbar. Wenn ein Agent andere Agenten aufruft, dehnt sich das Fenster auf Sekunden oder Minuten – lang genug, dass der Zahlende nach dem Prüfen, aber vor dem Abrechnen sein Wallet leeren kann, was verschenkte Rechenleistung bedeutet.

Vorab-Abrechnen gewinnt für agentische Workloads

Der Entwickler wählte B (prüfen → abrechnen → ausführen), weil Agentenarbeit echtes Geld kostet (0,30 $+ pro Aufruf) und langsam ist. Mit Vorab-Abrechnen wird bei fehlgeschlagener Zahlung nie das LLM ausgeführt. Er testete vier Szenarien unter Last:

• Gültige Signatur, Wallet vor Abrechnung geleert → Abrechnung wird rückgängig gemacht, keine Rechenleistung verschwendet (0 $ Verlust).
• Zwei parallele Anfragen vom selben Wallet mit unterschiedlichen Nonces, gleichem Guthaben → eine Abrechnung gelingt, die andere scheitert am Chain-Race, erreicht nie das Modell.
• Wiederholter Zahlungsheader → wird bei Nonce-Prüfung vor dem Prüfen abgefangen, gibt 402 zurück.
• Vermittler-Timeout bei 10 s, aber Chain bestätigt bei 25 s → verwaiste Zahlung (Zahlender belastet, Aufgabe fehlgeschlagen). Dies ist eine Eigenschaft der ausgelasteten Chain, nicht durch Reihenfolge behebbar.

Ein Fehlermodus der Vorab-Abrechnung: Zahlung landet, aber Arbeit schlägt fehl (500-Fehler, Bug). Der Anbieter handhabt dies mit persistierten Nonce/Auth-Metadaten und manuellen Rückerstattungen.

Der vollständige Ablauf ist Open Source mit E2E-Tests, die alle vier Szenarien auf einem Laptop ausführen. github.com/GetBindu/Bindu