Zitadelle erklärt: Wie Dusk Identität und selektive Offenlegung handhabt

Ich bin diese Woche in die Brücken-Operations von Dusk eingetaucht und bin dabei auf etwas Merkwürdiges gestoßen, noch bevor ich überhaupt bei der Zitadelle selbst angekommen bin: Der „Brücken-Vorfall“, auf den ich immer wieder gestoßen bin, hat in den Quellen keinen konsistenten Zeitstempel. Ein Aggregator datiert die verdächtige Wallet-Aktivität auf den 16. August, aber Dusk’ eigener News-Index listet eine „Bridge Services Incident Notice“ aus Januar und ein separates Post-Mortem im März auf – ohne dass ein August-Eintrag sichtbar ist. Dieselbe zugrunde liegende Geschichte (teamverwaltete Bridge-Wallet als auffällig markiert, Adressen recycelt, Bridge pausiert, eine Web-Wallet-Empfänger-Blocklist ausgeliefert, um Überweisungen an die markierten Adressen zu blockieren), aber die Belegkette passt nicht sauber zusammen.

Was die bestätigten Punkte zeigen: Die Bridge-Services wurden als Vorsichtsmaßnahme angehalten, eine kleine Zahl an Transaktionen wurde während des markierten Zeitfensters verschoben, und ein Teil dieses Flows soll Berichten zufolge Binance berührt haben, bevor die Eindämmung erfolgte. Das ist eine echte operative Reaktion, keine Spekulation.

Was es nicht zeigt: ein verifiziertes einzelnes Datum oder öffentliche Wallet-Adressen, die ich selbst zurückverfolgen könnte. Für ein Projekt, dessen Kernversprechen selektive, überprüfbare Offenlegung ist, ist diese Lücke eine mild ironische.

Hat jemand die tatsächlichen On-Chain-Adressen im Zusammenhang damit herausgezogen, und kann bestätigen, welche Woche das war?

Diese Tabelle legt dar, was bestätigt ist, versus was ich ableite – und dass der Datumsabgleich selbst der interessanteste Datenpunkt hier ist. Genau so etwas soll das On-Chain-Verifizierungsmodell von Citadel doch eindeutig machen.

@Dusk $DUSK #dusk