Zunächst ging ich davon aus, dass eine Compliance-Schicht für regulierte Assets etwas Einzigartiges sei. Ein Design. Ein Satz von Trade-offs. Jeder nutzt denselben Pfad. Dusk betreibt zwei. Zedger basiert auf der nativen Ausführungsumgebung. Hedger läuft auf der EVM-kompatiblen Schicht. Beide kümmern sich um die Emission regulierter Assets. Beide erzwingen Compliance-Regeln. Keines ist das andere. Was meine Aufmerksamkeit auf sich zog, war nicht die technische Aufteilung, sondern das, was sie darüber verrät, wen das Protokoll tatsächlich zu bedienen versucht. Native Entwickler erhalten einen Pfad. Solidity-Entwickler erhalten einen anderen. Das ist Flexibilität. Es sind aber auch zwei Codebasen, zwei Wartungsaufwände, zwei Stellen, an denen sich eine Compliance-Lücke bemerkbar machen könnte, bevor es überhaupt jemand merkt. Die Frage, die ich anhand der Dokumentation nicht beantworten kann, lautet, ob beide Schichten identische Datenschutz-/Privatsphären-Garantien bieten oder ob eine davon Trade-offs macht, die die andere nicht macht. Flexibilität, die stillschweigend unterschiedlichen Nutzern unterschiedliche Schutzstufen gibt, ist eigentlich keine Flexibilität. Es ist ein gestuftes System mit einem freundlicher klingenden Namen. Wenn <@Dusk > zwei Compliance-Schichten auf demselben Protokoll aufbaut, verdoppelt das dann das Ökosystem oder spaltet es?

#dusk $DUSK @Dusk