Zum Inhalt springen
In EntwicklungTier AZahlungen

SmartEscrow XLS-100

WebAssembly-Funktionen sollen frei programmierbare Freigaberegeln für Escrows ermöglichen. SmartEscrow ist laut xrpl.org in Entwicklung und noch nicht als Mainnet-Abstimmung gelistet. Eine stabile rippled-Version und die Validatorabstimmung stehen noch aus.

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

Status
In Entwicklung
XLS
XLS-100
Version
Offen
Aktiviert
Keine Angabe

Was ist der Entwicklungsstand?

Warum wird diese Funktion entwickelt?

Zeitangaben und standardisierte Crypto-Conditions decken nicht jede gewünschte Freigabelogik eines Escrows ab.

Wie soll der Mechanismus funktionieren?

EscrowCreate kann kompilierten WASM-Bytecode und lokalen Datenspeicher unveränderlich an das Escrow-Objekt binden. EscrowFinish führt die exportierte Funktion escrow_finish unter einem Gaslimit aus und zahlt nur aus, wenn sie einen positiven int32 zurückgibt. Der Code darf Ledger-Daten lesen, aber außer seinem eigenen Data-Feld keine Ledger-Objekte verändern und keine Transaktionen erzeugen.

Was fehlt bis zum Mainnet?

Nach Implementierung und Tests muss die Änderung in einer stabilen rippled-Version erscheinen. Erst dann kann die Mainnet-Abstimmung beginnen.

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

VorherNachher
Escrows konnten nur Zeitgrenzen und eine PREIMAGE-SHA-256-Crypto-Condition als Freigaberegel kombinieren.Ein Escrow kann zusätzlich eine begrenzte programmierbare Bedingung prüfen, etwa Credential-, Notar- oder Oracle-Regeln.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Nutzer können komplexere Freigaben verwenden, müssen Code und Ablaufzeit aber vor dem Sperren prüfen. Ein fehlerhafter Vertrag bleibt bis zur Stornierung gebunden.

Wallets und App-Entwickler

Entwickler kompilieren WASM mit genau definierter ABI, schätzen Gas und behandeln Trap, negativen Rückgabewert und unzureichendes Gas als fehlgeschlagene Freigabe.

Börsen und Emittenten

Unternehmen könnten Notar-, Compliance- oder Oracle-Bedingungen direkt an Escrows knüpfen. Tokenunterstützung hängt zusätzlich von TokenEscrow ab.

Node-Betreiber

Alle Validatoren führen denselben Bytecode deterministisch aus. FeeSettings begrenzt Codegröße, Gas und Preis, damit die UNL Ressourcenverbrauch anpassen kann.

Welche Grenzen und Risiken bleiben?

  • Das Amendment ist ein Draft und noch keine Mainnet-Funktion.
  • Die Details der WASM-Engine und API sollen in einer getrennten XLS festgelegt werden.
  • Bytecode und Freigabebedingungen lassen sich nach EscrowCreate nicht aktualisieren.
  • Data kann nicht durch eine normale Transaktion geändert werden, sondern nur durch den eigenen Bytecode.
  • Der Code besitzt keinen Schreibzugriff auf andere Ledger-Objekte und kann keine Transaktionen erzeugen.
  • Jedes Smart Escrow braucht CancelAfter als Notausgang.
  • Alle Nodes und Validatoren müssen den Bytecode ausführen.
  • SmartEscrow macht den XRPL nicht zu einer allgemeinen Smart-Contract-Plattform.
  • Die genaue EscrowFinish-Gebühr ist in der Spec noch nicht festgelegt.

Welche Gebühren- und Performancewerte nennt die Spec?

  • EscrowCreate mit Bytecode kostet laut Draft 100 Drops plus 5 Drops je Byte Bytecode.
  • Die ersten 500 Byte sind in der ersten Objektreserve enthalten. Für je weitere 500 Byte fällt eine zusätzliche Objektreserve an.
  • Die Startwerte im Draft sind 100.000 Gas, 100.000 Byte BytecodeSizeLimit und 1.000 Micro-Drops je Gas. Die UNL kann diese Werte per Fee Voting ändern.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • EscrowCreate
  • EscrowFinish
  • SetFee

Ledger-Objekte

  • Escrow (0x0075)
  • FeeSettings

Felder und Flags

  • Bytecode
  • Data (max. 4 KB nach Ausführungsmodell)
  • Gas
  • GasUsed
  • VMReturnCode
  • GasLimit
  • BytecodeSizeLimit
  • GasPrice
  • CancelAfter

Ergebnis-Codes

  • temMALFORMED
  • temBAD_EXPIRATION
  • temINVALID_BYTECODE
  • temTEMP_DISABLED
  • tefNO_BYTECODE
  • tefBYTECODE_NOT_INCLUDED
  • tecBYTECODE_REJECTED

Invarianten

  • Jedes Escrow mit Bytecode muss CancelAfter besitzen.

Wie sieht ein konkreter Ablauf aus?

Ein Escrow enthält eine Notaradresse im Bytecode. EscrowFinish liest die signierende Transaktion und gibt nur dann einen positiven Wert zurück, wenn das festgelegte Konto die Freigabe auslöst.

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?

SmartEscrow ist laut xrpl.org in Entwicklung und noch nicht als Mainnet-Abstimmung gelistet. Eine stabile rippled-Version und die Validatorabstimmung stehen noch aus.

Nach Implementierung und Tests muss die Änderung in einer stabilen rippled-Version erscheinen. Erst dann kann die Mainnet-Abstimmung beginnen.

Wo steht es in seiner Amendment-Familie?

Escrow und Payment Channels: Protokollfolge

  1. PayChanAktiviert · ab rippled 0.33.0
  2. CryptoConditionsAktiviert · ab rippled 0.50.0
  3. EscrowAktiviert · ab rippled 0.60.0
  4. fix1512Aktiviert · ab rippled 0.80.0
  5. fix1523Aktiviert · ab rippled 0.80.0
  6. fix1571Aktiviert · ab rippled 1.0.0
  7. fixPayChanRecipientOwnerDirAktiviert · ab rippled 1.4.0
  8. PriceOracleAktiviert · ab rippled 2.2.0
  9. TokenEscrowAktiviert · ab rippled 2.5.0
  10. fixPayChanCancelAfterAktiviert · ab rippled 2.5.0
  11. fixPriceOracleOrderAktiviert · ab rippled 3.0.0
  12. fixIncludeKeyletFieldsAktiviert · ab rippled 3.0.0
  13. SmartEscrowIn Entwicklung

Welche Primärquellen belegen die Angaben?

← Alle XRPL-Amendments und XLS-Spezifikationen