#dusk $DUSK @Dusk Lass mich die technischen Behauptungen überprüfen, bevor ich das finalisiere.

Lies am späten Nachmittag Dusk’ Whitepaper durch, neugierig darauf, was XSC jenseits eines Namens tatsächlich bedeutete. Hängen blieb ich schließlich beim Transaktionsabschnitt. Dusk betreibt zwei Modelle auf einer Kette: Moonlight, ein transparentes Kontosystem, und Phoenix, ein abgeschirmtes UTXO-Modell mit Zero-Knowledge-Proofs.

Was ich nicht erwartet habe: Moonlight war nicht Teil des ursprünglichen Designs. Dusk hat es später hinzugefügt, nachdem klar wurde, dass die Börsenanbindung ein öffentliches Transaktionsmodell braucht, denn vollständige Anonymität birgt nach EU-Regeln das Risiko der Listungsentfernung. Das ist ein praktischer Grund, kein Marketinggrund – und er verändert, wie ich das ganze System lese.

Die beiden Modelle sind nicht voneinander isoliert. Ein Transfer Contract ermöglicht es Nutzern, zwischen Phoenix-Notizen und Moonlight-Salden atomar zu wechseln, und Phoenix unterstützt Viewing Keys, sodass bestimmte Transaktionen gezielt offengelegt werden können, um sie für Audits auszuwerten.

Konkretes Szenario: Ein kleines Handelsteam zahlt Gehälter und berichtet Treasury-Bewegungen über Moonlight – vollständig sichtbar – und führt dann die tatsächlichen Positions-Trades über Phoenix aus, verborgen vor Wettbewerbern, mit einem Viewing Key, den bei Bedarf ein Regulator besitzt. Keine Bridge, keine zweite Kette, dieselbe Settlement-Ebene.

Das ist der Pitch. Was ich anhand des Dokuments nicht beurteilen kann, ist die Reibung: wie sich die Konvertierung bei echter Last verhält, und ob „nahtlos“ wirklich gilt, wenn beide Modelle sich denselben Block-Space teilen.

Hat jemand tatsächlich Moonlight-zu-Phoenix-Konvertierungen auf Dusk-Testnet ausgeführt? Wirkte es atomar und schnell, oder gab es eine Verzögerung, die in den Docs nicht erwähnt wird? $SOL $LAB