Ich habe gestern noch ein Set von automatisierten Skripten für Asset-Abrechnungen durchlaufen lassen und bin aus Langeweile dann noch in das Zedger-Wertpapier-Token-Modell von @Dusk reingestiegen. Als ich die Interaktionsdetails gelesen habe, hab ich als alter Codemonkey fast nicht mehr richtig reagiert: Auf Dusk müssen Empfänger beim Transfer von Wertpapieren anscheinend explizit „Zustimmen“ klicken, sonst gilt die Übertragung nicht als wirklich abgeschlossen – die Assets hängen dann weiterhin an der ursprünglichen Adresse. Nachdem ich auf EVM-Chains gewohnt bin, dass „Senden gleich On-Chain“ ist und man Sekunden später das Geld sieht, war mein erster Gedanke: Warum dieser zusätzliche Schritt? Ist das nicht ein Rückschritt hin zur Zeit, in der man erst eine Bestätigung per E-Mail abwarten musste?
Aber ich glaube grundsätzlich an „erstmal überleben“. Also habe ich mir die Logik in Ruhe angesehen und sie mit den traditionellen Prozessen der Wertpapier-Registry und Clearing-Vorgänge abgeglichen – und plötzlich wurde es mir klar. Im regulierten Finanzbereich ist der Eigentumswechsel von Aktien nie einfach nur einseitiges Transferieren, sondern das Register wird erst aktualisiert, nachdem die Clearing- bzw. Abwicklungsstelle die Qualifikation des Käufers bestätigt hat. Dusk schweißt die „Zweiseitige Bestätigung“ direkt in die Protokollebene – wenn die Whitelist nicht passt oder keine aktive Unterschrift gesetzt wurde, kannst du diese „Aktionärs“-Rolle schlicht nicht annehmen.
Wenn man es genau betrachtet, werden damit direkt drei lebenswichtige Schmerzpunkte eliminiert: Erstens Dust Attacks – früher haben dir allerlei Müll-„Aircoins“ deinen Adressen einfach zugeschaufelt, in Zedger werden sie direkt abgewiesen; zweitens Compliance bei Rechten und Pflichten – ohne Zustimmung ist die gehaltene Position nicht gültig, die Verantwortungsgrenzen sind klar gezogen; drittens Streit bei der Abwicklung – damit wird der Time-Difference-Schmerz der traditionellen DvP (Delivery versus Payment) konsequent beseitigt: Signatur ist Endgültigkeit, keine Zankerei im Zwischenzustand.
Aus Entwicklerperspektive habe ich allerdings auch ein paar Bedenken. Jede Abrechnung erfordert noch eine zusätzliche Signatur-Interaktion – für alle, die wie ich dauerhaft Hochfrequenz-Skripte laufen lassen und Batch-Automatisierung fahren, ist die Reibung real. Wie Dusk künftig die technische Balance zwischen „strikt expliziter Freigabe“ und „Batch-Automatisierungs-Abrechnung“ findet, behalte ich im Code-Repository weiter im Blick.
Wie seht ihr das: Würden Institutionen so ein „Quittung bestätigen“-Design akzeptieren, bei dem man für Compliance ein bisschen Smoothness bei der Interaktion opfert? Schreibt’s in die Kommentare.
@Dusk #dusk $DUSK
Aber ich glaube grundsätzlich an „erstmal überleben“. Also habe ich mir die Logik in Ruhe angesehen und sie mit den traditionellen Prozessen der Wertpapier-Registry und Clearing-Vorgänge abgeglichen – und plötzlich wurde es mir klar. Im regulierten Finanzbereich ist der Eigentumswechsel von Aktien nie einfach nur einseitiges Transferieren, sondern das Register wird erst aktualisiert, nachdem die Clearing- bzw. Abwicklungsstelle die Qualifikation des Käufers bestätigt hat. Dusk schweißt die „Zweiseitige Bestätigung“ direkt in die Protokollebene – wenn die Whitelist nicht passt oder keine aktive Unterschrift gesetzt wurde, kannst du diese „Aktionärs“-Rolle schlicht nicht annehmen.
Wenn man es genau betrachtet, werden damit direkt drei lebenswichtige Schmerzpunkte eliminiert: Erstens Dust Attacks – früher haben dir allerlei Müll-„Aircoins“ deinen Adressen einfach zugeschaufelt, in Zedger werden sie direkt abgewiesen; zweitens Compliance bei Rechten und Pflichten – ohne Zustimmung ist die gehaltene Position nicht gültig, die Verantwortungsgrenzen sind klar gezogen; drittens Streit bei der Abwicklung – damit wird der Time-Difference-Schmerz der traditionellen DvP (Delivery versus Payment) konsequent beseitigt: Signatur ist Endgültigkeit, keine Zankerei im Zwischenzustand.
Aus Entwicklerperspektive habe ich allerdings auch ein paar Bedenken. Jede Abrechnung erfordert noch eine zusätzliche Signatur-Interaktion – für alle, die wie ich dauerhaft Hochfrequenz-Skripte laufen lassen und Batch-Automatisierung fahren, ist die Reibung real. Wie Dusk künftig die technische Balance zwischen „strikt expliziter Freigabe“ und „Batch-Automatisierungs-Abrechnung“ findet, behalte ich im Code-Repository weiter im Blick.
Wie seht ihr das: Würden Institutionen so ein „Quittung bestätigen“-Design akzeptieren, bei dem man für Compliance ein bisschen Smoothness bei der Interaktion opfert? Schreibt’s in die Kommentare.
@Dusk #dusk $DUSK