Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

SmartContracts XLS-101

Ein früher Entwurf für native, zustandsbehaftete WASM-Smart-Contracts auf XRPL-Pseudo-Konten. Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

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

Netzwerkstatus
Kein Netzwerk-Amendment
XLS
XLS-101
Spec-Status
Draft
Spec-Stand
28.07.2025

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

SmartEscrow deckt gezielte Freigabebedingungen ab, aber keine allgemeine Vertragslogik mit dauerhaftem Zustand. Für neue DeFi-Protokolle oder komplexe Bridge-Logik fehlt bislang eine native, programmierbare Ausführungsschicht.

Wie ist der Mechanismus im aktuellen Draft gedacht?

ContractCreate legt ein Pseudo-Konto, ein Contract-Objekt und bei neuem Bytecode ein gemeinsam nutzbares ContractSource-Objekt an. ContractCall ruft eine benannte WASM-Funktion mit Parametern auf; der Code darf eigenen ContractData-Zustand ändern und eingebettete XRPL-Transaktionen atomar ausführen. ContractModify, ContractDelete, ContractUserDelete und ContractClawback regeln Updates, Löschung, Nutzerdaten und Emittentenrechte.

Wie verbindlich ist das?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

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

VorherNachher
XRPL stellt spezialisierte Transaktionstypen bereit, aber keinen allgemeinen zustandsbehafteten Vertrag mit frei definierbaren Funktionen.Ein Vertrag könnte als gesichertes Pseudo-Konto WASM-Code, Instanzparameter und eigenen Ledger-Zustand besitzen und native XRPL-Transaktionen auslösen.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Nutzer könnten neue Anwendungen direkt auf XRPL verwenden. An einen Vertrag gesendete Assets bleiben jedoch dem Code und möglichen Betrugsrisiken ausgesetzt.

Wallets und App-Entwickler

Entwickler müssten WASM, ABI, Gas, ContractData, Ereignisse und eingebettete Transaktionsergebnisse beherrschen. Wiederverwendeter ContractSource-Code senkt Speicherbedarf, ersetzt aber kein Audit.

Börsen und Emittenten

Emittenten könnten programmierbare Finanzlogik nutzen und per ContractClawback eigene Tokenrechte durchsetzen. Compliance und Vertragsprüfung bleiben organisatorische Aufgaben.

Node-Betreiber

Alle Validatoren müssten Bytecode, Zustandsänderungen und ausgelöste Transaktionen deterministisch innerhalb harter Ressourcenlimits ausführen.

Welche Grenzen und Risiken bleiben?

  • XLS-101 ist ein früher Draft mit ausdrücklichen offenen Fragen und noch kein Netzwerk-Feature.
  • Das Gebührenmodell nennt noch keine endgültigen Werte. Auch die Behandlung von Gasgebühren ist offen.
  • Wie Reserven für nutzerspezifische ContractData-Objekte verteilt werden, ist nicht entschieden.
  • Der Entwurf benennt Reentrancy als ungelöstes Sicherheitsgebiet.
  • Vertragscode kann betrügerisch oder fehlerhaft sein. Der Ledger bewertet seine wirtschaftliche Sicherheit nicht.
  • ContractData und Contract blockieren AccountDelete, bis die zugehörigen Objekte geordnet entfernt wurden.
  • Die vorgesehene URI-Platzierung und mehrere Serialisierungsdetails sind noch als offene Punkte markiert.

Welche Gebühren- und Performancewerte nennt die Spec?

  • ContractCreate soll mindestens ungefähr eine Objektreserve als nicht rückzahlbare Gebühr kosten, ergänzt um Bytecode- und init-Ausführungskosten.
  • Instruktionspreis, maximale Instruktionszahl und Speicherlimits sollen durch UNL Fee Voting veränderbar sein. Konkrete Startwerte fehlen im Draft.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • ContractCreate
  • ContractCall
  • ContractModify
  • ContractDelete
  • ContractUserDelete
  • ContractClawback

Ledger-Objekte

  • ContractSource
  • Contract
  • ContractData
  • AccountRoot des Pseudo-Kontos
  • FeeSettings

Felder und Flags

  • ContractCode / ContractHash
  • ContractAccount / ContractOwner
  • Functions / FunctionName / FunctionParameters
  • InstanceParameters / InstanceParameterValues
  • ReferenceCount / Data / ParentContractCallId
  • tfImmutable / tfCodeImmutable / tfABIImmutable / tfUndeletable
  • tfContractSubmittedTxn 0x20000000

API-Methoden

  • contract_info
  • eventEmitted Subscription
  • event_history

Invarianten

  • Kein ContractSource-Objekt darf mit ReferenceCount null bestehen bleiben.
  • Jedes Contract-Objekt muss auf ein vorhandenes ContractSource-Objekt zeigen.
  • Von lsfImmutable, lsfCodeImmutable und lsfABIImmutable darf höchstens ein Flag gesetzt sein.

Wie sieht ein konkreter Ablauf aus?

Ein DeFi-Vertrag wird einmal mit ContractCreate bereitgestellt. Ein Nutzer ruft eine Funktion über ContractCall auf; der Vertrag aktualisiert ContractData und löst innerhalb derselben Verarbeitung eine native Payment-Transaktion aus.

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 Vorschlag weiter?

Das ist ein Vorschlag, kein aktives Netzwerk-Feature. Was davon kommt und wann, ist offen.

Der Entwurf muss fachlich reifen und kann sich noch grundlegend ändern oder verworfen werden. Erst ein passendes rippled-Amendment würde eine getrennte Netzwerkabstimmung auslösen.

Wo steht es in seiner Amendment-Familie?

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen