Zum Inhalt springen
In AbstimmungTier ADeFi & DEX

LendingProtocol XLS-66

Das XRPL-Lending-Protokoll bildet befristete, unbesicherte Kredite aus Vault-Pools ab. LendingProtocol ist auf dem Mainnet offen, aber noch nicht aktiviert. Aktuell melden 12 von 35 erfassten Validatoren Unterstützung.

Fachlich geprüft am 31.07.2026 · Autor: Philip F. Schmitt

Status
In Abstimmung
XLS
XLS-66
Version
rippled 3.1.0
Aktiviert
Keine Angabe

Wie steht die Mainnet-Abstimmung?

12 von 35 Ja-Stimmen, benötigt: 28 (aktuell 34 %, Ziel 80 %)

Was ändert dieses Amendment?

Warum gibt es dieses Amendment?

Kapital aus einem gemeinsamen Vault soll über definierte On-Ledger-Kreditobjekte ausgeliehen und zurückgeführt werden können.

Wie funktioniert der Mechanismus?

Ein LoanBroker verbindet einen Single Asset Vault mit einzelnen, fest verzinsten Loan-Objekten. LoanSet legt einen Kredit atomar mit Zustimmung von Broker und Kreditnehmer an, zahlt Kapital aus und schreibt Tilgungsplan, Gebühren und Fälligkeiten in den Ledger. LoanPay, LoanManage und die Cover-Transaktionen führen Rückzahlungen, Wertberichtigungen, Ausfälle und das First-Loss-Kapital fort.

Was ändert sich gegenüber dem Vorgänger?

VorherNachher
Ein Vault bündelte Assets und Anteile, kannte aber weder Kreditvertrag noch Tilgungsplan, Brokergebühren oder Ausfallstatus.Befristete, unbesicherte Kredite werden als eigene Ledger-Objekte aus Vault-Liquidität ausgezahlt und nach festen Regeln zurückgeführt.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Vault-Einleger stellen freiwillig Kapital für unbesicherte Kredite bereit. Ausfälle und Wertberichtigungen können den Wert ihrer Vault-Anteile senken.

Wallets und App-Entwickler

Apps müssen Broker, Vault, Kreditstatus, Fälligkeiten, Rundung und verschiedene Zahlungsarten aus den gespeicherten Ledger-Werten lesen. Formeln allein reichen nicht als aktueller Saldo.

Börsen und Emittenten

Broker verantworten Off-Ledger-Prüfung, Kreditentscheidung, Gebühren und Ausfallmanagement. First-Loss-Kapital begrenzt Risiken, ersetzt aber keine Bonitätsprüfung.

Node-Betreiber

Nodes führen Tilgungsrechnung, Präzisionsprüfung, Statuswechsel und Buchungen zwischen Kreditnehmer, Broker-Pseudo-Konto und Vault deterministisch aus.

Welche Grenzen und Risiken bleiben?

  • Die Kredite sind unbesichert. Es gibt keine On-Ledger-Sicherheiten und keine automatische Liquidation.
  • Bonitätsprüfung, Identitätsprüfung und Kreditentscheidung bleiben außerhalb des Ledgers.
  • Das Protokoll bildet fest terminierte, amortisierende Kredite ab und keine variable Zinskurve.
  • Die Beteiligten müssen dem LoanBroker und seinen Off-Ledger-Prozessen vertrauen.
  • Asset-Präzision kann Konditionen unzulässig machen. MPTs erlauben nur ganze Einheiten und Zahlungen werden nach den Spec-Regeln gerundet.
  • Ein Kredit darf erst nach Ablauf von Fälligkeit und GracePeriod als ausgefallen markiert werden.
  • Die in der Spec markierten Transaktionsinvarianten sind noch als TBD ausgewiesen und werden deshalb hier nicht behauptet.

Welche Gebühren- und Performancewerte nennt die Spec?

  • LoanSet benötigt die Reserve des Kreditnehmers für das Loan-Objekt.
  • First-Loss-Kapital muss mindestens DebtTotal multipliziert mit CoverRateMinimum abdecken.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • LoanBrokerSet (Typ 74)
  • LoanBrokerDelete (Typ 75)
  • LoanBrokerCoverDeposit (Typ 76)
  • LoanBrokerCoverWithdraw (Typ 77)
  • LoanBrokerCoverClawback (Typ 78)
  • LoanSet (Typ 80)
  • LoanDelete (Typ 81)
  • LoanManage (Typ 82)
  • LoanPay (Typ 83)

Ledger-Objekte

  • LoanBroker (0x0088)
  • Loan
  • Vault
  • AccountRoot der Pseudo-Konten

Felder und Flags

  • VaultID / LoanBrokerID / LoanID
  • PrincipalRequested
  • InterestRate / LateInterestRate / CloseInterestRate
  • PaymentTotal / PaymentInterval / GracePeriod
  • Counterparty / CounterpartySignature
  • DebtTotal / DebtMaximum
  • CoverAvailable / CoverRateMinimum
  • tfLoanDefault 0x00010000
  • tfLoanImpair 0x00020000
  • tfLoanUnimpair 0x00040000
  • tfLoanFullPayment 0x00020000

Ergebnis-Codes

  • temBAD_SIGNER
  • temINVALID
  • temINVALID_FLAG
  • tecNO_ENTRY
  • tecNO_PERMISSION
  • tecINSUFFICIENT_FUNDS
  • tecINSUFFICIENT_PAYMENT
  • tecLIMIT_EXCEEDED
  • tecPRECISION_LOSS
  • tecTOO_SOON
  • tecEXPIRED
  • tecFROZEN / tecLOCKED

Wie sieht ein konkreter Ablauf aus?

Broker und Kreditnehmer signieren dieselben Konditionen für LoanSet. Der Ledger zahlt aus dem Vault aus, legt den Tilgungsplan an und akzeptiert spätere Raten ausschließlich über LoanPay.

Wie hängt dieses Amendment mit anderen zusammen?

Jede direkte Verbindung besitzt einen Typ, eine Erklärung und eine Primärquelle.

Wie geht es mit diesem Amendment weiter?

LendingProtocol ist auf dem Mainnet offen, aber noch nicht aktiviert. Aktuell melden 12 von 35 erfassten Validatoren Unterstützung.

Für die Aktivierung muss die Unterstützung mindestens 80 Prozent erreichen und zwei Wochen ununterbrochen oberhalb dieser Schwelle bleiben.

Wo steht es in seiner Amendment-Familie?

Vaults und Lending: Protokollfolge

  1. PermissionedDEXAktiviert · ab rippled 2.5.0
  2. SingleAssetVaultIn Abstimmung · ab rippled 3.1.0
  3. LendingProtocolIn Abstimmung · ab rippled 3.1.0
  4. fixCleanup3_1_3Aktiviert · ab rippled 3.1.3
  5. fixCleanup3_2_0Aktiviert · ab rippled 3.2.0

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen