Eman098

ENA hat gerade einen Monster-Move hingelegt: +25% auf 0.1854, prallt kräftig von dem Tief bei 0.1349 ab, das vor ein paar Tagen entstanden ist. Das ist ein klassisches V-förmiges Reversal nach einem mühsamen Abwärtstrend.

Das Volumen erzählt aber die eigentliche Geschichte: Diese riesige grüne Kerze direkt, als der Kurs ausbrach, bestätigt, dass es kein Fakeout war—echtes Kaufen ist aufgetaucht. RSI(6) bei 87 schreit kurzfristig überkauft; RSI(14) bei 74 untermauert das. Ein Rücksetzer oder eine Konsolidierung hier wäre daher absolut nicht überraschend. Der MACD ist gerade bullisch gekreuzt und das Histogramm wird wieder grün, was die Bewegung unterstützt, aber sie ist frisch und noch nicht „reif“.

Ehrlich gesagt sieht das nach einem starken Momentum-Ausbruch aus, der eine Verschnaufpause verdient. Es hinterherzulaufen bei 0.1854 ist riskant—abwarten und auf einen Pullback Richtung 0.165 bis 0.170 für den Einstieg zu setzen wirkt schlauer als den oberen Bereich dieser Kerze zu kaufen.
$ENA

#dusk $DUSK @Dusk
Was mir beim Durchgehen der Dusk-Dokumentation aufgefallen ist: Es existieren nur zwei Verträge. Beim Genesis-Prozess gibt es den Stake-Vertrag und den Transfer-Vertrag. Alles andere, einschließlich DuskVM und DuskEVM, sitzt auf diesen auf.

Das ist eine merkwürdige Konzentration für eine Kette, die darauf ausgelegt ist, regulierte Assets abzuwickeln. Daher wollte ich prüfen, was diese beiden tatsächlich tun und ob sie später geändert werden können.

Der Stake-Vertrag verfolgt Provisioner: wie viel sie staken, wann Belohnungen reifen und wann Slashing greift. Der Transfer-Vertrag verarbeitet sowohl öffentliche (Moonlight) als auch verschlüsselte (Phoenix) Guthaben und ist der einzige Ort, an dem tatsächlich eine Vertrags-zu-Vertrags-Zahlungsbewegung stattfindet. Jede Ausführungsumgebung wird für die Abwicklung und Datenverfügbarkeit über ihn geleitet, wie es die aktuelle Dokumentation beschreibt.

Warum das wichtig ist: Wenn du auf DuskEVM aufbaust oder Assets über Dusk Trade ausgibst, vertraust du nicht nur auf die Logik deines eigenen Vertrags. Du vertraust darauf, dass diese beiden Genesis-Verträge dauerhaft korrekt funktionieren, da sie die Abwicklungsbasis sind, unter der alles andere liegt.

Das konnte ich nicht eindeutig klären. Die Dokumente beschreiben, dass diese Verträge im Laufe der Zeit refaktorisiert wurden: Der Staking-Vertrag wurde neu gebaut, um ein Speicherproblem zu beheben, und später haben technische Updates seine Event-Struktur verändert. Sie sind also offensichtlich nicht im Sinne von „unveränderlich“ beim Genesis-Zeitpunkt eingefroren.

Unklar für mich ist der tatsächliche Upgrade-Pfad: Ist er diskretionär (das Protokollteam liefert ein Netzwerk-Upgrade) oder gibt es einen formalen On-Chain-Governance-Schritt, bei dem Provisioner vor Änderungen an der Genesis-Vertragslogik abstimmen? Die Dokumente, die ich gefunden habe, beschreiben, was die Verträge tun, aber nicht, wie Änderungen daran autorisiert werden.

Für eine Kette, die sich als Plattform für institutionelle Abwicklung positioniert, sollte diese Unterscheidung zwischen team-autorisertem Upgrade und von Provisionern bestätigtem Upgrade irgendwo explizit dokumentiert sein.

Hat jemand gesehen, wo @Dusk den tatsächlichen Authorization-Prozess für Änderungen an Genesis-Verträgen spezifiziert?

$DUSK #dusk

#dusk $DUSK @Dusk
Was mir aufgefallen ist, war nicht Dusk's Compliance-Kommunikation – sondern was eine unabhängige Wirtschaftsprüfungsgesellschaft gefunden hat: Es saß in „Dusk Plonk“ das Beweissystem zur Absicherung des abgeschirmten Transaktionsmodells von Phoenix @Dusk auf DuskDS.

Das Prinzip: Phoenix verwendet PLONK-Proofs, sodass ein Spend verifiziert werden kann, ohne Guthaben offenzulegen. Der Verifizierer soll eine Sammlung von Polynom-Commitments anhand eines vertrauenswürdigen Verifizierer-Schlüssels prüfen, bevor er irgendeinen Proof als gültig akzeptiert.

Der Teil, den ich prüfen wollte: Laut einem Vermerk einer Sicherheitsfirma wurden vier dieser Selector-Bewertungen nie tatsächlich gegen ihre Commitments geprüft – der Verifizierer hat sie verbraucht, ohne sie zu validieren. Theoretisch könnte diese Lücke es ermöglichen, dass ein gefälschter Proof als legitim durchgeht.

Warum das wichtig ist: Das liegt direkt unter dem geschirmten Pool, aus dem die regulierten Asset-Flows ihre Privatsphäre erben sollen. Ein gefälschter Proof in einem intransparenten Notizsystem ist nachträglich schwer zu erkennen – genau darum geht es bei „Shilding“.

Das Detail, das die meisten übersehen würden: Die Korrektur wurde Mitte Februar 2026 eingeführt, bevor die öffentliche Offenlegung im April erfolgte – also gefixt, nicht ausgenutzt, basierend auf dem, was veröffentlicht wurde. Unklar für mich ist jedoch, ob das durch die interne Prüfung von Dusk entdeckt wurde oder ob es zuerst von einer externen Partei gefunden wurde, und wie dieser Zeitplan den Partnern kommuniziert wurde, die auf diese Schicht angewiesen sind.
Bedeutet „Audited“ viel, wenn der Fix zwei Monate vor der Offenlegung erfolgte?

$DUSK #dusk

#dusk $DUSK @Dusk
Was mich an NPEX aufgefallen ist, war nicht die Zahl von 300 Mio. € – sondern dass NPEX bereits über eine MTF-Lizenz, eine Broker-Lizenz und eine ECSP-Lizenz nach niederländischen/EU-Regeln verfügt und Dusk direkt auf diesen bestehenden regulatorischen Stack aufbaut, statt die Regulierungsbehörden um einen neuen, kryptospezifischen Rahmen zu bitten.
Der Teil, den ich prüfen wollte, war daher: Wie bleibt ein On-Chain-Trade tatsächlich konform mit den Anleger-Eignungsregeln eines MTF, ohne dass ein zentraler Gatekeeper jede Transaktion überprüft?

Der Mechanismus läuft – soweit es die aktuellen Dokumente beschreiben – über die selektive Offenlegung von Citadel.
Dabei weist ein Investor einen konkreten Anspruch nach: seinen Wohnsitz-/Akkreditierungsstatus sowie die KYC-Abschlusserklärung als Zero-Knowledge-Proof, der an seine Wallet gebunden ist, ohne das zugrunde liegende Dokument oder personenbezogene Daten offenzulegen. Das Gegenüber bzw. die Protokoll-Logik verifiziert den Proof – nicht die Daten selbst.

Warum das speziell für einen regulierten Handelsplatz wichtig ist: NPEX darf rechtlich gesehen nicht einfach jedem den Handel mit bestimmten Instrumenten erlauben. Historisch bedeutete das, dass ein zentraler Broker vor jeder Order die Ausweise prüfte. Hier wird die Eignung zu einem wiederverwendbaren kryptografischen Berechtigungsnachweis statt zu einer wiederholten manuellen Kontrolle – und genau das macht eine sofortige Abwicklung für regulierte Vermögenswerte plausibel, statt nur eine Marketingaussage zu sein.

Was ich anhand der aktuellen Dokumentation nicht bestätigen konnte, ist, wie die Sperrung/Aussetzung von Credentials in der Praxis funktioniert, wenn sich der Eligibility-Status einer Person ändert (z. B. ein Wohnsitzwechsel, ein Sanktionshinweis). Wie schnell wird das in Wallets, die Proofs aus dem alten Status besitzen, wirksam, und erfordert das, dass der Investor erneut nachweisen muss – oder kann der Aussteller die Proofs einseitig ungültig machen?

Diese Lücke – also die Aktualität/Freshness eines Disclosure-Proofs im Verhältnis zu den Echtzeit-Erwartungen einer Regulierungsbehörde – scheint der eigentliche Test dafür zu sein, ob das über ein einziges Pilot-Exchange hinaus skaliert. Wer sich mit der Citadel-Spezifikation auskennt, weiß, wie Revocation derzeit gehandhabt wird?

$DUSK #dusk @Dusk

#dusk $DUSK @Dusk
Was meine Aufmerksamkeit auf sich gezogen hat, war nicht die Zero-Knowledge-Seite von Dusk, die die meiste Beachtung bekommt – sondern ein kleineres Detail daran, wie ein Block tatsächlich final wird.

Ich wollte prüfen, wie Succinct Attestation, das permissionless, committee-basierte Proof-of-Stake-Konsensprotokoll von DuskDS, eine Transaktion konkret bestätigt, denn in diesem Bereich wird sofortige Abwicklung gern locker herumgeworfen.

Jede Runde durchläuft drei Schritte: Ein Provisioner schlägt einen Kandidatenblock vor und broadcastet ihn, ein Komitee validiert ihn und ein zweites Komitee ratifiziert diese Validierung und finalisiert den Block. Erst nachdem beide Komitees zustimmen, geht der Block weiter.

Interessant ist, dass @Dusk Finalität nicht als ein einziges binäres Ereignis behandelt. Ein Block gilt als „Accepted“, sobald er alle drei Schritte passiert. „Confirmed“, wenn später folgende Blöcke darauf aufbauen. „Stable“, sobald er ausreichend tief eingebettet ist, und schließlich „Final“ – deterministisch und kryptografisch garantiert, also so, dass er nicht mehr zurückgedreht werden kann.

Für regulierte Abwicklung ist diese gestufte Unterscheidung wichtiger als die rohe Geschwindigkeit. Ein Custodian braucht nicht nur eine schnelle Transaktion – er braucht einen definierten Punkt, an dem Unumkehrbarkeit nachweisbar ist, nicht nur angenommen.

Was ich gern geklärt hätte, ist das Verhalten unter dauerhaft hoher Last. Zwei separate Komitees, die sich einig sind, fügen einen Koordinationsschritt hinzu, den einzelne Proposer-Ketten überspringen. Wenn sich das Provisioner-Set und die Stake-Verteilung vergrößern: Bleibt die Ratifizierung schnell, oder wird die Komitee-Koordination selbst zur Engstelle?

Die Doku legt die Phasen und die Belohnungsaufteilung fest: 70 % für den Proposer, 5 %/5 % für die Validierungs- und Ratifizierungs-Komitees. Klar ist, was sie tun – nicht ausgeführt wird jedoch ein Durchsatz-Limit unter echter Netzüberlastung; getestet wird nur mit Testnet-Verhalten.

Hat jemand Committee-Auswahl oder Finality-Time-Daten von Dusk unter tatsächlicher, dauerhaft hoher Transaktionslast gesehen – statt nur von inaktiven Netzen?

$DUSK #Dusk

#dusk $DUSK @Dusk
Ich habe zwischen zwei Dusk-Dokumenten hin- und hergewechselt, die Datenschutz auf völlig unterschiedliche Weise beschreiben, und die Lücke zwischen ihnen ist die eigentliche Geschichte.

Zedger, Dusk's ursprüngliches reguliertes-Asset-Protokoll, läuft nativ auf DuskDS und basiert auf UTXO – also demselben Abrechnungsmodell, das Bitcoin verwendet. l
zur Einhaltung von Vorschriften erweitert. Hedger, sein Nachfolger, läuft auf DuskEVM und geht einen anderen Weg: Es kombiniert homomorphe Verschlüsselung (ElGamal über elliptische Kurven) mit Zero-Knowledge-Beweisen auf Basis eines hybriden UTXO-/Account-Modells.

Was mich dabei besonders angesprochen hat, ist, was diese Kombination tatsächlich für dich erkauft. Mit HE passieren Berechnungen direkt auf verschlüsselten Salden; niemand muss einen Wert entschlüsseln, um ihn hinzuzufügen oder abzuziehen. ZK-Beweise verifizieren anschließend, dass die Berechnung korrekt durchgeführt wurde, ohne die Eingaben offenzulegen. Salden und Übertragungsbeträge bleiben Ende-zu-Ende verschlüsselt, während das Netzwerk dennoch bestätigen kann, dass nichts gefälscht wurde.

Der Teil, den ich prüfen wollte: kostet dich das etwas im Vergleich zu Zedger? Laut den eigenen Materialien von @Dusk kann das account-basierte Modell der EVM nicht die volle Anonymität bieten, die eine UTXO-Schicht wie Zedger bereitstellt. Hedger gibt dir vertrauliche Salden und Nachvollziehbarkeit, aber nicht Unverknüpfbarkeit.

Also lautet die Abwägung nicht „nOt privacy vs. compliance“, sondern „privacy vs. developer surface“. Zedger bewahrt stärkere Anonymität, bleibt aber UTXO-nativ. Hedger opfert einen Teil davon für Plug-and-Play-EVM-Tooling.

Was ich trotzdem wissen würde: In einem regulierten Instrument, das sowohl Zedger auf DuskDS als auch Hedger auf DuskEVM berührt – welches Datenschutzniveau gilt tatsächlich bei der Abwicklung?

$DUSK #dusk

#dusk $DUSK @Dusk
Phoenix speichert Double-Spend-Beweise in einem Merkle-Baum von Notizen anstelle eines Konto-Ledgers nO sichtbare Guthaben, dennoch kann niemand denselben Output zweimal ausgeben. Ich wollte sehen, wie das in der Praxis tatsächlich zusammenpasst.

Phoenix behandelt jede Einheit von @Dusk als eine UTXO, die eine Notiz genannt wird. Jede Notiz lebt als Hash in einem Merkle-Baum. Das Ausgeben einer Notiz löscht sie nicht so funktionieren diese Bäume nicht. Stattdessen erzeugt das Ausgeben eine Nullifier-Zahl: ein Wert, der aus dem geheimen Schlüssel der Notiz abgeleitet wird und öffentlich erscheint, sobald er verwendet wurde. Das Netzwerk erfährt nie, welche Notiz dem Nullifier zugrunde lag, sondern nur, dass er jetzt ungültig ist. Wenn man versucht, dieselbe Notiz erneut zu verwenden, verrät der doppelte Nullifier sie sofort.

Dieses Design ist der Grund, warum Phoenix verborgen bleiben kann und dennoch durchsetzbar ist. Regulierte Finanzsysteme können keine mehrdeutige Abwicklung tolerieren, und Nullifier liefern deterministische Endgültigkeit, ohne dass Absender, Empfänger oder Betrag offengelegt werden. Ein View-Key ermöglicht es dem Besitzer, selektiv zu beweisen, was eine Notiz enthielt, sodass die Nachvollziehbarkeit nicht vollständig verloren geht sie wird nur an den Inhaber des Keys verschoben.

Was ich aus den Dokumenten nicht vollständig auflösen konnte: wie das Wachstum der Nullifier-Menge langfristig verwaltet wird und wie hoch der Beweise-Overhead ausfällt, wenn der Notizbaum mit anhaltendem institutionellem Volumen skaliert, statt unter Testbedingungen.

Echt neugierig hat jemand Durchsatzkennzahlen für Phoenix bei der Generierung von Beweisen unter echter Settlement-Last gesehen, nicht nur Testnet-Benchmarks?

$DUSK #dusk

#dusk $DUSK @Dusk

Ich habe zwei verschiedene Browserprofile für Arbeit und private Sachen – dieselbe Person, aber die Konten berühren einander niemals. Etwas Ähnliches spielt sich unter der Haube von DuskEVMs Privacy-Layer ab, und es ist ein fremdartigeres Design, als ich erwartet hatte.

Was mir beim Lesen von Hedgers Spezifikation aufgefallen ist: Ein Nutzer mit der Kennung @Dusk , der in diesem System arbeitet, hat nicht eine Adresse – sondern zwei. Eine normale EVM-Adresse für gewöhnliche Contract-Calls und eine separate Hedger-Adresse, die einen verschlüsselten Kontostand hält. Das Interessante daran ist, warum das nicht nur zur Schau dient.

Der Mechanismus Schritt für Schritt: Dein Hedger-Kontostand wird mit ElGamal über elliptische Kurven verschlüsselt (ein homomorphes Schema), sodass das Netzwerk verschlüsselte Beträge addieren und subtrahieren kann, ohne sie jemals zu entschlüsseln. Wenn du eine private Überweisung sendest, fügst du einen Zero-Knowledge-Beweis hinzu, der zeigt, dass die Mathematik stimmt: Eingaben passen zu Ausgaben, keine negativen Salden – ohne die tatsächlichen Zahlen offenzulegen. Die Compliance wird über Allowlisting gehandhabt, statt über allgemeine Transparenz, sodass einem Auditor Zugriff gegeben werden kann, ohne dass die ganze Kette es sieht.

Warum das wichtig ist: Das ist ein wirklich anderes Trade-off als bei den meisten Private-DeFi-Setups, die zwar die Transaktion verschleiern, dich aber innerhalb einer einzigen Identität arbeiten lassen. Das Trennen der öffentlichen Ausführungsidentität von der vertraulichen Kontostandsidentität bedeutet, dass eine Anwendung in normale EVM-Tooling für Logik einstecken kann und nur die Geldseite über den verschlüsselten Pfad routet.

Was ich aus den Dokumenten nicht vollständig klären konnte: Wie sollen die beiden Adressen auf der UX-Ebene verknüpft oder entkoppelt werden – wird das Binding einmalig beim Wallet-Setup gesetzt, pro Session oder pro Contract?
Das scheint die entscheidende Stelle zu sein, die bestimmt, ob sich das nahtlos anfühlt oder ob man für immer zwei separate Konten verwalten muss.

Hat das jemand tatsächlich mit Hedger auf Sepolia getestet – wie funktioniert dieses Binding in der Praxis?

$DUSK #dusk