Ich habe letzte Woche spät in der Nacht durch @Dusk CreatorPad-Einträge gescrollt und irgendwie die Zeit vergessen, während ich ihre älteren Versionshinweise durchging.
die Community redet ständig über diesen Reinforced-Concrete-Hash, der angeblich 17-mal schneller läuft als Poseidon – solides Engineering, keine Frage. Aber das ist nicht der Teil, der mir aufgefallen ist.
Was mich wirklich zum Weiterlesen gebracht hat, war etwas aus Januar 2026. Dusk hat auf seltsame Aktivitäten von einer Bridge-Wallet reagiert, die durch unbefugten Zugriff kompromittiert worden war – und diese Wallet stand unter der Kontrolle ihres eigenen Teams. Ihre Reaktion? Sie haben die Adressen eingefroren, die gesamte Bridge gestoppt, eine Blocklist für Empfänger veröffentlicht und sich an Binance gewandt, um herauszufinden, wohin die Gelder gerade flossen.
Moment mal. Für eine Kette, die sich selbst als „privacy-first“ vermarktet, fühlt sich diese Reaktion auffällig vertraut an – so, wie man es von einer normalen verwahrenden (custodial) Börse erwarten würde.
Klar, keine Nutzerfonds sind verschwunden. Das ist eine Erleichterung. Aber hier ist das Problem, das niemand zu erwähnen scheint: Die Smart-Contract-Leitplanken und die dezentrale Multi-Sig haben dabei nichts abgefangen. Kein automatisierter Sicherheitsmechanismus ist eingeschritten. Es waren Menschen, die manuell zugesehen haben – und dann alles per Hand abgeschaltet haben.
Das ist der Teil von Dusk, der mir im Kopf geblieben ist. Von außen: standardmäßig privat, sofortige Finalität, zk-alles. Aber in diesem Moment von Druck wirkte das echte Bild anders: eine Bridge, die das Team jederzeit pausieren kann, mit Blocklist-Rechten, die in Admin-Wallets liegen.
Bridges waren schon immer die Schwachstelle. Aber als ich dabei zugesehen habe, wie das auf Dusk abläuft – einem Projekt, das um das Entfernen von Vertrauen herum gebaut ist –, hat mich das nachdenklich gemacht. Wenn Dusk seinem „trustless“-Versprechen wirklich gerecht werden will, wird diese Bridge-Abhängigkeit früher oder später eine echte Lösung brauchen.
#dusk $DUSK @Dusk
die Community redet ständig über diesen Reinforced-Concrete-Hash, der angeblich 17-mal schneller läuft als Poseidon – solides Engineering, keine Frage. Aber das ist nicht der Teil, der mir aufgefallen ist.
Was mich wirklich zum Weiterlesen gebracht hat, war etwas aus Januar 2026. Dusk hat auf seltsame Aktivitäten von einer Bridge-Wallet reagiert, die durch unbefugten Zugriff kompromittiert worden war – und diese Wallet stand unter der Kontrolle ihres eigenen Teams. Ihre Reaktion? Sie haben die Adressen eingefroren, die gesamte Bridge gestoppt, eine Blocklist für Empfänger veröffentlicht und sich an Binance gewandt, um herauszufinden, wohin die Gelder gerade flossen.
Moment mal. Für eine Kette, die sich selbst als „privacy-first“ vermarktet, fühlt sich diese Reaktion auffällig vertraut an – so, wie man es von einer normalen verwahrenden (custodial) Börse erwarten würde.
Klar, keine Nutzerfonds sind verschwunden. Das ist eine Erleichterung. Aber hier ist das Problem, das niemand zu erwähnen scheint: Die Smart-Contract-Leitplanken und die dezentrale Multi-Sig haben dabei nichts abgefangen. Kein automatisierter Sicherheitsmechanismus ist eingeschritten. Es waren Menschen, die manuell zugesehen haben – und dann alles per Hand abgeschaltet haben.
Das ist der Teil von Dusk, der mir im Kopf geblieben ist. Von außen: standardmäßig privat, sofortige Finalität, zk-alles. Aber in diesem Moment von Druck wirkte das echte Bild anders: eine Bridge, die das Team jederzeit pausieren kann, mit Blocklist-Rechten, die in Admin-Wallets liegen.
Bridges waren schon immer die Schwachstelle. Aber als ich dabei zugesehen habe, wie das auf Dusk abläuft – einem Projekt, das um das Entfernen von Vertrauen herum gebaut ist –, hat mich das nachdenklich gemacht. Wenn Dusk seinem „trustless“-Versprechen wirklich gerecht werden will, wird diese Bridge-Abhängigkeit früher oder später eine echte Lösung brauchen.
#dusk $DUSK @Dusk
