Architektur

Liquidation ohne Ausführungsnachweis ist eine bezahlte Blackbox: Die Agent-Zahlungs-Audit-Schleife schließen

Von IdeaBosqueZuletzt aktualisiert: 2026年7月30日

Kernpunkte

x402 verarbeitete im ersten Jahr 169 Millionen Agent-Zahlungen auf Base, aber payment_hash beweist nur, dass eine Transaktion liquidiert wurde — nicht, was der Agent getan hat — die Belegerweiterung (OMA3/x402, in das Protokoll integriert) erfasst, wer bezahlt hat, welchen Service, wann und eine Zahlungsreferenz, aber nicht, welche Screening-Version, Policy-Regel oder Modellversion serverseitig lief (Chainalysis, 2026; OMA3, 2026).
Der IETF-Entwurf action_ref (draft-etcheverry-action-ref-02, Juli 2026) definiert einen inhaltsadressierten Identifikator — SHA-256 über kanonisches JSON von agent_id, action_type, scope, timestamp — den jeder Prüfer ohne Vertrauen zum Emitter neu berechnet — mit optionalen Feldern für Policy-Versions-Auditierbarkeit, sodass ein Prüfer nicht nur feststellen kann, dass Regel 7 ausgelöst wurde, sondern welche Version von Regel 7 zu diesem Zeitpunkt aktiv war.
Der IETF-Entwurf x402-retention-chain (draft-hopley-x402-retention-chain-06, Juni 2026) formalisiert die Komposition: ein Settlement-Action Binding (binding_ref) bindet payment_hash an action_ref in einem Beleg — plus ein Policy Binding (policy_bound_ref), das die geltende Policy-Version an die Aktion bindet, und ein Compliance Gate Binding (gate_ref), das ein ALLOW/REFER/DENY-Urteil an die Policy-Referenz bindet.
Alle Konstruktionen verwenden nur SHA-256 und JCS (RFC 8785), von jeder Partei mit den Belegen verifizierbar, ohne den Emittenten zu kontaktieren — erfüllt die Audit-Trail-Anforderungen von MiCA Artikel 80, DORA Artikel 14 und AMLR Artikel 56 (IETF draft-hopley-x402-retention-chain-06, 2026).
Liquidation ohne Ausführungsnachweis ist eine bezahlte Blackbox; Ausführungsnachweis ohne Liquidation ist eine unbeweisbare Behauptung; Agenten brauchen beides, um die Vertrauensschleife zu schließen — x402 liquidiert den Austausch, action_ref bindet den Ausführungskontext und binding_ref setzt sie zu einem prüfbaren Beleg zusammen.

Das Problem: sechs Protokolle, null Ausführungsbelege

Der Agent-Commerce-Stack konvergierte 2026: UCP (Discovery), A2A (Kommunikation), MCP (Werkzeuge), ACP (Checkout), AP2 (Autorisierung), x402 (Liquidation). Sechs Schichten, über sechzig Launch-Partner — Google, Shopify, OpenAI, Stripe, Visa, Coinbase. Jeder Kauf ist abgedeckt: der Agent entdeckt, verhandelt, nutzt Werkzeuge, checkt aus, wird autorisiert und zahlt.

Außer einer Sache: der Beweis, dass der Agent tatsächlich getan hat, was er tun sollte.

x402 begleicht die Zahlung. Der payment_hash beweist, dass die Transaktion auf Base in etwa 200ms abgeschlossen wurde. Die x402-Belegerweiterung (über die OMA3/x402-Kollaboration in das Protokoll integriert) fügt einen signierten, portablen Kaufbeleg hinzu — wer bezahlt hat, auf welchen Service zugegriffen wurde, wann und eine Zahlungsreferenz. Dieser Beleg ist digital vom Service signiert, manipulationssicher und universell verifizierbar.

Er zeichnet nicht auf, was innerhalb des Service passierte. Der Beleg beweist, dass der Agent bezahlt hat. Er beweist nicht, welche Screening-Version lief, welche Policy-Regel ausgelöst wurde oder welche Modellversion die Entscheidung produzierte. Für ein Lieferanten-Compliance-Check beweist der Beleg, dass der Agent für den Screening-API-Aufruf bezahlt hat. Er beweist nicht, welche Version der Screening-Logik tatsächlich ausführte.

Für regulierte Beschaffung — EU AI Act Artikel 12, Durchsetzung ab 2. August 2026, FCA SYSC 9.1, SOC 2 CC7.x — ist diese Lücke der Compliance-Blocker. Logs können umgeschrieben werden. Ein Zahlungsbeleg, der nicht an die Ausführung bindet, ist eine bezahlte Blackbox.

Die Lösung: zwei IETF-Entwürfe, die Liquidation und Ausführung zusammenführen

action_ref — inhaltsadressierte Ausführungsidentität

Der IETF-Entwurf action_ref (draft-etcheverry-action-ref-02, 23. Juli 2026) definiert einen deterministischen, inhaltsadressierten Identifikator für Agent-Aktionen. Der Identifikator wird berechnet als:

action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp}))

Wobei JCS das JSON Canonicalization Scheme (RFC 8785) ist, das eine eindeutige Byte-Sequenz für jeden JSON-Wert erzeugt. Die vier Preimage-Felder:

Feld	Was es erfasst
`agent_id`	Der terminale Executor nach Delegationsauflösung (in einer Kette A→B→C ist agent_id C)
`action_type`	Semantisches Label (`payment.send`, `compliance.screen`, `oracle.signal`)
`scope`	Der Anforderungs-Intent-Umfang des Agenten zum Zeitpunkt der Aktion
`timestamp`	RFC 3339 UTC mit genau 3 Millisekunden-Stellen

Das Designziel ist Operator-Unabhängigkeit: ein Verifizierer, der die vier Felder hat, kann action_ref neu berechnen, ohne die Infrastruktur des Emitters aufzurufen. Der Entwurf enthält optionale Felder für Policy-Rotations-Auditierbarkeit — sodass ein Prüfer nicht nur feststellen kann, dass Regel 7 ausgelöst wurde, sondern welche Version von Regel 7 zu diesem Zeitpunkt aktiv war.

x402-retention-chain — die Bindungsschicht

Der IETF-Entwurf x402-retention-chain (draft-hopley-x402-retention-chain-06, 24. Juni 2026) definiert sieben kryptografische Konstruktionen. Drei sind direkt für die Schleife Zahlung → Liquidation → Audit relevant:

Settlement-Action Binding (binding_ref) — bindet den x402-payment_hash an action_ref in einem Beleg. Eine Liquidationsbescheinigung beweist nun nicht nur, dass eine Zahlung stattfand, sondern welcher verifizierten Agent-Aktion sie entspricht. Ein Prüfer mit dem Beleg folgt der Kette von payment_hash zu action_ref zum Aktionsdatensatz und bestätigt beides, ohne den Emittenten zu kontaktieren.
Policy Binding (policy_bound_ref) — bindet einen inhaltsadressierten Schnappschuss der geltenden Policy an die Aktion. Eine Screening-Entscheidung ist gegen die genaue Policy-Version verifizierbar, die bei der Entscheidung galt. Eine Policy-Rotation ist durch Neuberechnung erkennbar — der Hash ändert sich, wenn sich die Policy ändert, sodass der Prüfer den Übergang sieht.
Compliance Gate Binding (gate_ref) — bindet ein ALLOW/REFER/DENY-Compliance-Urteil und eine PII-freie Zahler-Referenz an die Policy-Referenz. Das Screening-Ergebnis ist nachweisbar an die Regelversion gebunden, die es produziert hat, ohne personenbezogene Daten im gebundenen Datensatz.

Alle Konstruktionen verwenden nur SHA-256 und JCS. Keine externe Infrastruktur erforderlich. Kein Kontakt zum Emittenten. Jede Partei mit den Belegen kann verifizieren.

Die Audit-Schleife: Zahlung → Liquidation → prüfbare Logs

Die vollständige Schleife für eine regulierte Agent-Commerce-Transaktion:

Zahlung — der Agent ruft eine kostenpflichtige API auf (Lieferanten-Compliance-Screening, Lieferantenverifikation, Produkt-Lookup). Der Server gibt HTTP 402 mit Zahlungsbedingungen zurück.
Liquidation — der Agent signiert eine Autorisierung, versucht es mit PAYMENT-SIGNATURE erneut, der Facilitator verifiziert und begleicht auf Base in etwa 200ms. Der Server gibt die Ressource mit einem Liquidationsbeleg zurück, der payment_hash enthält.
Ausführung — der Agent führt die Aktion aus (Screening, Lookup, Entscheidung). Er emittiert action_ref = SHA-256(JCS({agent_id, action_type, scope, timestamp})) — einen inhaltsadressierten Identifikator, den jeder Dritte aus den vier Preimage-Feldern neu berechnen kann.
Bindung — der binding_ref verknüpft payment_hash mit action_ref in einem Beleg. Der policy_bound_ref verknüpft die geltende Policy-Version mit der Aktion. Der gate_ref verknüpft das Compliance-Urteil mit der Policy-Referenz.
Audit — ein Prüfer (Regulator, Gegenpartei, interne Compliance) hält den zusammengesetzten Beleg. Er berechnet action_ref aus den vier Feldern neu. Er verifiziert payment_hash gegen die Base-Blockchain. Er prüft policy_bound_ref, um zu bestätigen, dass das Screening unter der korrekten Policy-Version lief. Er prüft gate_ref, um zu bestätigen, dass das Urteil übereinstimmt. Kein Aufruf des Operators. Kein Vertrauen erforderlich.

Die Schleife antwortet: Zahlung beglichen, diese spezifische Screening-Version lief, unter dieser Policy-Version, zu diesem Timestamp, mit diesem Urteil. Zwei Schichten, ein Beleg.

Warum jede Schicht allein versagt

Das Diagramm unten zeigt die volle Schleife — Zahlung, Liquidation, Ausführung, Bindung und Audit — und warum jede Schicht allein unzureichend ist:

Liquidation ohne Ausführungsnachweis ist eine bezahlte blackbox. Der Beleg sagt, dass der Agent für ein Compliance-Screening bezahlt hat. Er sagt nicht, welche Version der Screening-Logik lief, ob die Policy aktuell war oder ob das Urteil korrekt war. Ein Regulator, der fragt „haben Sie diesen Lieferanten gegen die Sanktionsliste vom Juli 2026 oder die vom Juni 2026 geprüft?“ bekommt von payment_hash allein keine Antwort.

Ausführungsnachweis ohne Liquidation ist eine unbeweisbare Behauptung. Der Agent sagt, er habe den Lieferanten gescreeningt. Ohne einen Zahlungsbeleg, der das Screening an eine liquidiette Transaktion bindet, gibt es keine ökonomische Evidenz, dass das Screening tatsächlich stattfand. Die Behauptung ist kostenlos zu machen und wertlos zu prüfen.

Die Kombination schließt die Vertrauensschleife. Liquidation verankert das ökonomische Ereignis — Beweis, dass Geld floss. Ausführungsnachweis verankert das semantische Ereignis — Beweis, was getan wurde. Die Bindung verknüpft sie. Ein Prüfer verifiziert beide aus einem Beleg und berechnet Hashes neu, ohne einer Partei in der Kette zu vertrauen.

Was dies für einen B2B-Build bedeutet

Ein Beschaffungs-Agent, der Bestellungen aufgibt, Zahlungen autorisiert und Lieferanten screeningt, braucht die volle Schleife in seinem Audit-Trail. Die Architektur:

x402 handhabt die Liquidation. Der Agent erhält eine 402-Antwort von der Lieferanten-Compliance-API, zahlt in USDC auf Base und erhält einen Liquidationsbeleg mit payment_hash.
action_ref handhabt die Ausführungsidentität. Der Agent emittiert action_ref für jede Compliance-Screening-Aktion und erfasst agent_id, action_type (compliance.screen), scope (Lieferanten-ID und Screening-Typ) und timestamp.
binding_ref setzt sie zusammen. Der Liquidationsbeleg trägt payment_hash und action_ref in einem Umschlag. Der policy_bound_ref erfasst, welche Policy-Version das Screening regierte. Der gate_ref erfasst das ALLOW/DENY-Urteil.
Der Audit-Trail ist die zusammengesetzte Belegkette. Ein Prüfer berechnet action_ref aus den vier Feldern neu, verifiziert payment_hash on-chain, prüft den Policy-Versions-Hash und bestätigt das Urteil — alles ohne den Agent-Operator, den Zahlungs-Facilitator oder den Screening-Service zu kontaktieren.

Für eine regulierte Branche — pharmazeutische GMP-Compliance, aerospace ITAR-Screening, Sanktionsprüfungen im Finanzwesen — ist dies der Unterschied zwischen einem prüfbaren Agent und einem Agent, der ein Compliance-Risiko ist. Die EU-AI-Act-Artikel-12-Aufzeichnungspflicht (Durchsetzung ab 2. August 2026) verlangt die Rückverfolgbarkeit von KI-Systementscheidungen. MiCA Artikel 80 verlangt Transaktionsaufzeichnungen. DORA Artikel 14 verlangt Audit-Trails für operationelle Resilienz. Die binding_ref-Konstruktion erfüllt alle drei aus einem Beleg.