Zwei der Kernideen von Dusk scheinen miteinander im Konflikt zu stehen, und es hat mich eine Weile gekostet zu sehen, wie sie zusammenpassen.
„Native Issuance“ bedeutet, dass ein Wertpapier onchain als tatsächlicher Datensatz erzeugt wird. Es gibt keinen externen Treuhänder, der das Original verwahrt. Das Ledger ist das Asset.
#dusk
„Phoenix privacy“ bedeutet, dass Salden und Inhaber privat sind. Überweisungen sind abgeschirmt. Niemand, der sich die Kette ansieht, kann erkennen, wer was hält.
Nun denke an Corporate Actions. Wenn ein Unternehmen eine Anleihe emittiert und die Zeit kommt, einen Coupon zu zahlen, oder wenn eine Aktionärsstimme ein Register erfordert, das auf einem bestimmten Datum zeigt, wer was gehalten hat, muss der Emittent wissen, wer das Asset hält. Das ist eine gesetzliche Verpflichtung – nicht optional.
Auf einer transparenten Kette ist das trivial. Man sieht sich die Salden an.
Bei Dusk kann der Emittent, wenn eine Anleihe nativ emittiert wurde und die Inhaber „Phoenix“ verwenden, nicht in die Kette schauen und sehen, wer was hält. Die Privatsphäre funktioniert wie vorgesehen. Das Problem der Corporate Action ist real.
Das, was sie kompatibel macht, ist selektive Offenlegung. Inhaber können ZK-Beweise erzeugen, die dem Emittenten genau das offenbaren, was er braucht, um ihre Berechtigung sowie ihren Bestand zu prüfen – genau in dem Umfang, den die rechtliche Anforderung verlangt –, ohne alles andere zu zeigen. Die Offenlegung wird vom Inhaber gesteuert, wobei der Emittent der konkrete Empfänger ist.
@Dusk
Die Synthese ist also: Native Issuance schafft die Notwendigkeit für die Sichtbarkeit des Emittenten. Phoenix erzeugt das Problem der verborgenen Inhaber. Selektive Offenlegung ist die Brücke, die beides nebeneinander bestehen lässt. Jede der drei ergibt in diesem Kontext nur Sinn, weil die anderen beiden ebenfalls existieren.
Worüber ich mir wirklich unsicher bin, ist die operative Seite: Wie funktioniert der tatsächliche Dividendenauszahlungs-Flow, wenn die Inhaberliste privat ist? Muss jede Coupon-Zahlung erfordern, dass jeder Inhaber einen Beweis generiert? Ich würde gern sehen, dass dieser Prozess Ende-zu-Ende beschrieben wird.
$DUSK
„Native Issuance“ bedeutet, dass ein Wertpapier onchain als tatsächlicher Datensatz erzeugt wird. Es gibt keinen externen Treuhänder, der das Original verwahrt. Das Ledger ist das Asset.
#dusk
„Phoenix privacy“ bedeutet, dass Salden und Inhaber privat sind. Überweisungen sind abgeschirmt. Niemand, der sich die Kette ansieht, kann erkennen, wer was hält.
Nun denke an Corporate Actions. Wenn ein Unternehmen eine Anleihe emittiert und die Zeit kommt, einen Coupon zu zahlen, oder wenn eine Aktionärsstimme ein Register erfordert, das auf einem bestimmten Datum zeigt, wer was gehalten hat, muss der Emittent wissen, wer das Asset hält. Das ist eine gesetzliche Verpflichtung – nicht optional.
Auf einer transparenten Kette ist das trivial. Man sieht sich die Salden an.
Bei Dusk kann der Emittent, wenn eine Anleihe nativ emittiert wurde und die Inhaber „Phoenix“ verwenden, nicht in die Kette schauen und sehen, wer was hält. Die Privatsphäre funktioniert wie vorgesehen. Das Problem der Corporate Action ist real.
Das, was sie kompatibel macht, ist selektive Offenlegung. Inhaber können ZK-Beweise erzeugen, die dem Emittenten genau das offenbaren, was er braucht, um ihre Berechtigung sowie ihren Bestand zu prüfen – genau in dem Umfang, den die rechtliche Anforderung verlangt –, ohne alles andere zu zeigen. Die Offenlegung wird vom Inhaber gesteuert, wobei der Emittent der konkrete Empfänger ist.
@Dusk
Die Synthese ist also: Native Issuance schafft die Notwendigkeit für die Sichtbarkeit des Emittenten. Phoenix erzeugt das Problem der verborgenen Inhaber. Selektive Offenlegung ist die Brücke, die beides nebeneinander bestehen lässt. Jede der drei ergibt in diesem Kontext nur Sinn, weil die anderen beiden ebenfalls existieren.
Worüber ich mir wirklich unsicher bin, ist die operative Seite: Wie funktioniert der tatsächliche Dividendenauszahlungs-Flow, wenn die Inhaberliste privat ist? Muss jede Coupon-Zahlung erfordern, dass jeder Inhaber einen Beweis generiert? Ich würde gern sehen, dass dieser Prozess Ende-zu-Ende beschrieben wird.
$DUSK
