Die Aufgabe – und ihre Grenze
L402 verbindet Lightning-Zahlungen mit authentifiziertem Zugriff auf APIs. Es ist nicht erst für KI-Agenten entstanden, kann aber maschinell konsumierte Leistungen abrechenbar machen. Der Einsatz setzt eine passende Lightning-Infrastruktur und eine bewusste Behandlung von Zahlungs- und Zugriffsrechten voraus.
Nicht dafür gedacht: Kein vollständiges Commerce-Protokoll und keine automatische Alternative zu jedem bestehenden Zahlungsweg.
Wie es sich in den Stack einfügt
- Vergleichbarer Anwendungsraum wie x402 und MPP bei bezahlten API-Ressourcen.
- Aperture ist ein Implementierungsbaustein aus dem Lightning-Labs-Ökosystem, nicht die Spezifikation selbst.
Release und Arbeitsfassung getrennt
- Veröffentlichter Stand
- Keine eigenständige Releaseversion verifiziert
- Arbeitsfassung
- Kein separater Draft hier ausgewiesen
L402sdk README und Changelog widersprechen sich zur Veröffentlichung: 0.1.0 vom 16. März 2026 wird als noch unveröffentlichtes Entwicklungsrelease bezeichnet.
- Lizenz / Bedingungen
- L402sdk: MIT OR Apache-2.0; Lizenz des Spec-Repositories hier nicht abschließend festgestellt.
Originalbedingungen prüfen ↗ - Quellenprüfung
- · Kein Installations- oder Konformitätstest
Ein konkreter Ablauf
Die Schritte ordnen die Rolle des Protokolls ein. Sie sind kein ausführbarer oder getesteter Quickstart.
- Eine API-Ressource fordert den vorgesehenen Zahlungs- und Zugriffsnachweis.
- Der Client bezahlt über den unterstützten Lightning-Weg und erhält nutzbare Zugangsdaten.
- Der Dienst prüft den Nachweis und liefert die freigegebene Ressource.
SDKs und Implementierungswege
Die Einträge unterscheiden Bibliotheken, Modelle und Beispiele. Paketnamen sind Upstream-Einstiege, keine hier getesteten Installationsempfehlungen. Prüfen Sie vor der Integration die exakte Version und deren Spezifikationsunterstützung.
L402sdk
Artefakt: Rust-SDK mit TypeScript-/Python-Bindings
Paket / Modul: L402sdk; konkrete Registry-Artefakte vor Nutzung prüfen
Version & Kompatibilität: Changelog 0.1.0, 16. März 2026: Entwicklungsrelease
Veröffentlichung auf crates.io/npm nicht verifiziert; keine „fertig veröffentlicht“-Behauptung.
Was für den Betrieb offen bleibt
- README-Installbefehle sind bei widersprüchlichem Changelog kein ausreichender Beleg für ein Registry-Release.
- Rechteumfang, Aufbewahrung und Wiederverwendung der Zugangsnachweise sowie Rückerstattungsregeln separat betrachten.
Eine offene Spezifikation erteilt keine automatische Erlaubnis für Zahlungen oder Verkaufskanäle. Testmodus, Benutzerfreigabe und Produktionszulassung bleiben eigene Schritte.
Originalquellen
Redaktioneller Stand: . Ein Versionsstand gilt für die genannte Spezifikation oder Bibliothek, nicht automatisch für andere Sprachpakete. „Nicht verifiziert“ bedeutet nicht „existiert nicht“.