Originalquelle: Waterdrop Capital

Zusammenfassung

Große Modelle entwickeln sich von Werkzeugen, die Fragen beantworten, zu intelligenten Agenten, die planen, Werkzeuge aufrufen und Ergebnisse liefern können. Gleichzeitig kombinieren sich stabile Coin-Abrechnungen, HTTP-native Zahlungsprotokolle (HTTP 402) und intelligente Wallets zunehmend zu einer für Maschinen konzipierten Zahlungsinfrastruktur. Ein Programm kann zur Laufzeit ein Angebot erhalten, eine Autorisierung signieren und eine Mikrozahlung abschließen – etwas, das vor wenigen Jahren noch reine Theorie war, heute aber ein realisierbarer technologischer Weg ist.

Doch „Maschinen können zahlen“ bedeutet nicht automatisch „Maschinen können Transaktionen abschließen“. Wenn ein intelligenter Agent Suchdienste, Daten, Rechenleistung, Inhaltsgenerierung oder professionelle Analysedienste erwerben muss, stehen ihm weiterhin Herausforderungen wie die Auffindung von Endpunkten, der Vergleich von Angeboten, plattformübergreifende Zahlungen, Budgetkontrolle, Lieferbestätigung und einheitliche Abrechnung entgegen. Zahlungsinfrastrukturen regeln, wie Wert transferiert wird, lösen aber nicht automatisch, wie Nachfrage auf Angebot trifft oder ob nach der Zahlung tatsächlich die richtige Leistung erbracht wurde.

Das heißt: In der nächsten Phase von Agentenzahlungen dürfte der Wettbewerb sich nicht mehr allein auf Protokoll-Durchsatz, Abrechnungsgeschwindigkeit oder Anzahl unterstützter Blockchains konzentrieren, sondern vielmehr darauf, ob eine echte maschinennahe Käuferinfrastruktur aufgebaut werden kann. Dieser Artikel untersucht, warum Agentenzahlungen zu einem eigenständigen Feld werden – ausgehend von Nachfragestruktur, Protokollentwicklung, realen Engpässen und Arbeitsteilung im Markt – und welche zentralen Lücken noch vor einer breiten Einführung geschlossen werden müssen.

Einleitung: Intelligente Agenten erhalten ein begrenztes „freies Budget“

In den letzten zwei Jahren haben sich die Fähigkeiten intelligenter Agenten sehr rasch weiterentwickelt. Frühe große Modelle behandelten vor allem Informationsgenerierung – Nutzer stellten Fragen, die Modelle lieferten Text. Später ermöglichte der Aufruf externer Werkzeuge das Durchsuchen von Webseiten, Abfragen von Datenbanken, Ausführen von Code und Steuern von Software. Noch einen Schritt weiter: Intelligente Agenten zerlegen Ziele, erstellen Pläne und passen Aktionen über mehrere Ausführungszyklen hinweg an externe Ergebnisse an.

Wenn die Ausführungsziele auf kostenlose Tools oder interne Unternehmenssysteme beschränkt waren, konnten Entwickler Zugriffsrechte vorab konfigurieren. Hochwertige Dienste auf offenen Märkten erfordern jedoch meist Zahlung: Echtzeit-Finanzdaten kosten pro Abruf, Web-Scraping verbraucht Credits, Inferenz- und GPU-Rechenleistung wird nutzungsabhängig abgerechnet, Video-Generierung und professionelle Datenbanken haben klare Preise. Damit ein intelligenter Agent eine Aufgabe eigenständig abschließen kann, muss er zur Laufzeit zwangsläufig zum Käufer werden.

Das klassische API-Geschäftsmodell war für diesen Kauftyp nicht konzipiert. Es erfordert, dass eine Person zunächst eine Website besucht, ein Konto erstellt, eine Bankkarte verknüpft, einen Tarif auswählt, einen API-Schlüssel sicher verwahrt und diesen dann in die Programmumgebung einfügt. Kaufentscheidung und tatsächlicher Aufruf sind zeitlich getrennt: Der Mensch kauft vor der Aufgabe, die Software nutzt nur das bereits gekaufte Kontingent.

Ein Agent weiß möglicherweise erst beim Erreichen eines bestimmten Arbeitsschritts, was er benötigt. Er kann nicht im Voraus vorhersagen, welche Datenquelle er letztlich nutzen wird – und sollte vom Nutzer auch nicht für jeden potenziellen Dienst einzeln ein Konto anlegen müssen. Sein Beschaffungsprozess ist charakterisiert durch Sofortigkeit, geringen Wert, Mehrfachanbieter, hohe Frequenz und ergebnisorientierte Abwicklung. Die natürlichste Erfahrung für ihn ist daher nicht „erst abonnieren, dann aufrufen“, sondern „Dienst finden, Angebot einholen, Zahlung autorisieren, Ergebnis erhalten.“

Agentenzahlung bedeutet daher nicht einfach, einem Chatbot eine Zahlungsschaltfläche hinzuzufügen. Sie bedeutet, dass Software eine begrenzte Ausgabenbefugnis erhält und einen maschineneigenen Beschaffungsprozess bildet. Menschen definieren Ziele, Budgets und Risikogrenzen; Agenten verteilen Mittel innerhalb dieser Grenzen. Zahlung wandelt sich damit von einer Abrechnungsaktion zu einem Bestandteil des Entscheidungssystems des Agenten.

1. Warum Agentenzahlungen zu einem eigenständigen Feld werden

1.1 Vom Werkzeugaufruf zur wirtschaftlichen Handlung

Der Unterschied zwischen Agenten und gewöhnlichen Automatisierungsskripten liegt nicht nur in der Schlussfolgerungsfähigkeit. Skripte führen vorgegebene Prozesse aus; benötigte Ressourcen und Anbieter sind meist bereits im Code festgelegt; Agenten wählen Pfade basierend auf der Umgebung. Bei derselben Rechercheaufgabe könnte ein Agent zunächst Suchergebnisse kaufen, dann anhand der Ergebnisse entscheiden, ob eine Branchendatenbank nötig ist, und schließlich ein anderes Modell zur Querverifikation aufrufen. Jeder Beschaffungsschritt beeinflusst folgende Entscheidungen.

Dieses „Ausführen während Beschaffen“-Modell bringt wirtschaftliche Entscheidungen in die Software-Laufzeit ein. Ein Agent muss nicht nur prüfen, ob ein Werkzeug verfügbar ist, sondern auch, ob es sich lohnt: ob der Preis das Budget übersteigt, ob die Antwortgeschwindigkeit den Anforderungen genügt, ob die bisherige Erfüllungsquote zuverlässig ist und ob ein alternativer Dienst besser geeignet wäre. Herkömmliches Tool-Routing fokussiert auf Funktionsabgleich, maschinelle Beschaffung muss gleichzeitig Preis und Kontrahentenrisiko berücksichtigen. Bei solchen Transaktionen trägt der Agent selbst das Risiko: Die Zahlung kann erfolgreich sein, doch die Leistung bleibt aus.

Der Kernbedarf bei Agentenzahlungen ist daher nicht unbegrenzte automatische Zahlung, sondern kontrollierte Delegation von Kaufbefugnis an Software. Nutzer werden ihr gesamtes Wallet nicht leicht einem Agenten überlassen, doch sie sind bereit, für eine klare Aufgabe einige Dollar Budget festzulegen und ihm mehrere Cent-Zahlungen zu erlauben. Großvolumige Autorisierungen erfordern möglicherweise langfristiges Vertrauen, doch kleinere Autorisierungen schaffen bereits echten Mehrwert.

1.2 Mikrozahlungen, hohe Frequenz und mehrere Händler verändern die Zahlungsökonomie

Die Zahlungsinfrastruktur des menschlichen Internets eignet sich gut für relativ seltene, höherwertige Transaktionen. Kreditkartennetze, Zahlungsgateways und Abonnement-Systeme weisen feste Kosten auf, weshalb Händler häufig viele Aufrufe in monatliche Pakete bündeln. Bei API-Aufrufen im Wert von nur wenigen Cent können die Gebühren, das Risiko von Rückbuchungen sowie die Kosten für Kontoverwaltung die Werte der Güter selbst übertreffen.

Maschinennutzung ist genau das Gegenteil: Ein Agent kann innerhalb weniger Minuten mehrere Einkäufe bei mehreren Händlern tätigen, um eine einzelne Leistung abzuschließen. Der Betrag pro Transaktion ist sehr gering, doch die Aufruffrequenz ist hoch – und die Gesamtanzahl der Transaktionen kann diejenige menschlicher Nutzer deutlich übersteigen. Stablecoins und programmierbare on-chain-Abrechnung bieten eine neue wirtschaftliche Grundlage für solche Szenarien: Geld fließt rund um die Uhr, Zahlungsfreigaben können softwareseitig signiert werden, und Dienstleistungen lassen sich direkt pro Aufruf abrechnen.

Noch wichtiger: Der Einkauf bei mehreren Händlern wird den Wettbewerb im API-Markt verändern. Abonnementmodelle fördern langfristige Bindung an einen Anbieter, während Pay-per-Use-Agenten dynamische Entscheidungen pro Aufgabe ermöglicht. Dienstanbieter konkurrieren nicht mehr nur um Jahresverträge, sondern auch um kurzfristige Bedarfe. Preis, Performance und Erfüllungsdaten können Routing-Ergebnisse in Echtzeit beeinflussen.

1.3 Stablecoins wandeln sich vom Tauschmittel zur Abrechnungsinfrastruktur

Auf dem frühen Kryptomarkt stammte die Nachfrage nach Stablecoins hauptsächlich aus Handel und Kapitalflucht in sichere Häfen. Mit zunehmender Reife von Ausgabe-, Verwahr-, Compliance- und Cross-Chain-Infrastruktur dringen Stablecoins nun in grenzüberschreitende Abrechnung, Unternehmens-Treasurymangement und internet-native Zahlungen vor. Für Maschinen-Zahlungen bieten Stablecoins zudem einen besonderen Vorteil: Sie sind sowohl Währung als auch digitales Asset, das direkt von Programmen verarbeitet werden kann.

Kreditkartenzahlungen setzen Identität des Karteninhabers, Bankkonten und geografische Netzwerke voraus. Agenten besitzen keine natürliche Personidentität und können klassische Kontoeröffnungsprozesse nicht eigenständig durchlaufen. Eine regelbasierte Wallet hingegen kann als Finanzierungsschnittstelle des Agents fungieren: Der Betreiber lädt ein begrenztes Guthaben ein, legt Höchstbeträge pro Transaktion und pro Sitzung fest und behält Rechte zum Einfrieren oder Widerrufen; der Agent signiert lediglich Zahlungen innerhalb des autorisierten Rahmens.

Dies bedeutet nicht, dass on-chain-Zahlungen grundsätzlich allen traditionellen Zahlungen überlegen sind. Verbraucherschutz, Rückerstattungsmechanismen, Datenschutz, Schlüsselverwaltung und regulatorische Verantwortung müssen weiterhin adressiert werden. Doch bei Maschine-zu-Maschine-Zahlungen, niedrigwertigen Pay-per-Use-Modellen und globaler Dienstbeschaffung bieten programmierbare Stablecoins klare Kompatibilität. Erstmals ermöglichen sie, „eine Schnittstelle aufzurufen“ und „eine Schnittstelle zu bezahlen“, in einer einzigen Netzwerkinteraktion zu vereinen.

2. Zahlungsrails sind bereits entstanden: x402, MPP und HTTP-native Transaktionen

2.1 Von Statuscode 402 zur kommerziellen Schnittstelle

HTTP reservierte vor langer Zeit den Statuscode 402 (Payment Required), doch bildete sich fast 30 Jahre lang kein allgemeiner Workflow daraus. Maschinen-Zahlungsprotokolle haben diese Semantik neu aktiviert: Der Client fordert einen kostenpflichtigen Endpunkt an, der Server antwortet mit 402 und maschinenlesbaren Zahlungsbedingungen; der Client wählt eine akzeptable Option, führt Signatur oder Zahlung durch und wiederholt die Anfrage mit den erforderlichen Berechtigungsnachweisen.

Die Bedeutung dieses Prozesses liegt darin, dass er die manuelle Registrierungsseite eliminiert. Preisermittlung, Zahlungsanforderungen und Inhaltsbereitstellung erfolgen alle auf Protokollebene – verständlich für Programme. Für Entwickler müssen kostenpflichtige APIs nicht mehr ein komplettes SaaS-Portal mit Konten, Tarifen und Keys aufbauen; für Agenten sind Dienste wie gewöhnliche Webseiten auffindbar und bei Bedarf sofort kaufbar.

x402 ist eines der am stärksten beobachteten offenen Protokolle auf diesem Weg. Es strukturiert Zahlungsherausforderungen und -berechtigungen um HTTP 402 herum und ermöglicht es Dienstanbietern, pro Anfrage zu berechnen. MPP hingegen startet aus einem anderen Ökosystem und erforscht maschinenorientierte Zahlungsmethoden wie Charge und Session. Die beiden unterscheiden sich in ihrer konkreten Ausgestaltung, validieren aber gemeinsam eine Richtung: Maschinen-Zahlungen können Teil des Anwendungsprotokolls werden – statt einer separaten, außerhalb der Anwendung implementierten manuellen Abrechnung.

2.2 Langfristige Diversifizierung der Zahlungsrails

Die Branche erwartet oft, dass sich letztlich nur ein Standardprotokoll, ein Abrechnungsnetzwerk und ein Zahlungsverfahren durchsetzen. Doch aus Sicht eines Händlers hat Diversifizierung langfristig Sinn: Einzelabfragen eignen sich für Pay-per-Call, während kontinuierliche Inferenz- oder Streaming-Dienste eher sessionbasierte Abrechnung benötigen; hochwertige Dienste erfordern stärkere Garantien und Streitbeilegung, während niedrigwertige Aufrufe Geschwindigkeit und Kosten priorisieren; verschiedene Regionen und Unternehmen wählen zudem unterschiedliche Compliance- und Abrechnungsnetzwerke.

Die Protokollebene wird weiter innovieren. Händler könnten Lastschriften, Vorautorisierungen, Treuhandkonten, Streaming-Zahlungen oder Sammelabrechnungen nutzen; Netzwerke könnten unterschiedliche Kompromisse zwischen Kosten, Endgültigkeit, Liquidität und Ökosystem-Tools eingehen. Für Verkäufer bedeutet dies Wahlfreiheit. Für Käufer erweitert jede neue Kombination die Integrationsfläche.

Die Konfigurationsmatrix in der folgenden Abbildung zeigt einen Ausschnitt dieser Diversifizierung: Protokolle/Zahlungsverfahren bilden die Spalten, Blockchains die Zeilen; jede Auswahl ist eine Zahlungskonfiguration, die separat integriert werden muss – und diese Tabelle wächst weiter.

Abbildung 1: Zahlungsrail-Konfigurationsmatrix unter Fragmentierung

Fragmentierung wird also nicht zwangsläufig mit der Marktreife verschwinden. Der Kartenzahlungsmarkt mündete nach langjähriger Entwicklung nicht in einer einzigen Kartengesellschaft, und Cloud-Computing konvergierte nicht auf einen einzigen Anbieter. Ausgereifte Märkte eliminieren Unterschiede meist nicht, sondern bauen stattdessen Aggregations-, Routing- und Clearing-Schichten darüber auf. Agent Payments wird wahrscheinlich denselben Evolutionspfad nehmen. Diese Aufspaltung ist bereits messbar: Daten zweier öffentlicher Explorer (x402scan und mppscan) der letzten 30 Tage (Stand 3. September 2026) zeigen: Das MPP-Protokoll verzeichnet 65.591 aktive Käufer-Wallets auf der Tempo-Chain, x402 19.472 auf der Base-Chain; nur 365 Wallets erscheinen auf beiden Rails – weniger als 0,6 % der MPP-Käufer und 2 % der x402-Base-Käufer; davon absolvierten lediglich 112 mehr als zehn Transaktionen auf jeder Rail, und ein beträchtlicher Teil davon sind Dual-Rail-Aggregatoren, die im Namen von Nutzern mit demselben Schlüssel zahlen – nicht Käufer, die selbst eine zweite Zahlungs-Rail nutzen. Käufer wechseln nicht zwischen Rails; jede Rail baut ihre eigene unabhängige Käuferbasis auf.

2.3 Onboarding des Verkäufers ist nur die halbe Transaktion

Zahlungsprotokolle senken zunächst die Hürde für Händler, Zahlungen anzunehmen. Sobald ein Endpunkt Preise veröffentlichen, Berechtigungen verifizieren und Dienstleistungen bereitstellen kann, erfüllt er die Grundvoraussetzungen für maschinenlesbaren Handel. Dadurch werden zunehmend mehr Entwickler-Tools, Datendienste und Inhalts-Schnittstellen maschinenkaufbar.

Doch kaufbare Angebote bedeuten nicht automatisch Nachfrage. Händler lösen das Problem „Wie erhalte ich Zahlungen von Maschinen?“, doch Agenten müssen weiterhin klären: „Von wem kaufe ich? Welche Zahlungsmethode verwende ich? Wie bestätige ich die Lieferung nach der Zahlung?“ Falls jeder Käufer jedes Protokoll einzeln integrieren, Mittel auf verschiedenen Netzwerken bereitstellen und unabhängige Buchhaltungen führen muss, wiederholen maschinelle Zahlungen die Komplexität früher API-Integrationen – nur mit Wallets und Protokoll-Adaptern statt API-Schlüsseln.

Die echte Akzeptanz hängt vom gesamten Transaktionsaufwand ab, nicht nur vom Aufwand beim Settlement.

3. Die eigentliche Engstelle der Branche: Transaktionen haben keine geschlossene Schleife

Abbildung 2: Der vollständige Ablauf einer maschinellen Beschaffung

3.1 Die erste Hürde: Auffinden kaufbarer Dienste

Agenten benötigen maschinenlesbare Dienstverzeichnisse. Ein effektives Verzeichnis darf nicht nur Namen und URLs enthalten; es muss zudem Endpunktfunktionen, Eingaben/Ausgaben, Preis-Einheiten, verfügbare Protokolle, Latenz, geografische Einschränkungen und Aktualisierungsstatus beschreiben. Zudem ist eine Zuordnung zwischen natürlichsprachlicher Absicht und API-Parametern erforderlich; andernfalls weiß ein Agent zwar, dass er „makroökonomische Daten benötigt“, aber nicht, welcher Endpunkt die Aufgabe erfüllt.

Verzeichnisse in offenen Märkten leiden zudem unter Duplikation, Verfall und falschen Angaben. Jeder Händler kann behaupten, hochwertige Daten bereitzustellen – doch Agenten können sich nicht wie menschliche Einkaufsmitarbeiter tagelang mit Hintergrundchecks aufhalten. Die Discovery-Schicht muss kontinuierlich prüfen, ob Endpunkte aufrufbar sind, ob Preise real sind und ob Beschreibungen mit dem gelieferten Inhalt übereinstimmen.

Daher unterscheidet sich Dienst-Discovery vom klassischen Suchen: Suchmaschinen optimieren für Informationsrelevanz, während maschinelle Beschaffungsverzeichnisse zusätzlich für Handelbarkeit optimieren müssen – also ob Funktionen passen, Preise akzeptabel sind, Zahlungen kompatibel sind und Händler liefern können.

3.2 Die zweite Hürde: Verstehen und Vergleichen von Angeboten

Auf den ersten Blick lassen sich ähnliche APIs alle pro Aufruf preisen – doch tatsächlich sind Angebote nur schwer vergleichbar. Ein Anbieter berechnet pro Anfrage, ein anderer pro Ergebniselement; einer inkludiert Modell-Inferenz im Preis, ein anderer verlangt Zusatzgebühren; wieder andere berechnen dynamisch nach Eingabelänge, Laufzeit oder erfolgreichen Ergebnissen.

Ein Agent darf nicht einfach den Endpunkt mit dem niedrigsten Nennpreis wählen. Er muss Gesamtkosten, Lieferwahrscheinlichkeit, Latenz und Ergebnisqualität berücksichtigen. Scheitert eine günstige Schnittstelle wiederholt, können Wiederholungskosten und Aufgabeverzögerungen ihren effektiven Preis erhöhen. Angebote sollten daher gemeinsam mit Service-Level, historischer Leistung und Aufgabenkontext bewertet werden.

Maschinenlesbare Angebote müssen zudem Gültigkeitsdauer und Endbetrag angeben. In dynamischen Preissystemen muss das vom Agenten unterzeichnete Angebot eine verbindliche Zusage sein – kein vager Preiskorridor. Betreiber benötigen zudem Kenntnis der Gebührenstruktur (Dienstgebühren, Netzwerk-Kosten, Routing-Gebühren), um glaubwürdige Budgets festzulegen.

3.3 Das dritte Tor: Mittelverteilung und Liquidität über mehrere Netzwerke

Benötigt ein Agent Dienste gleichzeitig über mehrere Blockchains und Protokolle, liegt es nahe, vorab Guthaben auf jedem Netzwerk zu halten. Doch dadurch wird ein kleiner Kapitalbetrag in viele Einzelbeträge zerstückelt. Mittel liegen brach auf nicht genutzten Netzwerken, während beliebte Netzwerke an Liquidität mangeln; Nachladen erfordert Bridging, Swapping, Gas und Sicherheitsmaßnahmen.

Für einen einzelnen Nutzer ist dies bereits umständlich. Für Unternehmen mit vielen Agenten verstärkt sich das Problem: Wie viel Guthaben soll jeder Agent halten? Wer ist für das Nachladen zuständig? Wie verhindert man Fehlausgaben? Wie aggregiert man Vermögenswerte und Gebühren über verschiedene Netzwerke? Ohne eine einheitliche Finanzierungsschicht steigt die finanzielle Komplexität mit jeder zusätzlichen Zahlungsrail.

Idealerweise sieht ein Agent ein einziges ausgebbares Budget – nicht mehrere Netzwerk-Guthaben. Das zugrundeliegende System wählt Settlement-Pfade, verwaltet Liquidität und liefert transparente Angebote. Das Prinzip entspricht einer Reisekarte: Der Nutzer achtet auf Gesamtkreditlimit und Wechselkurs – nicht auf Vorab-Eröffnung lokaler Konten für jedes Reiseland.

3.4 Das vierte Tor: Richtlinienbasierte Autorisierung

Autonome Zahlungen wecken schnell die Sorge, ein Agent könnte ungehemmt ausgeben. Die Lösung liegt nicht zwischen „vollständigem Verbot“ und „vollständiger Freigabe“, sondern in mehrschichtigen Richtlinien.

Pro-Transaktions-Obergrenzen begrenzen den Schaden eines einzelnen Fehlers, Sitzungsbudgets steuern die Gesamtausgaben einer Aufgabe, Händler-Whitelists oder -Blacklists regeln Gegenparteien, Kategorieregeln beschränken Kaufgegenstände und Rate-Limits verhindern ungewöhnliche Aufrufe in kurzer Zeit. Hochrisiko- oder hochwertige Transaktionen können zudem manuelle Bestätigung erfordern. Richtlinien werden durch Betreiber festgelegt – Agenten dürfen nur innerhalb dieser Grenzen handeln und selbst keine Limits erhöhen.

Eine Wallet sollte nicht nur Signaturen erstellen können. Sie muss mit Aufgaben, Identität und Audit-Protokollen verknüpft werden, um die Fragen zu beantworten: „Welcher Agent hat diese Zahlung für welche Aufgabe und nach welcher Richtlinie genehmigt?“ Andernfalls bleibt dem Unternehmen lediglich eine Folge von On-Chain-Transaktions-Hashes – was internen Kontrollanforderungen und der Kostenzuordnung nicht genügt.

3.5 Stufe fünf: Erfolgreiche Abwicklung ≠ Leistungserbringung

Blockchain eignet sich hervorragend, um zu beweisen, dass Geld von einer Adresse zur anderen übertragen wurde – doch sie kann nicht inherent nachweisen, ob eine API den korrekten Inhalt zurückgab. Eine Transaktion kann abgeschlossen sein, während der Server jedoch zeitüberschreitet, einen Fehlerstatus zurückgibt oder Daten liefert, die nicht der Ankündigung entsprechen. Für Agenten ist dies kein Randfall – sondern das Kernrisiko bei Beschaffung.

Traditioneller E-Commerce verbindet Zahlung und Lieferung über Logistik, Bewertungen und Rückerstattungen; Maschinendienste besitzen keine physische Logistik – die Lieferung kann lediglich eine flüchtige HTTP-Antwort sein. Erfassen Zahlungssysteme nur den Geldfluss und Händler nur ihre eigenen Antworten, fehlt dem Markt eine einheitliche Erfüllungssicht, die Händler und Protokolle gleichermaßen umfasst.

Vorsicht ist geboten: Das Erfassen einer Antwort bedeutet nicht deren Qualität zu beweisen. Doch die Korrelation von Zahlung und Antwort ermöglicht zumindest die Unterscheidung grundlegender Zustände wie „bezahlt und Ergebnis erhalten“, „bezahlt, aber Dienst fehlgeschlagen“ und „nicht abgewickelt“. Dies ist die erste Faktenebene zur Schaffung von Glaubwürdigkeit bei Maschinentransaktionen.

3.6 Stufe sechs: Einheitliche Abstimmung und Verantwortlichkeitszuweisung

Eine einzelne Aufgabe kann Dutzende Mikrokaufakte umfassen. Werden diese Transaktionen über verschiedene Wallets, Protokolle und Händler-Backends verstreut, kann der Nutzer kaum nachvollziehen, warum das Endprodukt diesen Preis hat. Unternehmen müssen zudem Ausgaben Projekten, Teams, Kunden und Kostenstellen zuordnen und nachweisbare Belege aufbewahren.

Ein einheitliches Hauptbuch sollte gleichzeitig Beschaffungsintention, Händler, Angebote, Genehmigungsrichtlinien, Abwicklungsergebnisse, Antwortstatus und Fehlergründe erfassen. Es dient nicht nur der Finanzabteilung, sondern auch der Optimierung von Agenten. So lässt sich analysieren, welche Datenquellen häufig ausfallen, welche Routen teurer sind und welches Beschaffungsprofil sich typischerweise für eine bestimmte Aufgabenart ergibt.

Wenn Zahlung in die Entscheidungskette eingebettet ist, wird Kosten zum Feedback-Signal für Modellentscheidungen. Ohne einheitliche Abstimmung können Agenten lediglich Antworten optimieren – nicht den wirtschaftlichen Prozess ihrer Beschaffung. Ein wesentlicher Teil des langfristigen Werts von Agent Payment resultiert genau aus dieser Observability.

4. Vom Zahlungsprotokoll zur Maschinenbeschaffungsschicht

4.1 Die zentrale Abstraktion der Zukunft ist nicht „zahlen“, sondern „kaufen“

Zahlen ist eine Aktion nach Festlegung von Objekt und Preis; Beschaffung umfasst den gesamten Prozess von der Nachfrage bis zur Annahme. Ein pay()-Aufruf für einen Agenten erlaubt lediglich die Übertragung an eine bekannte Adresse; eine buy()-Funktion hingegen ermöglicht es dem System, Nachfrage entgegenzunehmen, Dienste zu finden, Optionen zu vergleichen, die Zahlung auszuführen und verifizierbare Ergebnisse zurückzugeben.

Diese Unterscheidung bestimmt die Arbeitsteilung in der Branche. Protokolle liefern standardisierte Zahlungsnachrichten, Wallets verwalten Signaturen und Vermögenswerte, Abwicklungsnetzwerke transferieren Wert, Verzeichnisse bündeln Angebot – die Beschaffungsschicht integriert all diese Komponenten zu einer einzigen Aufgabe. Jede Komponente ist wichtig, doch keiner allein repräsentiert eine vollständige Transaktion.

Die Maschinenbeschaffungsschicht muss offen bleiben: Sie darf nicht alle Händler zur Migration auf ein einziges Protokoll zwingen, noch darf sie Kaufberechtigung über ein geschlossenes Verzeichnis festlegen. Ein nachhaltigeres Modell ist die Kompatibilität mit mehreren Zahlungswegen, die Offenlegung von Routingkosten in Angeboten und die autonome Auswahl durch Agenten gemäß Richtlinien.

4.2 Käuferaggregation kann wichtiger sein als Anbieteraggregation

Internetplattformen aggregieren typischerweise zunächst Angebot und ziehen dann Konsumenten an. Auf Maschinenmärkten existiert das Angebot bereits weitgehend als APIs; fehlend ist ein standardisierter Käufer mit kontinuierlichem Kaufvermögen. Ein ausgestatteter Agent wandelt fragmentierte, gelegentliche Nachfrage in einen stabilen Transaktionsstrom um.

Käuferaggregation verbessert zudem die Sichtbarkeit von Langschwanz-Diensten. Menschliche Entwickler nutzen bevorzugt bekannte Großmarken, da die Zeitkosten für die Bewertung neuer Anbieter hoch sind; können Agenten standardisierte Leistungs-, Preis- und Erfüllungssignale lesen, wählen sie für jede Aufgabe den passenden Dienst. Dies senkt möglicherweise die Kundenakquisitionskosten neuer Händler und zwingt etablierte Händler, konkret an Leistung zu konkurrieren.

Doch Käufer-Einstiegspunkte können neue Plattformmacht schaffen. Wer das Standardverzeichnis, die Rangfolge und die Zahlungswege kontrolliert, beeinflusst möglicherweise die Verkehrszuweisung. Die Branche benötigt daher transparente Ranking-Regeln, erklärliche Gebühren und portierbare Transaktionsdaten. Aggregation kann Reibungsverluste senken – doch sie darf offene Protokolle nicht zu geschlossenen Kanälen umverpacken.

4.3 Aufbau von Reputation auf realen Transaktionsdaten

Maschinenkäufer entscheiden sehr schnell und können sich nicht auf aufwändige Due-Diligence-Prozesse stützen. Sie benötigen Gegenparteiensignale bereits beim Eintreffen eines Angebots. Traditionelle Bewertungen und Nutzerrezensionen bieten zwar Orientierung, sind aber leicht durch Scheinvolumen, Sybil-Konten und verwandte Parteien manipulierbar. Ist für Rezensionen keine echte Zahlung erforderlich, ist die Angriffskosten besonders gering. Aktuelle empirische Forschung zu ERC-8004 – der ersten zulassungsfreien On-Chain-Vertrauensebene für Agenten – bestätigt dies [6]. Die Spezifikation lautet wörtlich: „Zahlungen sind orthogonal zu diesem Protokoll“ – Rezensionen müssen per Default nicht an eine echte bezahlte Transaktion gekoppelt sein, der Zahlungsnachweis ist lediglich ein optionales Feld. Das Ergebnis: Auf Ethereum, BSC und Base (Stand 13. Mai 2026) zeigten jeweils 73,5 %, 59,2 % und 90,6 % der Rezensenten koordiniertes Sybil-Verhalten.

Eine zuverlässigere Grundlage bilden Ergebnisdatensätze, die echten bezahlten Aufrufen zugeordnet sind: wie viele Abrechnungen ein Dienst-Endpunkt abgeschlossen hat, welche Erfolgsquote bei Antworten vorliegt, welche durchschnittliche Latenz auftritt und wie hoch der Anteil fehlender Antworten nach Zahlung ist. Diese Metriken können die Inhaltsqualität zwar immer noch nicht vollständig widerspiegeln, liegen aber näher an überprüfbaren Fakten als Selbstdarstellungen.

Mit zunehmendem Datenvolumen könnte sich ein gestuftes Reputationssystem am Markt entwickeln: Die erste Stufe umfasst objektive Transaktionsstatus, die zweite Stufe reproduzierbare Dienstmetriken und die dritte Stufe Qualitätsbewertungen für spezifische Aufgaben. Agenten können je nach Betrag und Risiko die erforderliche Beweiskraft wählen: Für eine Datenabfrage im Cent-Bereich genügen statistische Signale, während bei hochwertigen Beschaffungsvorgängen Garantien, Audits oder Streitbeilegung erforderlich sind.

4.4 Budgetstrategie wird eine wichtige Fähigkeit für Agenten werden

Heute werden Agenten hauptsächlich nach Antwortqualität, Aufgabenerfüllungsrate und Genauigkeit des Tool-Aufrufs bewertet. Sobald sie in bezahlte Umgebungen eintreten, müssen wirtschaftliche Kennzahlen hinzukommen: wie viel ausgegeben wird, um dieselbe Qualität zu erreichen; ob die Aufgabe innerhalb des Budgets erledigt wird; wann es sinnvoll ist, teurere Daten zu kaufen; sowie wie Geschwindigkeit, Kosten und Zuverlässigkeit ausgewogen werden.

Dies eröffnet neue Richtungen für Training und Evaluation. Agenten lernen nicht nur „welches Tool die Frage beantworten kann“, sondern auch „ob der Kauf dieses Tools angesichts des Wertes der aktuellen Aufgabe gerechtfertigt ist“. Sie könnten zunächst kostengünstige Dienste zur Filterung nutzen und dann für Schlussfolgerungen hohe Qualität verifizieren; bei knappem Budget reduzieren sie möglicherweise die Aufrufhäufigkeit oder fordern zusätzliche Nutzerfreigaben an.

In diesem Sinne ist Agent Payment kein externes Finanz-Plugin außerhalb der Modellfähigkeiten, sondern Teil der Entscheidungsintelligenz. Ein wirklich ausgereifter Agent sollte nicht nur Ressourcen nutzen, sondern diese auch bewerten können.

5. Mögliche Entwicklungspfade für Agent Payment

5.1 Phase eins: Entwickler-Tools und digitale Dienste führen den Weg

Die frühesten großflächigen Szenarien werden wahrscheinlich weiterhin rein digitale Lieferungen sein – etwa Suche, Daten, Proxy-Scraping, Modell-Inferenz, Codeausführung, Speicherung und Inhaltsgenerierung. Diese Dienste werden selbst über APIs bereitgestellt, haben geringe marginale Bereitstellungskosten, ermöglichen Zahlung und Antwort innerhalb derselben Netzwerksitzung und erfordern keine komplexe Logistik.

Die typischen Beträge sind in dieser Phase sehr klein; Nutzer legen Wert auf Entwicklungsbequemlichkeit und Aufgabenerfüllungsrate. Der Markt wird Protokolle rasch validieren, doch das Transaktionsvolumen bleibt stark fragmentiert. Viele Aufrufe erfolgen weiterhin über herkömmliche API-Schlüssel und Abonnements, wobei Maschinen-Zahlungen vor allem für temporäre Bedürfnisse, Querhandel zwischen Anbietern und Nischen-Dienste genutzt werden, die nicht im Vorfeld als Konten freigeschaltet werden können.

5.2 Phase zwei: Unternehmensbudgets und Multi-Agenten-Zusammenarbeit

Wenn Unternehmen mehrere Agenten einsetzen, wird das Finanzmanagement von persönlichen Wallets auf organisationsebene Kontosysteme aufgerüstet. Unternehmen müssen Budgets für verschiedene Rollen zuweisen, kaufbare Kategorien steuern, Freigabeschwellen festlegen und Ausgaben in ihre Finanzsysteme buchen. Interne Abrechnungen zwischen Agenten sind ebenfalls möglich: Rechercheagenten kaufen Daten, Analyseagenten Rechenleistung und Ausführungsagenten externe Dienste.

Zu diesem Zeitpunkt gewinnen Sicherheit und Compliance stärker an Gewicht als Zahlungsinnovation. Unternehmen achten auf Schlüsselverwahrung, Berechtigungstrennung, Transaktionsüberwachung, Anbieterprüfung und Audit-Trails. Nur Infrastrukturen, die nahtlos in bestehende Finanzprozesse integrierbar sind, können vom Experimentierstadium in die Produktion übergehen.

5.3 Phase drei: Von digitalen Diensten zur Realwirtschaft

Flugtickets, Hotels, Logistik, Werbung und professionelle Dienstleistungen könnten allesamt Beschaffungsziele für Agenten werden – doch reale Transaktionen erfordern komplexere Identitätsprüfung, Rückerstattungs-, Steuer- und Streitbeilegungsverfahren. Stablecoins lösen lediglich einen Teil des Abrechnungsproblems; sie ersetzen nicht Verbraucherrechte und Handelsverträge.

Daher darf die Branche „autonome Zahlungen“ nicht fälschlich als Eliminierung aller Zwischenhändler verstehen. Vielmehr treten mit steigendem Transaktionswert Garantien, Versicherungen, Kredit und Schiedsverfahren wieder verstärkt auf – sie müssen jedoch in maschinenaufrufbare Dienste transformiert werden. Der zukünftige Agent-Payment-Stack könnte offene Zahlungsprotokolle und traditionelle Finanzanbindungen parallel enthalten, statt dass ein Pfad den anderen ersetzt.

5.4 Phase vier: Von Cross-Protokoll-Routing zu Cross-Market-Execution

Langfristig kaufen Agenten nicht nur eine API-Antwort, sondern ein Ergebnis. Ein Nutzer könnte etwa „Erstelle einen glaubwürdigen Branchenbericht“ anfordern – das System kombiniert autonom Such-, Datenbank-, Übersetzungs-, Modell- und Verifizierungsdienste. Auf unterer Ebene laufen mehrere Transaktionen ab, während der Nutzer nur Gesamtbudget, Quellenbelege und Endauslieferung sieht.

Damit wird Payment Routing zur Marktausführung. Das System muss komplexe Ziele in Beschaffungsportfolios zerlegen, ausgefallene Anbieter dynamisch ersetzen und zwischen Gesamtkosten und Qualität optimieren. Protokollkompatibilität ist lediglich die Grundlage; die eigentliche Wettbewerbsbarriere ergibt sich aus Verständnis der Nachfrage, Transaktionsdaten und Ausführungsfeedback.

6. Risiken und offene Fragen

Agentenzahlungen besitzen enormes kreatives Potenzial, doch reale Einschränkungen dürfen nicht ignoriert werden. Erstens Sicherheit: Prompt-Injektionen könnten Agenten zu schädlichen Dienstleistungen verleiten; Lieferkettenangriffe könnten Empfängeradressen austauschen; fehlerhafte Richtlinien könnten massenhafte Doppelzahlungen verursachen. Zahlungsvorgänge müssen von nicht vertrauenswürdigem Inhalt isoliert sowie mit Limits, Simulation, Widerruf und Anomalieerkennung ausgestattet sein.

Zweitens Datenschutz: Beschaffungsdaten offenbaren, welche Aufgaben ein Agent ausführt; öffentliche Blockchain-Daten könnten Nutzeridentität und kommerzielle Absicht verknüpfen. Systeme müssen sensible Metadaten-Lecks minimieren und einen Ausgleich zwischen Audit-Anforderungen und Privatsphäre finden.

Drittens Haftung: Wer trägt den Verlust bei fehlerhaften Käufen durch einen Agenten, bei Lieferausfällen eines Händlers oder bei gescheiterten Protokollkonvertierungen? Niedrigwertige Transaktionen können automatisiertes Risiko akzeptieren; hochwertige Transaktionen benötigen klare Haftungsgrenzen. Ein Zahlungsnetzwerk ohne Streitbeilegungsmechanismus wird sich schwer im Hochwert-Handel behaupten.

Viertens Regulierung: Stablecoin-Ausgabe, Wallet-Kontrollen, grenzüberschreitende Überweisungen und Händlerzahlungen unterliegen je nach Rechtsgebiet unterschiedlichen Vorschriften. Maschinen sind Ausführende – keine rechtlichen Haftungssubjekte. Die Infrastruktur muss jede autonome Transaktion auf einen klaren Betreiber, eine Autorisierungsrichtlinie und die Mittelherkunft zurückverfolgen können.

Fünftens wirtschaftliche Nachhaltigkeit: Mikrozahlungseinnahmen schmelzen leicht an Netzwerkkosten, Liquidität und Risikosteuerungsgebühren. Subventionieren Plattformen das Erlebnis über versteckte Aufschläge, untergraben sie das Vertrauen der Käufer. Gebühren müssen transparent sein; ein tragfähiges Geschäftsmodell erfordert Skalierung, Routing-Effizienz und Mehrwertdienste.

Diese Herausforderungen entkräften den Sektor nicht; vielmehr zeigen sie, dass Agentenzahlungen nicht allein durch ein einzelnes Protokoll realisiert werden können. Stattdessen entsteht schließlich eine zusammengesetzte Infrastruktur für Zahlungen, Identität, Berechtigungen, Auffindbarkeit, Reputation und Abstimmung.

7. SELAT: Die Kauflseite für maschinennahe Handelsprozesse stärken

„SELAT“ leitet sich vom malaiischen Wort für „Meerenge“ ab – etwa die Straße von Malakka (Selat Melaka). Jahrhundertelang durchquerte der Hauptstrom des Ost-West-Handels diese Wasserstraße – unabhängig vom Herkunftshafen der Waren oder dem Zielmarkt. SELAT zielt darauf ab, diese Meerenge im maschinennahen Handel zu werden: Unabhängig davon, an welcher Zahlungsinfrastruktur ein Händler andockt, kann die Nachfrage von Agenten hier hindurchfließen.

SELAT ist ein KI-native Unternehmen, das den Einstieg in maschinennahe Zahlungen von der Kauflseite her wählt. SELAT bildet die Kauflagen-Schicht für maschinennahe Handelsprozesse. Ihr Kernziel ist nicht die Schaffung einer weiteren Zahlungsinfrastruktur, die Händler zur Migration zwingt, sondern die Möglichkeit für Agenten, Beschaffungsvorgänge über bestehende Infrastrukturen abzuwickeln. Dabei fokussiert SELAT zwei zentrale Probleme: Erstens die Fragmentierung von Zahlungskonfigurationen – da Infrastrukturen, Protokolle, Blockchains und Zugangsdaten variieren, ist pro Händler jeweils eine neue Integration erforderlich; zweitens das Fehlen einer Messung des Gegenparteirisikos, denn erfolgreiche Abwicklung bedeutet nicht zwangsläufig, dass die Leistung erbracht wurde.

Abbildung 3: Schematische Darstellung der SELAT-Kauflagen-Schicht

Um Fragmentierung zu begegnen, hält die SELAT-CLI Unterschiede bei Protokollen, Zahlungssystemen und Abrechnungsnetzwerken auf der Infrastrukturebene – so können Agenten mittels eines einzigen Befehls querschnittlich beschaffen. Auffindbarkeit, Angebotserstellung, Autorisierung, Zahlung, Lieferstatusaufzeichnung und Abstimmung sind in denselben Beschaffungsprozess integriert; jeder Aufruf wird zudem im selben Ledger protokolliert.

• Ein Treasury, nutzt N Zahlungsinfrastrukturen

Agenten halten ein selbstverwaltetes USDC-Guthaben – ohne Vorfinanzierung pro Blockchain oder unterschiedliche Clients für verschiedene Protokolle.

• Aggregierter Endpunkt-Katalog

Die SELAT-CLI integriert vier externe Diensteregister – Circle, MPP, Apify und pay.sh – sowie SELATs eigenen Katalog, sodass Agenten über 4.000 Service-Endpunkte basierend auf aktuellem Bedarf vergleichen und auffinden können.

• Strenge Ausgabenobergrenzen

Operatoren können pro Transaktion Obergrenzen und Sitzungsbudgets festlegen sowie Ausgabenberechtigungen jederzeit einfrieren; Agenten können Grenzen nicht selbst erhöhen.

• Keine Händlermigration erforderlich

Händler behalten ihre bevorzugte Zahlungsinfrastruktur und können von Agenten entdeckt sowie gekauft werden – ohne erneute Registrierung bei SELAT.

Auf der Finanzierungsseite arbeitet SELAT mit beliebigen Agent-Wallets zusammen, darunter Circle- und MetaMask-Agent-Wallets. SELAT leitet jeden Kauf über Zahlungsinfrastrukturen wie x402 und MPP weiter – basierend auf Echtzeit-Preisen.

7.1 ERC-8004: Richtige Primitiven, fragwürdige Signale

ERC-8004 definiert drei Registry-Typen – Identität, Reputation und Validierung – und erlaubt Käufern, Bewertungen an Verkäufer zu senden. Die Zielrichtung ist richtig, doch die Spezifikation trennt Zahlung und Reputation explizit: Feedback muss nicht aus echten Transaktionen stammen, und der Nachweis einer Zahlung ist optional.

Empirische Untersuchungen des eingesetzten Ökosystems zeigen, dass auf Base 93,8 % der Rezensenten niemals eine x402-Zahlung getätigt hatten, aber 94,9 % des Feedbacks beisteuerten; zudem weist ein Großteil des Feedbacks koordiniertes Sybil-Verhalten auf [6]. Registries erfassen Behauptungen, doch Käufer benötigen tatsächlich Ergebnisse.

7.2 Reputation, verknüpft mit echten Transaktionsdaten, ist das, was Käufer brauchen

Zahlungsinfrastrukturen können bestätigen, ob Gelder beglichen wurden, sehen aber nicht, welche Leistung erbracht wurde; Händler sehen nur ihre eigenen Antworten, nicht den gesamten Markt; Registries listen Endpunkte auf, können aber nicht beweisen, dass Bewertungen aus echten Käufen stammen.

Die Kaufer-Schicht, die Einkäufe ausführt, ist am besten positioniert, beide Transaktionsenden zu verbinden: Jeder über SELAT abgeschlossene Kauf protokolliert, welcher Endpunkt bezahlt wurde, welcher Betrag beglichen wurde und Metadaten zum Lieferstatus nach der Zahlung (2xx, 4xx, 5xx). Diese Einträge sammeln sich kontinuierlich nach Händler und Zahlungsinfrastruktur und bilden die Datenbasis des „Abrechnungs–Liefergraphen“.

Eine präzise Unterscheidung ist nötig: Aufzeichnungen, die Zahlung und Lieferstatus verknüpfen, sind nicht gleichbedeutend mit unabhängiger Nachweisführung zur Lieferqualität oder Preisgenauigkeit. Doch sie liefern die Grundlage, die registrybasierte Reputation vermissen lässt – Ergebnisdaten, verknüpft mit realen bezahlten Aufrufen.

7.3 Glaubwürdigkeit der Gegenpartei vor Transaktionen ermitteln

Während Menschen auf X diskutierten, wie man einen Google PageRank-ähnlichen Vertrauensmechanismus für das Internet der vierten Generation entwerfen könnte, hatte SELAT bereits den „Transactability Index“ auf seinem Abrechnungs–Liefergraphen gestartet, um Agenten Laufzeitzugriff auf Gegenpartei-Glaubwürdigkeitsdaten zu ermöglichen – gestützt auf reale Transaktionsergebnisse.

Der Index wird zusammen mit Angeboten zurückgegeben, ohne dass Agenten ihre Aufgaben unterbrechen und Händler separat recherchieren müssten. Er kennzeichnet Risiken, ohne Marktzugänge einzurichten: Endpunkte bleiben auffindbar und kaufbar, und Agenten entscheiden basierend auf Budget, Aufgabenwichtigkeit und Risikopräferenz.

Agenten haben keine Zeit, Markengeschichten zu lesen. Vor der Zahlung müssen sie wissen: Wie performt dieser Endpunkt in echten Transaktionen? Glaubwürdigkeit im maschinennativen Handel darf nicht aus Behauptungen, sondern muss aus Ergebnissen erwachsen.

Abbildung 3: Transactability-Signale in der Angebotsphase

Derzeit wurde die SELAT-CLI für Agent-Laufzeitumgebungen wie Claude Code, Codex, Cursor, Gemini CLI, OpenClaw, Hermes und Grok Bot angepasst.

8. Zusammenfassung: Die Maschinenwirtschaft braucht mehr als nur schnellere Zahlungsinfrastrukturen

Agenten-Zahlungen befinden sich in einer Phase, in der sie leicht überschätzt oder unterschätzt werden. Sie werden leicht überschätzt, weil die technische Durchführung einer Stablecoin-Zahlung nicht bedeutet, dass ein Agent über reife kommerzielle Autonomie verfügt; sie werden leicht unterschätzt, weil sich bei der Fähigkeit von Software, externe Leistungen unter klaren Randbedingungen zu kaufen, Organisationsformen, Preisgestaltungen und Wettbewerbsgrenzen der Maschinenwirtschaft grundlegend ändern werden.

Zahlungsprotokolle haben bereits bewiesen, dass Maschinen Angebote empfangen und Abrechnungen abschließen können. Der nächste entscheidende Schritt ist die Ausweitung einer isolierten Zahlung zu einem vollständigen Beschaffungsprozess: Agenten sollen geeignete Dienste finden, echte Kosten verstehen, innerhalb ihres Budgets über verschiedene Zahlungsinfrastrukturen zahlen, die Lieferung bestätigen und jede Transaktion in eine auditierbare, lernfähige Aufzeichnung verwandeln können.

Die zukünftige Maschinenwirtschaft wird nicht nur eine Blockchain, ein Protokoll oder eine Wallet haben. Mehrquellige Versorgung wird langfristig bestehen bleiben, und wirklich wertvolle Infrastruktur wird Käufern helfen, diese Komplexität zu navigieren. Agenten-Zahlungen müssen Zahlungsinfrastrukturen, Versorgung, Standardzahlungen und Vertrauensmechanismen kombinieren, um technische Kapazität in echte Nachfrage umzusetzen.

Wenn Software beginnt, als Käufer zu handeln, ist die Zahlung nur der erste Schritt. Die wichtigere Frage lautet stets: Kann sie eine tatsächlich nützliche Transaktion auf kontrollierbare, transparente und verifizierbare Weise abschließen?

Literaturverzeichnis

[1] Circle, „Aufbau der offenen agierenden Wirtschaft“, 2026. https://www.circle.com/blog/building-the-open-agentic-economy

[2] SELAT, „Gegenparteirisiko bei agentenbasierten Zahlungen: Die ungemessene Hälfte“, 2026. https://selat.ai/insights/counterparty-risk-agentic-payments

[3] Google Cloud, „KI-basierten Handel mit dem neuen Agent Payments Protocol (AP2) vorantreiben“, 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[4] x402 Foundation, „x402: Ein offener, internet-native Zahlungsstandard.“ https://github.com/x402-foundation/x402

[5] Machine Payments Protocol, „MPP: Ein maschinengestütztes Zahlungsprotokoll basierend auf HTTP 402.“ https://mpp.dev/

[6] Xiong et al., „Können vertrauenslose Agenten vertraut werden? Eine empirische Untersuchung des dezentralen KI-Agenten-Ökosystems ERC-8004“, arXiv, 2026. https://arxiv.org/abs/2606.26028

[7] Offizielle Website von SELAT: https://www.selat.ai

Dieser Artikel wurde eingereicht und stellt nicht die Ansichten von BlockBeats dar.