Entwurf fuer einen Onchain-Cosigner kommt ins XRPL-Standards-Repository
Serguey Asael Shinder2 Min. LesezeitDas Standards-Repository des XRP Ledger hat am 16. September 2026 einen Entwurf fuer einen Onchain Cosigner aufgenommen. Pull Request #613 stammt von shawnxie999 gemeinsam mit ckeshava und wurde von mvadari zusammengefuehrt; er ergaenzt 1.203 Zeilen in einer einzigen Datei nach 31 Commits und 126 Kommentaren im Thread.
Das ist die Besprechung eines Dokuments, nicht die Meldung eines Starts, und das Datum liegt sechs Tage zurueck — die Feeds des XRP-Tisches trugen nichts Neueres, deshalb steht hier das Repository des Projekts selbst und nicht dessen Berichterstattung.
Zwei Details der Historie sagen, wozu der Entwurf dient. Er ging aus einem frueheren "Cosign draft" (#586) hervor, und eine separate Aenderung beschreibt den Entwurf einer transaction_proposal-RPC rund um den Signaturstand je Konto. Darin steckt die Substanz: Es geht um eine Transaktion, die existiert, unvollstaendig ist und verfolgt werden muss, waehrend sich Signaturen jener Konten ansammeln, von denen sie erwartet werden.
Was das bedeutet
Mehrparteien-Signaturen gibt es auf dem XRP Ledger laengst — SignerLists und multisignierte Transaktionen sind etabliert. Nie standardisiert wurde das Drumherum: wo eine teilsignierte Transaktion wartet, wie ein Beteiligter erfaehrt, dass ausgerechnet seine Signatur fehlt, und wie sich all das abfragen laesst, ohne eine private Absprache zwischen den beteiligten Wallets.
Heute geschieht diese Koordination ausserhalb des Ledgers, in der Infrastruktur eines Anbieters oder in einem geteilten Dokument — und genau dort scheitern Multisig-Verwahrungen typischerweise: nicht an der Kryptografie, sondern an der Buchfuehrung darueber, wer was signiert hat. Eine RPC, die um den Signaturstand je Konto herum gebaut ist, versucht, das abfragbar statt verabredet zu machen.
⚠️ Den Status genau lesen. Ein ins Standards-Repository uebernommener Entwurf ist ein nummeriertes Dokument zur Pruefung; er ist kein Amendment, es steht keine Validator-Abstimmung dahinter, und in rippled setzt ihn nichts um, nur weil er zusammengefuehrt wurde. Zu beobachten ist als Naechstes, ob er eine XLS-Statusaenderung und eine Referenzimplementierung erhaelt — und den Inhalt der Spezifikation haben wir hier nicht geprueft, nur ihr Eintreffen.