Ich dachte, dass Moonlight und Phoenix auf der Architekturseite gleichberechtigt nebeneinander stehen, bedeutet, dass Nutzer des Mainnets heute noch frei zwischen öffentlichen Konten und gesperrten Transaktionen wählen können. Nach der weiteren Überprüfung des Boreas-Updates für @Dusk habe ich jedoch festgestellt: Nicht das Architekturdiagramm entscheidet darüber, ob Institutionen live gehen können, sondern welche Art von Transaktionen das aktuelle Netzwerk tatsächlich annimmt.
Das offizielle Update ist sehr eindeutig: Das Mainnet stellt am 10. Juni 2026 mit dem Boreas-Restart bei Block `4,414,095` die Annahme neuer Phoenix-Transaktionen ein; auch das Testnet wird am 7. August, bei Block `4,000,000`, deaktiviert. Moonlight ist das derzeit unterstützte Transaktionsmodell.
Wenn man es in einen Prozess einbaut, in dem eine Institution aus der Liquidität heraus eine begrenzte Anleihe kauft, zeigt sich der Unterschied sofort. Das Produktteam möchte möglicherweise Zahlungsbeträge und die Zuordnung zu Konten verbergen und gleichzeitig – je nach Berechtigung – Nachweise gegenüber dem Platz oder dem Audit-Partner offenlegen. Steht in der Live-Checkliste nur „Dusk unterstützt Phoenix“, würden Wallet-, Custody- und Abwicklungs-Systeme es erst ganz am Ende merken: Die Anschlussgrenzen im aktuellen Mainnet haben sich geändert, und die ursprünglich geplante Transaktionsfamilie kann nicht eingereicht werden.
Das bedeutet nicht, dass Dusk’ Datenschutzrichtung verschwunden ist. Die offizielle Website führt weiterhin Datenschutz, selektive Offenlegung und native ZK-Verträge als Kernfähigkeiten auf. Der Hedger auf DuskEVM bietet außerdem eine weitere geheime EVM-Route; allerdings hat die Website an dem Tag sowohl DuskEVM als auch Hedger als `Testnet` markiert. Daher müssen der historische Phoenix-, der native ZK-Fähigkeitsstatus, der Testnet-Hedger-Status und der Status der institutionell verfügbaren Produktions-Workflows getrennt ausgewiesen werden; sie dürfen nicht in einem einzigen Satz „Datenschutz unterstützt“ gegeneinander als Ersatz austauschbar werden.
Offizielle Unterlagen können weder belegen, dass Datenschutz-Workflows im Mainnet bereits in großem Maßstab laufen, noch können sie nachweisen, dass die Testnet-Fähigkeiten des Hedgers schon einen institutionellen SLA-Standard erreicht haben. Hier gibt es keinen Abkürzungs-„Sinn“, dass „je mehr Funktionsnamen, desto stärker die Adoption“.
Die nächsten Beobachtungen lassen nur vier Quittungen übrig: die neu erstellbaren geheimen Transaktionspfade im Mainnet, die Anzahl unterstützter Produktions-Wallets und Custody, die tatsächliche Menge an ausgeführten geheimen Contract-Ausführungen sowie die Erfolgsquote bei autorisierten Offenlegungen. Auf der Token-Ebene erweitere ich die Nutzen-Story nicht weiter: Der Dokumentations-Anker bei $DUSK bleibt die Bezahlung der Ausführungsgebühren und das Netzwerk-Staking; erst wenn verfügbare Pfade eine fortlaufende Ausführung tragen, lohnt es sich, über Anforderungen zur Beobachtbarkeit zu sprechen.
Was du als nächsten Schritt für am wichtigsten hältst, ist entscheidend: A die Wiederherstellung nativer gesperrter Transaktionen, B die Weiterentwicklung des Hedger in die Produktion – oder C zuerst die Veröffentlichung einer korrekten Matrix zur Verfügbarkeit? #dusk
Das offizielle Update ist sehr eindeutig: Das Mainnet stellt am 10. Juni 2026 mit dem Boreas-Restart bei Block `4,414,095` die Annahme neuer Phoenix-Transaktionen ein; auch das Testnet wird am 7. August, bei Block `4,000,000`, deaktiviert. Moonlight ist das derzeit unterstützte Transaktionsmodell.
Wenn man es in einen Prozess einbaut, in dem eine Institution aus der Liquidität heraus eine begrenzte Anleihe kauft, zeigt sich der Unterschied sofort. Das Produktteam möchte möglicherweise Zahlungsbeträge und die Zuordnung zu Konten verbergen und gleichzeitig – je nach Berechtigung – Nachweise gegenüber dem Platz oder dem Audit-Partner offenlegen. Steht in der Live-Checkliste nur „Dusk unterstützt Phoenix“, würden Wallet-, Custody- und Abwicklungs-Systeme es erst ganz am Ende merken: Die Anschlussgrenzen im aktuellen Mainnet haben sich geändert, und die ursprünglich geplante Transaktionsfamilie kann nicht eingereicht werden.
Das bedeutet nicht, dass Dusk’ Datenschutzrichtung verschwunden ist. Die offizielle Website führt weiterhin Datenschutz, selektive Offenlegung und native ZK-Verträge als Kernfähigkeiten auf. Der Hedger auf DuskEVM bietet außerdem eine weitere geheime EVM-Route; allerdings hat die Website an dem Tag sowohl DuskEVM als auch Hedger als `Testnet` markiert. Daher müssen der historische Phoenix-, der native ZK-Fähigkeitsstatus, der Testnet-Hedger-Status und der Status der institutionell verfügbaren Produktions-Workflows getrennt ausgewiesen werden; sie dürfen nicht in einem einzigen Satz „Datenschutz unterstützt“ gegeneinander als Ersatz austauschbar werden.
Offizielle Unterlagen können weder belegen, dass Datenschutz-Workflows im Mainnet bereits in großem Maßstab laufen, noch können sie nachweisen, dass die Testnet-Fähigkeiten des Hedgers schon einen institutionellen SLA-Standard erreicht haben. Hier gibt es keinen Abkürzungs-„Sinn“, dass „je mehr Funktionsnamen, desto stärker die Adoption“.
Die nächsten Beobachtungen lassen nur vier Quittungen übrig: die neu erstellbaren geheimen Transaktionspfade im Mainnet, die Anzahl unterstützter Produktions-Wallets und Custody, die tatsächliche Menge an ausgeführten geheimen Contract-Ausführungen sowie die Erfolgsquote bei autorisierten Offenlegungen. Auf der Token-Ebene erweitere ich die Nutzen-Story nicht weiter: Der Dokumentations-Anker bei $DUSK bleibt die Bezahlung der Ausführungsgebühren und das Netzwerk-Staking; erst wenn verfügbare Pfade eine fortlaufende Ausführung tragen, lohnt es sich, über Anforderungen zur Beobachtbarkeit zu sprechen.
Was du als nächsten Schritt für am wichtigsten hältst, ist entscheidend: A die Wiederherstellung nativer gesperrter Transaktionen, B die Weiterentwicklung des Hedger in die Produktion – oder C zuerst die Veröffentlichung einer korrekten Matrix zur Verfügbarkeit? #dusk