Ich starrte so lange auf ein Dividenden-Zahlungsflussdiagramm, bis es irgendwann nicht mehr sinnvoll wirkte. DTC zu Broker zu Sub-Custodian zu Aktionär – vier Sprünge, und ich ging davon aus, dass der Engpass irgendwo in der Verarbeitungsgeschwindigkeit lag. Dem ist nicht so. Je mehr ich nachgesehen habe, desto klarer wurde mir: Die echten Kosten stecken in der Abstimmung (Reconciliation). Jede Stelle in dieser Kette aktualisiert ihre eigenen Datensätze unabhängig, und erst danach vergleichen alle die Notizen. Genau dort landen die 58 Mrd. $ an jährlichen Kosten für Corporate Actions.
Was mir beim Durchgraben der XSC-Designs von DUSK besonders aufgefallen ist: Es versucht nicht, jeden Hop schneller zu machen. Es entfernt überhaupt die Notwendigkeit für Abstimmungen zwischen den Hops – bei einer einzigen Ausführung, einem einzigen Ergebnis, wobei jeder Inhaber aus derselben Quelle liest, statt dass vier Parteien separat berechnen und später abgleichen. Genau hier beginnt sich DUSKs Ansatz anders anzufühlen als die meisten Infrastrukturen, die ich zuvor gesehen habe.
Da ist bei mir auch der Unterschied zwischen Tokenisierung und nativer Ausgabe klick gemacht. Eine Aktie in einen Token zu verpacken sitzt zwar immer noch auf dem gleichen DTC-„Klempnerwerk“, das man hinzugefügt hat – ersetzt wurde es nicht. Native Ausgabe auf etwas wie DUSK stellt eine deutlich direktere Frage: Braucht man immer noch Tausende von Paying Agents, die denselben Dividenden-Event unabhängig voneinander verarbeiten, wenn es eine einzige Settlement-Ebene gibt, von der alle lesen? DUSKs gesamte Architektur scheint darauf zu wetten, dass die Antwort „nein“ lautet.
Ich bleibe allerdings beim Thema Haftung hängen. Wenn ein DUSK-Contract eine Auszahlung falsch berechnet – wer ist dann in der Verantwortung: die Kette, der Emittent oder der Paying Agent, der früher existierte? Ich glaube nicht, dass das bereits beantwortet ist, und ich bin mir nicht sicher, ob man das einfach darüber hinwegsehen sollte, nur weil die Architektur „sauberer“ ist.
#dusk $DUSK @Dusk
Was mir beim Durchgraben der XSC-Designs von DUSK besonders aufgefallen ist: Es versucht nicht, jeden Hop schneller zu machen. Es entfernt überhaupt die Notwendigkeit für Abstimmungen zwischen den Hops – bei einer einzigen Ausführung, einem einzigen Ergebnis, wobei jeder Inhaber aus derselben Quelle liest, statt dass vier Parteien separat berechnen und später abgleichen. Genau hier beginnt sich DUSKs Ansatz anders anzufühlen als die meisten Infrastrukturen, die ich zuvor gesehen habe.
Da ist bei mir auch der Unterschied zwischen Tokenisierung und nativer Ausgabe klick gemacht. Eine Aktie in einen Token zu verpacken sitzt zwar immer noch auf dem gleichen DTC-„Klempnerwerk“, das man hinzugefügt hat – ersetzt wurde es nicht. Native Ausgabe auf etwas wie DUSK stellt eine deutlich direktere Frage: Braucht man immer noch Tausende von Paying Agents, die denselben Dividenden-Event unabhängig voneinander verarbeiten, wenn es eine einzige Settlement-Ebene gibt, von der alle lesen? DUSKs gesamte Architektur scheint darauf zu wetten, dass die Antwort „nein“ lautet.
Ich bleibe allerdings beim Thema Haftung hängen. Wenn ein DUSK-Contract eine Auszahlung falsch berechnet – wer ist dann in der Verantwortung: die Kette, der Emittent oder der Paying Agent, der früher existierte? Ich glaube nicht, dass das bereits beantwortet ist, und ich bin mir nicht sicher, ob man das einfach darüber hinwegsehen sollte, nur weil die Architektur „sauberer“ ist.
#dusk $DUSK @Dusk
