SOLANA·HUB
EN
Infrastruktur

Payment Channels und die x402-Sammelabrechnung sind auf Solana verfügbar

Am 7. Oktober sind x402-Sammelzahlungen auf Solana über PayAI und BlockRun verfügbar. Ein Agent hinterlegt einen Höchstbetrag, autorisiert per Signatur und rechnet gesammelt ab. Die Rate von über 1 Million pro Sekunde stammt aus einem Proxy-Test.

SOLANA·HUB Redaktion
Quelle: Solana

Was passiert ist

Solana hat am 7. Oktober um 5:45 Uhr MESZ auf X gemeldet, dass Sammelzahlungen für x402 auf Solana verfügbar sind. Der Post nennt PayAI und BlockRun. Solana beschreibt den Ablauf so: Ein Agent öffnet einen Payment Channel, zahlt so oft wie nötig und rechnet einmal über x402 ab.

Die Payment Channels, auf denen diese Abrechnung aufsetzt, sind älter. Die Solana Foundation beschreibt sie in einem Beitrag vom 3. September. Neu an diesem Morgen ist die Meldung, dass die Sammelabrechnung mit PayAI und BlockRun läuft.

BlockRun hatte um 3:59 Uhr MESZ geschrieben, die Sammelabrechnung mit PayAI und der Solana Foundation auf Solana ausgeliefert zu haben. Laut BlockRun lassen sich mehrere Modellaufrufe mit einer USDC-Transaktion bezahlen. In der Grafik zu diesem Post stehen die Zeilen „10x Lower Latency“ und „Save $20K+ /mo in Gas Fees“, also eine zehnmal geringere Latenz und mehr als 20.000 US-Dollar weniger Netzgebühren im Monat. Das sind Angaben von BlockRun, kein geprüfter Vergleich.

x402 ist das Protokoll, in dem ein Dienst auf einen Aufruf ohne Zahlung mit dem HTTP-Status 402 antwortet und der Aufrufer eine Zahlung nachreicht. Den Ablauf pro Aufruf erklärt KI-Agenten auf Solana: x402. Der Statuscode bleibt. Was sich ändert, ist die Bündelung: Viele Autorisierungen laufen in weniger Transaktionen zusammen.

Wie ein Payment Channel funktioniert

Ein Agent hinterlegt einmal einen Höchstbetrag in einem On-Chain-Escrow. Das Programm hält das Guthaben, nicht der Betreiber der API. Danach autorisiert der Agent jede Nutzung mit einer Signatur, nicht mit einer eigenen Transaktion. Das Programm hält den verbrauchten Betrag in einer Transaktion fest. Die Empfänger erhalten ihren Anteil. Der nicht genutzte Rest geht an die Wallet zurück, die eingezahlt hat.

Die Foundation vergleicht das mit einer offenen Rechnung in einer Bar oder mit einem vorausbezahlten Zähler. Man hinterlegt Geld, nutzt den Dienst, ohne jeden Vorgang einzeln zu bezahlen, und rechnet einmal ab. Der hinterlegte Betrag ist die Obergrenze. Man zahlt, was verbraucht wurde.

Auf pay.sh ergänzt die Foundation: Der Betreiber kann die Netzgebühr für das Öffnen und das Abrechnen übernehmen. Der Zahler braucht dann den Stablecoin, nicht SOL.

Drei Schemata sitzen auf demselben Programm:

  • x402 „upto“: ein Deckel für einen einzelnen gemessenen Aufruf. Der Betreiber rechnet den tatsächlichen Betrag ab, die Differenz geht zurück.
  • x402 „batch-settlement“: viele Lieferungen, gemeinsam abgerechnet. Die Foundation benennt dieses Schema in dem Beitrag vom 3. September. PayAI dokumentiert es, und die Posts vom 7. Oktober meinen diese Sammelabrechnung.
  • MPP „session“: ein Kanal für viele Lieferungen in einem Strom. Jede Lieferung läuft über einen kumulativen Beleg. Der Kanal rechnet einmal ab, wenn die Sitzung im Leerlauf endet.

Das Programm ist quelloffen, die Lizenz ist MIT. Laut Repository läuft es auf dem Mainnet unter der Adresse CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX. Diese Adresse ist auf dem Mainnet ein ausführbares Programm. Im Repository verlinkt die Foundation einen Sicherheitsbericht von Cantina vom Juli 2026.

Solana formuliert das als einmalige Abrechnung. PayAI beschreibt den Betrieb genauer. Der Anbieter soll Belege in kurzen Abständen einziehen, in der Dokumentation zum Beispiel alle 10 bis 60 Sekunden, und das gerade Fällige auszahlen. So entstehen weniger Transaktionen als Aufrufe. Die Dokumentation legt nicht fest, dass ein Kanal über die ganze Laufzeit bei genau einer Transaktion bleibt. PayAI speichert unbeanspruchte Belege nicht für den Anbieter. Wer selten einzieht, kann nach dieser Beschreibung Umsatz verlieren. Ist der Kanal abgeschlossen, geht der nicht genutzte Rest laut Repository sofort zurück. Erzwingt der Einzahler das Schließen, nennt PayAI eine Wartezeit von 15 Minuten bis 24 Stunden.

Warum das für Agenten und bezahlte APIs zählt

Zwei Muster passen schlecht zu einer eigenen Transaktion pro Aufruf. Erstens Aufrufe, deren Preis erst hinterher feststeht, etwa ein Sprachmodell, das pro Token abrechnet, oder ein Auftrag pro Byte oder pro Rechensekunde. Zweitens viele kleine Lieferungen, etwa eine Antwort Token für Token oder ein Stoß aus Hunderten günstigen Aufrufen. Ein Payment Channel reduziert die On-Chain-Arbeit auf ein Öffnen und ein Abrechnen, unabhängig davon, wie oft dazwischen gemessen wird.

Die Foundation nennt drei Folgen der Abrechnung pro Aufruf. Ein Mensch muss Zahlungen einzeln freigeben. Jede Zahlung trägt Kosten und Latenz. Laut Foundation verlässt vorausbezahltes Guthaben mit dem ersten Aufruf die eigene Wallet und wird in einer fremden Datenbank geführt. Beim Payment Channel setzt man einen Deckel, der Agent gibt dagegen aus, und das Guthaben bleibt im Programm.

Was der Test misst

Im Beitrag vom 3. September schreibt die Foundation von einem Test mit 100.000 unterschiedlichen Wallets über einen Payment-Channel-Proxy und mehr als 1 Million Zahlungen pro Sekunde. Sie nennt das genug Kapazität für mehr als 80 Milliarden Zahlungen in 24 Stunden. Die geschätzten Verarbeitungskosten gibt sie mit 0,000000000776 US-Dollar je Zahlung an.

Das ist ein Test über einen Proxy. Die Foundation beschreibt ihn selbst so. Es ist keine gemessene Zahl von Transaktionen, die das Solana-Netz in dieser Höhe verarbeitet hat. Wer den Test nachbauen will, findet bei der Foundation eine quelloffene Vorlage und Werkzeuge für den Lasttest.

Grenzen der PayAI-Vorschau

PayAI betreibt den Facilitator, den Dienst, der Prüfung und Abrechnung für das Schema einreicht. Die Pakete @x402/core und @x402/svm stammen laut PayAI ab Version 2.28.0 aus dem Repository der x402 Foundation. PayAI gibt sie nicht selbst heraus.

PayAI nennt die Unterstützung eine öffentliche Vorschau. Wer den öffentlichen Zugang nutzt, braucht kein PayAI-Konto und keinen API-Schlüssel. Neue Kanäle nehmen eine Einzahlung von 0,01 bis 100 USDC auf dem Solana-Mainnet an. Die Obergrenze liegt bei 10 offenen oder schließenden Kanälen pro Anbieter. Hat der Anbieter ein Konto, teilen sich seine API-Schlüssel dieses Kontingent. Ohne Konto zählt PayAI die Kanäle pro Empfangsadresse auf Solana. Laufende Reservierungen zählen mit. Im ganzen Dienst sponsert PayAI höchstens 1.000 Kanäle, offene, schließende und reservierte zusammen. Die Zulassung neuer Kanäle kann pausieren, wenn Kapazität oder das Guthaben für die übernommenen Gebühren fehlt. Die geltenden Werte liefert der Endpunkt „/supported“.

Alibaba Cloud im Beitrag vom September

Im Beitrag vom 3. September nennt die Foundation Alibaba Cloud als Partner zum Start der Payment Channels. Laut dem Beitrag waren die API-Endpunkte an diesem Tag erreichbar. Ein Agent autorisiert einmal und ruft die Schnittstellen ohne eigenes Konto und ohne Freigabe pro Aufruf auf. Die Posts vom 7. Oktober nennen Alibaba Cloud nicht. Ob die Endpunkte am 8. Oktober noch erreichbar sind, steht dort nicht.

Hinweis: Dies ist Berichterstattung, keine Anlageberatung.

Was zu beobachten ist

  • Ob PayAI die Grenzen der öffentlichen Vorschau ändert oder neue Kanäle zeitweise nicht mehr annimmt
  • Ob die Foundation oder Alibaba Cloud den Stand der genannten API-Endpunkte nach dem 3. September aktualisiert

Quellen

#x402 #payments #ai-agents #payai #usdc

Verwandte Artikel