Analyse · Bitcoin
x402 lässt KI-Agenten per Lightning nur in Vorkasse zahlen
Die Spezifikation sieht keinen Rückerstattungsweg vor, der Zahler trägt die Routinggebühren. Block beansprucht den Beitrag, ein Dokument für den XRP Ledger fehlt im Standard bislang.
Phil7 Min. Lesezeit

Stand 25. September 2026 führt der Zahlungsstandard x402 acht netzwerkspezifische Dokumente, und eines davon regelt, wie KI-Agenten mit Bitcoin über das Lightning-Netz bezahlen. Die Regeln verlangen viel vom Zahler: Das Geld fließt vorab, bevor der Server die Anfrage bearbeitet, und einen Rückerstattungsweg sieht das Lightning-Schema nicht vor. Block gibt an, diese Lightning-Zahlungen zu x402 beigesteuert zu haben.
Die Spezifikation mit dem Kürzel lnbtc liegt in der Fassung von Commit 6fe0d4b im x402-Repository auf GitHub. Lightning kommt damit als Vorkasse in den Standard: genau beschrieben, mit den Folgen beim Zahler. Für dich als XRP-Halter zählt das doppelt, denn Ripple hat für denselben Standard Unterstützung auf dem XRP Ledger erklärt, ein eigenes Dokument in der Liste hat bisher aber Lightning bekommen.
Der Preis: Zahlung vor Leistung, Gebühren obendrauf, Erstattung nur beim Empfänger
Im allgemeinen exact-Schema von x402 ist ein anderer Ablauf Standard. Bei authorization wird die Zahlung vor der Leistung geprüft und erst danach verbucht; scheitert die Verarbeitung auf dem Server, bleibt der Zahler unbelastet. Für Lightning ist upfront der einzige Ablauf, und dort bleibt der zahlende Agent in diesem Fall belastet und geht leer aus.
Für diesen Fall verweist das Lightning-Schema an den Empfänger: Eine Rückzahlung ist allenfalls eine eigene Vereinbarung mit ihm, und Zahler dürfen nicht von einer Erstattung ausgehen. Unvollständige oder fehlgeschlagene Zahlungen laufen über die übliche Lightning-Fehlerbehandlung.
Dazu kommen die Routinggebühren, die der Zahler zusätzlich zum Rechnungsbetrag trägt. Ihre Höhe lässt die Spezifikation offen; dass Lightning-Zahlungen günstig sind, bleibt bis zu belastbaren Messungen die Einschätzung von Block.
Für den Facilitator, den Dienst, der für den Server die Zahlungsnachweise prüft, gilt eine Datenregel: Er muss das Feld payer in seiner Abrechnungsantwort weglassen und darf die Zahleridentität auch nicht aus payTo oder dem Rechnungsempfänger ableiten. Die Begründung der Spezifikation: Lightning-Routing legt keine stabile Zahleridentität offen.
Auf der Empfängerseite verlangt die Spezifikation Exklusivität. Der Ressourcenserver, also der Anbieter der kostenpflichtigen Leistung, muss für seinen Empfängerschlüssel allein Rechnungen ausstellen dürfen; ein geteilter, verwahrter Lightning-Knoten, auf dem ein nicht vertrauenswürdiger Mandant Rechnungen unter demselben Knotenschlüssel erzeugen kann, ist nicht kompatibel.
Rechnung, Nachweis, Prüfung: So zahlt ein Agent mit Lightning
Den Ablauf regelt die Lightning-Spezifikation scheme_exact_lnbtc.md. Der Client, etwa ein KI-Agent, bezahlt eine frische BOLT11-Rechnung des Ressourcenservers; BOLT11 ist das Rechnungsformat des Lightning-Netzes.
Als Nachweis reicht der Client das 32-Byte-Preimage ein, einen geheimen Wert, den er erst mit der erfolgreichen Zahlung erhält. Der Facilitator prüft lokal, ob der SHA-256-Hash dieses Werts dem Payment-Hash der Rechnung entspricht und ob der Signaturschlüssel der Rechnung zum Empfänger in payTo passt. Das geht ohne Zugriff auf den Lightning-Knoten des Empfängers.
Jede Rechnung ist über ihren signierten Beschreibungs-Hash an genau eine Anfrage gebunden. Vorgesehen sind zwei Profile: http:1 für gewöhnliche HTTP-Anfragen und mcp:1 für Toolaufrufe über das Model Context Protocol (MCP), mit dem KI-Agenten externe Werkzeuge ansprechen.
Bezahlt wird ausschließlich in BTC, auf dem Bitcoin-Mainnet (lnbtc:000000000019d6689c085ae165831e93) oder dem Bitcoin-Testnet (lnbtc:000000000933ea01ad0ee984209779ba).
Beträge stehen als Zeichenkette einer positiven ganzen Zahl in Millisatoshi, also Tausendsteln eines Satoshi: 21 Satoshi werden als „21000“ geschrieben.
Beim abschließenden Settlement ist die Lightning-Zahlung bereits abgeschlossen, der Facilitator bewegt kein Geld mehr. Seine Aufgabe ist die Kontrolle: Er trägt jeden Nachweis in einen neustartfesten Replay-Speicher ein, damit er sich nur einmal einlösen lässt.
Die Reihenfolge steht fest. Das Schema lässt nur die Übertragungsmethode bolt11 und nur den Ablauf upfront zu: Die Zahlung ist abgeschlossen, bevor der Server die Anfrage bearbeitet, und er arbeitet erst nach erfolgreichem /settle.
Diese Regeln stammen aus der Fassung von Commit 6fe0d4b, mit dem scheme_exact_lnbtc.md in die Liste der netzwerkspezifischen Dokumente von scheme_exact.md aufgenommen wurde; auf main steht der Eintrag am 25. September 2026 weiterhin. Sie beschreiben, was jede Umsetzung erfüllen muss.
Block tritt bei: was das Unternehmen erklärt und wer hinter x402 steht
Seinen Beitritt zur x402 Foundation hat Block am 24. September 2026 in einem Beitrag auf X erklärt, Cointelegraph berichtet dasselbe unter Berufung auf die Mitteilung des Unternehmens. Eine Bestätigung durch die Foundation steht aus; bis dahin ist der Beitritt eine Angabe von Block.

Die Begründung liefert Block mit: Lightning sei auf sofortige, günstige Zahlungen in hoher Stückzahl ausgelegt, heißt es in dem X-Post. Laut Cointelegraph verknüpft Block das mit dem Agentenhandel, der auf solche Zahlungen angewiesen sein werde.
Steve Lee, laut Cointelegraph Leiter von Spiral, der Bitcoin-Initiative von Block, wird dort so zitiert:
Bringing Lightning to x402 is a concrete step toward making Bitcoin everyday money for people and the agents acting on their behalf, and we’re excited to help the industry build on it.
Übersetzt: Lightning in x402 sei ein konkreter Schritt, Bitcoin zu Alltagsgeld für Menschen und für die Agenten zu machen, die in ihrem Auftrag handeln; man freue sich, der Branche beim Aufbau darauf zu helfen.
Die Foundation selbst ist jung. Am 2. April 2026 kündigte die Linux Foundation an, die x402 Foundation zu starten, verbunden mit der Übergabe des x402-Protokolls, das Coinbase geschaffen hatte.
Den operativen Start und den abgeschlossenen Beitrag des Protokolls durch Coinbase meldete die Linux Foundation am 14. Juli 2026. Wenn Cointelegraph schreibt, die Foundation sei im April gestartet, fasst das Ankündigung und Start zu einem Schritt zusammen.
Laut Linux Foundation waren zum 14. Juli 2026 seit der Absichtserklärung im April 40 Organisationen als Mitglieder beigetreten, darunter 17 Premier- und 18 General-Mitglieder. Die Liste stammt aus der Zeit vor Blocks Mitteilung.
Wie breit die Foundation aufgestellt ist, zeigt dieselbe Liste: Google, Amazon Web Services, Coinbase und die Solana Foundation sind dort Premier-Mitglieder. Cointelegraph nennt außerdem Microsoft; das Unternehmen stand im April 2026 unter den Unterstützern der Ankündigung, in der Liste vom Juli fehlt es. Die Mitgliedschaften gelten der Foundation als Ganzes.
Wo der XRP Ledger in x402 steht
Ripple hat sich schon im Juli positioniert. Markus Infanger, Senior Vice President von RippleX, sagte am 14. Juli 2026 in der Mitteilung der Linux Foundation, Ripples x402-Unterstützung auf dem XRP Ledger ermögliche Agenten Zahlungen mit XRP und RLUSD. Den technischen Hintergrund beschreibt der Artikel über den XRP Ledger für KI-Agenten vom 19. September 2026, die Grundlagen stehen auf der Seite XRP und KI-Zahlungen.
Die Datei scheme_exact.md verweist am 25. September 2026 auf acht netzwerkspezifische Dokumente: Solana, Stellar, EVM, SUI, TON, Starknet, Bitcoin Lightning und Hedera. Lightning hat damit einen eigenen Platz in der Spezifikation, ein Dokument für den XRP Ledger steht noch aus.
Liste und Ripples Angabe beschreiben verschiedene Dinge. Die Liste zeigt, welche Netze ein eigenes Dokument im Standard haben; Ripples Angabe betrifft die eigene Unterstützung auf dem XRP Ledger. Lightning ist als eines von acht Netzen neben die bestehenden getreten. Für dich als XRP-Halter ist die Größe zum Beobachten, ob der XRP Ledger ein eigenes Dokument bekommt.
Ob Lightning in x402 ankommt, zeigen SDKs, Facilitatoren, Wallets und die Mitgliederliste
Ob aus der Spezifikation Zahlungsverkehr wird, erkennst du zuerst an Software: an SDKs, Facilitatoren oder Wallets, die lnbtc ausdrücklich umsetzen. Das zweite Zeichen ist eine Mitgliederliste der x402 Foundation, die Block führt.
Das Netz dafür hat eine messbare Größe: 1ML wies am 25. September 2026 eine Kapazität von 266.029.841.662 Satoshi aus, rund 2.660,30 BTC. Kapazität meint die in Zahlungskanälen gebundenen Bitcoin, also die Größe des Netzes.
In den 30 Tagen vor dem 25. September 2026 ist diese Kapazität laut 1ML um 1,71 Prozent gesunken; ob das Netz wächst oder schrumpft, zeigt erst der Verlauf über weitere Monate.
Unterm Strich hat Lightning in x402 eine ausformulierte Spezifikation, für die Block den Beitrag beansprucht. Wer als Agent so bezahlt, zahlt vorab, trägt die Routinggebühren und ist bei einer Erstattung auf den Empfänger angewiesen. Bis zum 25. September 2026 ist keine Umsetzung von lnbtc belegt, und wer Commit 6fe0d4b verfasst hat, ist offen. Die Antwort auf die Frage, ob KI-Agenten jetzt mit Lightning bezahlen können, lautet damit: spezifiziert, aber noch nicht nachweislich in Betrieb.
* Werbehinweis: Dieser Artikel enthält eine gekennzeichnete Partner-Empfehlung (Bitvavo). CryptoTuts kann bei Vertragsabschluss über diesen Link eine Provision erhalten; das ändert nichts an der redaktionellen Einschätzung. Mehr erfahren
Quellen
- Cointelegraph: Block brings Bitcoin Lightning payments to x402 for AI agents · Cointelegraph
- X-Post @blocks zum Beitritt zur x402 Foundation (24.09.2026) · Block
- GitHub x402-foundation/x402: Commit 6fe0d4b · x402 Foundation (GitHub)
- x402-Spezifikation: scheme_exact_lnbtc.md (Bitcoin Lightning), Stand Commit 6fe0d4b · x402 Foundation (GitHub)
- x402-Spezifikation: scheme_exact.md · x402 Foundation (GitHub)
- Linux Foundation: Launching the x402 Foundation (02.04.2026) · Linux Foundation
- Linux Foundation: Operational Launch of x402 Foundation (14.07.2026) · Linux Foundation
- 1ML: Lightning Network Statistics · 1ML
Nächster Schritt · XRPL
Die technische Entwicklung weiterverfolgen
Für den aktuellen Stand des XRP Ledgers führt der nächste sinnvolle Schritt zu den laufenden XRPL-Amendments.



