Zum Inhalt springen
Kein Netzwerk-AmendmentTier BKommende StandardsSpec: Draft

URIToken XLS-35

Ein älterer Draft für schlanke, einzeln reservepflichtige URI-Token als Alternative zur XLS-20-NFT-Struktur. 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-35
Spec-Status
Draft
Spec-Stand
09.02.2023

Was schlägt diese XLS vor?

Welches Problem soll der Vorschlag lösen?

XLS-20 bündelt NFTs in Seiten und verwendet eigene Offer-Objekte mit zahlreichen Sonderfällen. Der Vorschlag sucht ein kleineres Modell aus erstklassigem Objekt, URI und höchstens einem aktuellen Verkaufsangebot.

Wie ist der Mechanismus im aktuellen Draft gedacht?

URITokenMint erzeugt genau ein ltURI_TOKEN pro Kombination aus Issuer und URI und kann optional einen unveränderlichen Inhalts-Digest sowie tfBurnable setzen. URITokenCreateSellOffer schreibt Preis und optionales Ziel direkt in dieses Objekt; URITokenBuy erfüllt das eine vorhandene Angebot ohne Pathfinding. Burn und Cancel entfernen das Objekt beziehungsweise seine Verkaufsfelder.

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
Native XLS-20-NFTs liegen als Einträge in NFTokenPage und handeln über separate Buy- oder Sell-Offer-Objekte.Jedes URIToken wäre ein eigenes Owner-Objekt, das höchstens ein direkt eingebettetes Verkaufsangebot tragen kann.

Für wen ist die Änderung relevant?

XRP-Halter und Nutzer

Käufer können den optionalen Digest gegen den Inhalt der URI prüfen. Bei tfBurnable darf der Aussteller das Token später vernichten.

Wallets und App-Entwickler

Indexer erhalten ein einzelnes Objekt je Token und müssen nur ein Sell Offer abbilden. Käufe erlauben kein Pathfinding und keine andere Währung als das Angebot.

Börsen und Emittenten

Minter können nicht für Dritte minten und pro URI nur ein Token erzeugen. Digest und Burn-Recht werden bei der Ausgabe festgelegt.

Node-Betreiber

Jedes Token belegt ein eigenes Owner-Objekt und verschiebt seine Reserve beim Eigentümerwechsel zum neuen Besitzer.

Welche Grenzen und Risiken bleiben?

  • XLS-35 ist seit 2023 als Draft geführt und keine aktive Mainnet-Funktion.
  • Es gibt keine Buy Offers und höchstens ein Sell Offer pro Token.
  • URITokenBuy unterstützt kein Pathfinding. Kaufbetrag und Angebot müssen dieselbe Währung verwenden.
  • Jedes Token kostet eine volle Owner-Reserve statt sich eine NFTokenPage-Reserve mit weiteren NFTs zu teilen.
  • Ein bei der Ausgabe gesetztes tfBurnable erlaubt dem Issuer die spätere Vernichtung auch nach einem Verkauf.
  • Ohne Digest kann sich der Inhalt am URI-Ziel ändern; mit Digest ist eine beabsichtigte dynamische Aktualisierung nicht mehr verifizierbar.
  • Der Vorschlag enthält keine XLS-20-TransferFee oder parallele Marktplatzangebote.

Welche Gebühren- und Performancewerte nennt die Spec?

  • Jedes URIToken bindet beim aktuellen Owner eine eigene Owner-Reserve. Beim Burn wird sie frei.
Technische Details: Transaktionen, Felder, Codes und Invarianten

Transaktionen

  • URITokenMint
  • URITokenBurn
  • URITokenBuy
  • URITokenCreateSellOffer
  • URITokenCancelSellOffer

Ledger-Objekte

  • URIToken (ltURI_TOKEN)

Felder und Flags

  • URITokenID aus Issuer und URI
  • URI / Issuer / Owner
  • Digest (SHA512-Half)
  • Amount / Destination
  • tfBurnable 0x00000001

Invarianten

  • Ein Issuer kann für dieselbe URI höchstens ein URIToken ausgeben.
  • Das Token trägt höchstens ein aktives Verkaufsangebot.

Wie sieht ein konkreter Ablauf aus?

Ein Issuer mintet einen URIToken mit Digest. Der Owner setzt genau ein XRP-Angebot; ein Käufer nennt denselben URITokenID und mindestens den geforderten Betrag, worauf Objekt und Reserve zum Käufer wechseln.

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