Binance Square
Salar_Ghazi
5.2k Beiträge

Salar_Ghazi

395 Following
19.3K+ Follower
4.2K+ Like gegeben
Beiträge
PINNED
·
--
Bullisch
Übersetzung ansehen
#dusk $DUSK @Dusk_Foundation for a few hours and the thing that keeps pulling my attention isn't the ZK architecture or the RWA narrative it's what the August 16th bridge incident actually revealed about how the network is being used. Monitoring flagged suspicious behavior on a team-managed wallet tied to bridge operations. The team paused bridge services, recycled the affected addresses, and coordinated with Binance after identifying that part of the flow touched their platform. What struck me isn't the incident itself bridge ops getting flagged is almost routine in 2026 it's what it implies about the current architecture. The team was quick to clarify this was not a protocol-level issue on DuskDS, and that mainnet continued operating normally. Meaning the network held, but the operational layer the bridge wallet was the weak point. That's a meaningful distinction. My small surprise Dusk markets itself heavily on institutional-grade compliance and privacy, yet the bridge is still relying on team-managed wallets for operational flow. That feels like a temporary design choice they haven't fully replaced yet. Bridge services remain temporarily paused while a broader hardening pass is completed. I don't know the full scope of what that means whether it's a quick patch or a structural redesign. Which raises the question I can't answer: how much of Dusk's cross-chain volume was flowing through this single bridge operational wallet, and what does that concentration say about how decentralized the infrastructure actually is right now? $PROM $ONG Team-managed bridge wallets acceptable for an "institutional-grade" project?
#dusk $DUSK @Dusk for a few hours and the thing that keeps pulling my attention isn't the ZK architecture or the RWA narrative it's what the August 16th bridge incident actually revealed about how the network is being used.

Monitoring flagged suspicious behavior on a team-managed wallet tied to bridge operations. The team paused bridge services, recycled the affected addresses, and coordinated with Binance after identifying that part of the flow touched their platform.

What struck me isn't the incident itself bridge ops getting flagged is almost routine in 2026 it's what it implies about the current architecture. The team was quick to clarify this was not a protocol-level issue on DuskDS, and that mainnet continued operating normally. Meaning the network held, but the operational layer the bridge wallet was the weak point. That's a meaningful distinction.

My small surprise Dusk markets itself heavily on institutional-grade compliance and privacy, yet the bridge is still relying on team-managed wallets for operational flow. That feels like a temporary design choice they haven't fully replaced yet.
Bridge services remain temporarily paused while a broader hardening pass is completed. I don't know the full scope of what that means whether it's a quick patch or a structural redesign.

Which raises the question I can't answer: how much of Dusk's cross-chain volume was flowing through this single bridge operational wallet, and what does that concentration say about how decentralized the infrastructure actually is right now?
$PROM
$ONG

Team-managed bridge wallets acceptable for an "institutional-grade" project?
Yes, it's transitional
100%
No, it's a red flag
0%
Depends on timeline
0%
Neutral
0%
1 Stimmen • Abstimmung beendet
PINNED
#dusk $DUSK @Dusk_Foundation der eigentliche Node-Client hinter Dusk, nicht die Marketing-Seitenversion. Zurück im Mai wurde still und leise ein Rusk-Release ausgeliefert, das etwas namens http.policy ACL-Regeln, Endpoint-Rate-Limits und ein ganzes Framework umfasste, mit dem der Node auf Protokollebene spezifischen Traffic verweigern oder drosseln kann. Als Spezifikationszeile gelesen, wirkte es wie langweilige Betriebsroutine. Doch am 16. August markierte das Team von Dusk verdächtige Aktivitäten auf einer Bridge, die mit einer verknüpften Wallet verbunden war, und hatte innerhalb weniger Stunden eine Web-Wallet-Empfänger-Blockliste aufgesetzt, um Überweisungen an die als verdächtig markierten Adressen zu stoppen – genau derselbe Mechanismus, live, unter Druck. Das ist der Teil, der hängen blieb. $DUSK wird als „Privacy + Compliance“ vermarktet, im Futur, bald verfügbar. Aber die tatsächliche erste reale Nutzung dieser Durchsetzungsschicht war keine nutzerseitige Privacy-Funktion – es ging darum, dass das Team die Bridge schützt. Infrastruktur, die für Regulierungsbehörden gebaut wurde, endete als Incident-Response-Tool, bevor sie jemals eine geschützte Transaktion eines Endnutzers berührt hat. Keine Beschwerde, nur ein Hinweis darauf, in welcher Reihenfolge Dinge freigeschaltet werden. Ich bin hineingegangen in der Erwartung, dass Rusk „die VM“ sei, und bin mit dem Gefühl herausgekommen, dass es eher eine Policy-Engine ist, die nebenbei auch Konsens ausführt. Wer bekommt sonst noch Zugang zu dieser Blocklisten-Logik, bevor sie jemals öffentlich dokumentiert wird.
#dusk $DUSK @Dusk der eigentliche Node-Client hinter Dusk, nicht die Marketing-Seitenversion.

Zurück im Mai wurde still und leise ein Rusk-Release ausgeliefert, das etwas namens http.policy ACL-Regeln, Endpoint-Rate-Limits und ein ganzes Framework umfasste, mit dem der Node auf Protokollebene spezifischen Traffic verweigern oder drosseln kann. Als Spezifikationszeile gelesen, wirkte es wie langweilige Betriebsroutine.

Doch am 16. August markierte das Team von Dusk verdächtige Aktivitäten auf einer Bridge, die mit einer verknüpften Wallet verbunden war, und hatte innerhalb weniger Stunden eine Web-Wallet-Empfänger-Blockliste aufgesetzt, um Überweisungen an die als verdächtig markierten Adressen zu stoppen – genau derselbe Mechanismus, live, unter Druck. Das ist der Teil, der hängen blieb. $DUSK wird als „Privacy + Compliance“ vermarktet, im Futur, bald verfügbar. Aber die tatsächliche erste reale Nutzung dieser Durchsetzungsschicht war keine nutzerseitige Privacy-Funktion – es ging darum, dass das Team die Bridge schützt.

Infrastruktur, die für Regulierungsbehörden gebaut wurde, endete als Incident-Response-Tool, bevor sie jemals eine geschützte Transaktion eines Endnutzers berührt hat.

Keine Beschwerde, nur ein Hinweis darauf, in welcher Reihenfolge Dinge freigeschaltet werden. Ich bin hineingegangen in der Erwartung, dass Rusk „die VM“ sei, und bin mit dem Gefühl herausgekommen, dass es eher eine Policy-Engine ist, die nebenbei auch Konsens ausführt. Wer bekommt sonst noch Zugang zu dieser Blocklisten-Logik, bevor sie jemals öffentlich dokumentiert wird.
Übersetzung ansehen
join guys
join guys
超人不会飞2020
·
--
[Wiederholung] 🎙️ Der 12. Tag meines BTC-100U-DCA mit Superhelden, DUSK: Long oder Short?
02 h 23 m 12 s · 7.8k Zuhörer
🎙️ 超人100U定投BTC的第12天,DUSK多or空
cover
Beenden
02 h 23 m 12 s
7.5k
17
15
🎙️ 建设币安广场,定投BNB|周三,BTC还是没能稳在8万,接下来大家觉得行情该怎么走?来聊聊~
cover
Beenden
05 h 21 m 38 s
9.4k
41
38
·
--
Bullisch
$BTC blinkt ein Setup, das Händler nicht ignorieren sollten. Der nächste Move könnte schnell kommen. $BTC zeigt starke bullische Dynamik, wobei sich die Struktur schön aufbaut. Long Watch — Marktkontext Einstieg: $80.500–$80.700 Ziel 1: $81.000 Ziel 2: $81.270 Ziel 3: $81.600 Ziel 4: $82.000 Stop Loss: $80.100 $BTC ist stark vom Bereich $80,1K zurückgesprungen und reklamiert die $80,5K-Zone zurück. Wenn Käufer über $81,27K drängen, könnte sich die Aufwärtsstruktur beschleunigen. #Write2Earn {future}(BTCUSDT)
$BTC blinkt ein Setup, das Händler nicht ignorieren sollten. Der nächste Move könnte schnell kommen.

$BTC zeigt starke bullische Dynamik, wobei sich die Struktur schön aufbaut.

Long Watch — Marktkontext

Einstieg: $80.500–$80.700
Ziel 1: $81.000
Ziel 2: $81.270
Ziel 3: $81.600
Ziel 4: $82.000
Stop Loss: $80.100

$BTC ist stark vom Bereich $80,1K zurückgesprungen und reklamiert die $80,5K-Zone zurück. Wenn Käufer über $81,27K drängen, könnte sich die Aufwärtsstruktur beschleunigen.
#Write2Earn
·
--
Bullisch
Übersetzung ansehen
Guys, $XRP is setting up for a move don’t ignore this zone. $XRP is showing strong bullish momentum, with the structure building up nicely. Entry: $1.47–$1.49 Target 1: $1.52 Target 2: $1.55 Target 3: $1.60 Target 4: $1.65 Stop Loss: $1.43 XRP is holding above the $1.45 area after a strong consolidation phase, while buyers are starting to push back toward the $1.50 resistance. A clean break above $1.50 could open the way toward the higher targets. #Write2Earn {future}(XRPUSDT) {future}(PORTALUSDT)
Guys, $XRP is setting up for a move don’t ignore this zone.

$XRP is showing strong bullish momentum, with the structure building up nicely.

Entry: $1.47–$1.49
Target 1: $1.52
Target 2: $1.55
Target 3: $1.60
Target 4: $1.65
Stop Loss: $1.43

XRP is holding above the $1.45 area after a strong consolidation phase, while buyers are starting to push back toward the $1.50 resistance. A clean break above $1.50 could open the way toward the higher targets.
#Write2Earn

·
--
Bullisch
Übersetzung ansehen
$BNB Long Watch Entry: $692–696 Target 1: $705 Target 2: $715 Stop Loss: $686 $BNB is holding above the $690 support zone after a strong recovery from the $680s. Price is consolidating near $696, while the recent rejection around $705 remains the key resistance. A clean hold above $692–696 could set up another push toward $705 and potentially $715. Losing $690 would weaken the bullish structure. $SPK {future}(SPKUSDT) {future}(PORTALUSDT) {future}(BNBUSDT)
$BNB Long Watch
Entry: $692–696
Target 1: $705
Target 2: $715
Stop Loss: $686

$BNB is holding above the $690 support zone after a strong recovery from the $680s. Price is consolidating near $696, while the recent rejection around $705 remains the key resistance.

A clean hold above $692–696 could set up another push toward $705 and potentially $715. Losing $690 would weaken the bullish structure.
$SPK

·
--
Bullisch
$ETH hält die Erholungsstruktur im 4H-Chart. Der Kurs prallte stark aus der Zone $2.360–$2.400 ab und konsolidiert nun um $2.438, nachdem es bei $2.470 abgelehnt wurde. Wichtige Niveaus: Entry: $2.420–$2.440 Ziel 1: $2.480 Ziel 2: $2.520 Stop Loss: Unter $2.390 Ein sauberer 4H-Ausbruch über $2.480 könnte den Weg in Richtung $2.520 freimachen. Ein Verlust von $2.400 würde die bullische Set-up-Situation abschwächen. #Write2Earn $PORTAL {future}(PORTALUSDT) $SPK {future}(SPKUSDT)
$ETH hält die Erholungsstruktur im 4H-Chart.

Der Kurs prallte stark aus der Zone $2.360–$2.400 ab und konsolidiert nun um $2.438, nachdem es bei $2.470 abgelehnt wurde.

Wichtige Niveaus:
Entry: $2.420–$2.440
Ziel 1: $2.480
Ziel 2: $2.520
Stop Loss: Unter $2.390

Ein sauberer 4H-Ausbruch über $2.480 könnte den Weg in Richtung $2.520 freimachen. Ein Verlust von $2.400 würde die bullische Set-up-Situation abschwächen.
#Write2Earn
$PORTAL
$SPK
·
--
Bullisch
#dusk @Dusk_Foundation $DUSK dev-Dokumentation diese Woche, nachdem das DuskEVM-Testnet am 10. August live ging. Was mir aufgefallen ist, ist nicht der Launch an sich – sondern die Weggabelung, die er für Entwickler schafft. DuskEVM läuft auf OP Stack, wird auf DuskDS „settled“ und ermöglicht dir, Solidity mit Hardhat/Foundry sowie den Standard-EVM-Wallets bereitzustellen – mit all den vertrauten Tools. DuskVM hingegen baut direkt auf Dusk’ eigenem Ausführungsmodell auf: Rust/WASM-Contracts, native Transaktionsmodelle, protokollbasierten Asset-Typen und ZK-Fähigkeiten. Gleiche zugrunde liegende Chain, aber zwei völlig unterschiedliche Entwicklungsideologien. Was mich überrascht hat: Die Doku ist ungewöhnlich ehrlich darüber, wann man DuskEVM nicht verwenden sollte. Sie sagen ausdrücklich, dass man natives Dusk nutzen sollte, wenn man Privatsphäre, ZK-Smart-Contracts, vertrauliche Assets oder eine benutzerdefinierte Ausführung benötigt. Die meisten L2s stellen ihre eigenen Grenzen nicht so transparent freiwillig dar. Das Testnet ging Mitte August live. Du kannst frühe Contract-Deployments auf Blockscout (dem Explorer von DuskEVM) überprüfen. Ich habe noch nicht bestätigt, wie viele unabhängige Entwickler tatsächlich deployed haben – im Vergleich zu den eigenen Test-Contracts des Teams. Diese Unterscheidung ist wichtig, und ich kann das noch nicht sicher sagen. TVL liegt unter 1 Mio. USD und das DApp-Ökosystem ist dünn. Die eigentliche Frage lautet: Holt DuskEVM Solidity-Entwickler ins Boot, die sonst nie Rust anfassen würden – oder zieht Dusk’ Privacy-Story nur Builder an, die bereit sind, native zu gehen?
#dusk @Dusk $DUSK dev-Dokumentation diese Woche, nachdem das DuskEVM-Testnet am 10. August live ging. Was mir aufgefallen ist, ist nicht der Launch an sich – sondern die Weggabelung, die er für Entwickler schafft.

DuskEVM läuft auf OP Stack, wird auf DuskDS „settled“ und ermöglicht dir, Solidity mit Hardhat/Foundry sowie den Standard-EVM-Wallets bereitzustellen – mit all den vertrauten Tools. DuskVM hingegen baut direkt auf Dusk’ eigenem Ausführungsmodell auf: Rust/WASM-Contracts, native Transaktionsmodelle, protokollbasierten Asset-Typen und ZK-Fähigkeiten. Gleiche zugrunde liegende Chain, aber zwei völlig unterschiedliche Entwicklungsideologien.

Was mich überrascht hat: Die Doku ist ungewöhnlich ehrlich darüber, wann man DuskEVM nicht verwenden sollte. Sie sagen ausdrücklich, dass man natives Dusk nutzen sollte, wenn man Privatsphäre, ZK-Smart-Contracts, vertrauliche Assets oder eine benutzerdefinierte Ausführung benötigt. Die meisten L2s stellen ihre eigenen Grenzen nicht so transparent freiwillig dar.

Das Testnet ging Mitte August live. Du kannst frühe Contract-Deployments auf Blockscout (dem Explorer von DuskEVM) überprüfen. Ich habe noch nicht bestätigt, wie viele unabhängige Entwickler tatsächlich deployed haben – im Vergleich zu den eigenen Test-Contracts des Teams. Diese Unterscheidung ist wichtig, und ich kann das noch nicht sicher sagen.

TVL liegt unter 1 Mio. USD und das DApp-Ökosystem ist dünn. Die eigentliche Frage lautet: Holt DuskEVM Solidity-Entwickler ins Boot, die sonst nie Rust anfassen würden – oder zieht Dusk’ Privacy-Story nur Builder an, die bereit sind, native zu gehen?
·
--
Bullisch
#dusk @Dusk_Foundation $DUSK architektur im Detail, wie vertrauliche Smart Contracts unter dem XSC-Standard funktionieren, und eine Einzelheit zieht mich immer wieder zurück. Dusk positioniert sich als die erste Blockchain mit nativen vertraulichen Smart Contracts: Ausführungslogik, Gegenparteien und Beträge sind standardmäßig verborgen. Nicht in eine Privacy-Layer „darüber“ eingewickelt, sondern direkt im Basisausführungsumfeld eingebaut. Das ist zumindest die architektonische Behauptung. Was mich am 16. August wirklich zum Nachdenken gebracht hat: Das Dusk-Team erkannte verdächtige Aktivitäten, die mit einer vom Team verwalteten Bridge-Wallet zusammenhingen. Es pausierte Bridge-Services, deaktivierte zugehörige Adressen und koordinierte sich mit Binance, nachdem ein Teil des Ablaufs deren Plattform berührt hatte. Keine Benutzergelder seien betroffen gewesen, sagen sie. Aber lies es genau: Das war kein Protokollfehler. Es handelte sich um Infrastruktur außerhalb der Kette – eine Off-Chain-Bridge. Die L1 selbst blieb sauber. Und genau diese Spannung ist interessant. Das Team bestätigte ausdrücklich, dass der Vorfall kein Problem auf Protokollebene in DuskDS, der nativen Chain, war. Das bedeutet: Die vertrauliche Ausführungsschicht hat das getan, wofür sie vorgesehen ist. Die Schwachstelle lag genau dort, wo sie in solchen Fällen immer liegt – bei der Bridge, nicht bei der Chain. Ehrlich gesagt hatte ich nicht erwartet, dass sie das so schnell eindämmen. Das hat mich ein wenig überrascht. Was ich nicht bestätigen kann: Wie viele Transaktionen tatsächlich in dem Zeitraum durchliefen und ob irgendwelche geschützten Contract-Interaktionen auf der nativen Seite betroffen waren. Diese Daten sind nicht leicht lesbar – und genau das ist gewissermaßen der Sinn vertraulicher Contracts. Gleichzeitig macht es eine unabhängige Verifikation schwieriger. Die Bridge bleibt geschlossen, bis eine vollständige Sicherheitsprüfung abgeschlossen ist. In der Zwischenzeit ist DuskEVM noch im Anmarsch. Wie sich diese beiden Zeitpläne zueinander verhalten, lohnt sich genau zu beobachten…
#dusk @Dusk $DUSK architektur im Detail, wie vertrauliche Smart Contracts unter dem XSC-Standard funktionieren, und eine Einzelheit zieht mich immer wieder zurück.

Dusk positioniert sich als die erste Blockchain mit nativen vertraulichen Smart Contracts: Ausführungslogik, Gegenparteien und Beträge sind standardmäßig verborgen. Nicht in eine Privacy-Layer „darüber“ eingewickelt, sondern direkt im Basisausführungsumfeld eingebaut. Das ist zumindest die architektonische Behauptung.

Was mich am 16. August wirklich zum Nachdenken gebracht hat: Das Dusk-Team erkannte verdächtige Aktivitäten, die mit einer vom Team verwalteten Bridge-Wallet zusammenhingen. Es pausierte Bridge-Services, deaktivierte zugehörige Adressen und koordinierte sich mit Binance, nachdem ein Teil des Ablaufs deren Plattform berührt hatte. Keine Benutzergelder seien betroffen gewesen, sagen sie. Aber lies es genau: Das war kein Protokollfehler. Es handelte sich um Infrastruktur außerhalb der Kette – eine Off-Chain-Bridge.
Die L1 selbst blieb sauber.

Und genau diese Spannung ist interessant. Das Team bestätigte ausdrücklich, dass der Vorfall kein Problem auf Protokollebene in DuskDS, der nativen Chain, war. Das bedeutet: Die vertrauliche Ausführungsschicht hat das getan, wofür sie vorgesehen ist. Die Schwachstelle lag genau dort, wo sie in solchen Fällen immer liegt – bei der Bridge, nicht bei der Chain.

Ehrlich gesagt hatte ich nicht erwartet, dass sie das so schnell eindämmen. Das hat mich ein wenig überrascht.

Was ich nicht bestätigen kann: Wie viele Transaktionen tatsächlich in dem Zeitraum durchliefen und ob irgendwelche geschützten Contract-Interaktionen auf der nativen Seite betroffen waren. Diese Daten sind nicht leicht lesbar – und genau das ist gewissermaßen der Sinn vertraulicher Contracts. Gleichzeitig macht es eine unabhängige Verifikation schwieriger.

Die Bridge bleibt geschlossen, bis eine vollständige Sicherheitsprüfung abgeschlossen ist. In der Zwischenzeit ist DuskEVM noch im Anmarsch. Wie sich diese beiden Zeitpläne zueinander verhalten, lohnt sich genau zu beobachten…
·
--
Bullisch
#dusk @Dusk_Foundation $DUSK Transaktionsdaten auf duskexplorer.com heute. Eine Zahl hat mich kalt erwischt. Von 252 in den letzten 24 Stunden erfassten Transaktionen waren nur 21 Phoenix – das abgeschirmte ZK-Proof-Modell –, das angeblich die eigentliche Privacy-Layer dieses Netzwerks ist. Die anderen 231 liefen über Moonlight, das vollständig öffentliche, kontobasierte Modell. Das sind ungefähr 9% Phoenix-Nutzung auf einer Kette, die um Privatsphäre herum gebaut ist. Phoenix ist ein UTXO-basiertes Zero-Knowledge-Transaktionsmodell, das Beträge sowie Sender-Empfänger-Verknüpfungen und Bilanzänderungen über kryptografische Zusagen (Commitments) und Nullifier verbirgt. Phoenix 2.0 geht sogar noch einen Schritt weiter und ermöglicht konforme Privatsphäre, bei der die Absenderidentität für den Empfänger nachweisbar ist, ohne der Öffentlichkeit etwas offenzulegen – was angeblich das institutionelle Alleinstellungsmerkmal ist. Also, was erklärt die Lücke? Meine ehrliche Einschätzung: Phoenix ist schwerer. Jede Phoenix-Transaktion trägt einen PLONK-Proof, während Moonlight nur eine BLS-Signaturprüfung nutzt – weniger Rechenaufwand, schneller, günstiger. Die meisten aktuellen Nutzer sind wahrscheinlich nur am Staken, Konvertieren von Tokens oder bei Routine-Transfers. Privatsphäre hat ihren Preis, und nicht jeder zahlt ihn schon. Was ich im Explorer nicht erkennen kann, ist, ob die Phoenix-Transaktionen, die wir tatsächlich sehen, echte Nutzer widerspiegeln, die Privatsphäre suchen, oder ob es nur Wallet-Mekanik ist, die Gelder aus anderen Gründen durch den abgeschirmten Pool routet. Wenn die Phoenix-Nutzung so niedrig bleibt, während institutionelle Partner dazukommen: Hält die Privacy-Ansage stand oder wird sie still und leise optional?
#dusk @Dusk $DUSK Transaktionsdaten auf duskexplorer.com heute. Eine Zahl hat mich kalt erwischt.

Von 252 in den letzten 24 Stunden erfassten Transaktionen waren nur 21 Phoenix – das abgeschirmte ZK-Proof-Modell –, das angeblich die eigentliche Privacy-Layer dieses Netzwerks ist. Die anderen 231 liefen über Moonlight, das vollständig öffentliche, kontobasierte Modell.

Das sind ungefähr 9% Phoenix-Nutzung auf einer Kette, die um Privatsphäre herum gebaut ist.
Phoenix ist ein UTXO-basiertes Zero-Knowledge-Transaktionsmodell, das Beträge sowie Sender-Empfänger-Verknüpfungen und Bilanzänderungen über kryptografische Zusagen (Commitments) und Nullifier verbirgt. Phoenix 2.0 geht sogar noch einen Schritt weiter und ermöglicht konforme Privatsphäre, bei der die Absenderidentität für den Empfänger nachweisbar ist, ohne der Öffentlichkeit etwas offenzulegen – was angeblich das institutionelle Alleinstellungsmerkmal ist.

Also, was erklärt die Lücke? Meine ehrliche Einschätzung: Phoenix ist schwerer. Jede Phoenix-Transaktion trägt einen PLONK-Proof, während Moonlight nur eine BLS-Signaturprüfung nutzt – weniger Rechenaufwand, schneller, günstiger. Die meisten aktuellen Nutzer sind wahrscheinlich nur am Staken, Konvertieren von Tokens oder bei Routine-Transfers. Privatsphäre hat ihren Preis, und nicht jeder zahlt ihn schon.

Was ich im Explorer nicht erkennen kann, ist, ob die Phoenix-Transaktionen, die wir tatsächlich sehen, echte Nutzer widerspiegeln, die Privatsphäre suchen, oder ob es nur Wallet-Mekanik ist, die Gelder aus anderen Gründen durch den abgeschirmten Pool routet.
Wenn die Phoenix-Nutzung so niedrig bleibt, während institutionelle Partner dazukommen: Hält die Privacy-Ansage stand oder wird sie still und leise optional?
·
--
Bullisch
#dusk @Dusk_Foundation $DUSK explorer for a while and one number stuck with me in the last 24 hours out of 252 total transactions on the network 231 were Moonlight and only 21 were Phoenix that's roughly 92% public, 8% shielded. You can verify this yourself at duskexplorer.com right now. That ratio surprised me a little. The whole design premise of $DUSK is that Phoenix handles confidential financial activity private settlements hidden balances ZK proofs. Moonlight was added later, partly to satisfy exchange compliance requirements. But on-chain, actual users are overwhelmingly choosing the public path. Could be that Phoenix's UX overhead (UTXO notes, proof generation) is still friction enough to push casual users toward Moonlight. Could also be staking-related flows Moonlight supports the Stake contract and most delegation activity is public by nature. I'm honestly not sure which use case is dominating. What I can't confirm is whether that 21 Phoenix count reflects real privacy demand or just power users testing the model. There's no way to see who's behind those shielded notes which is kind of the point. The question I'm sitting with: if privacy is the core value proposition why is it the minority behavior at this stage?
#dusk @Dusk $DUSK explorer for a while and one number stuck with me in the last 24 hours out of 252 total transactions on the network 231 were Moonlight and only 21 were Phoenix that's roughly 92% public, 8% shielded. You can verify this yourself at duskexplorer.com right now.

That ratio surprised me a little. The whole design premise of $DUSK is that Phoenix handles confidential financial activity private settlements hidden balances ZK proofs. Moonlight was added later, partly to satisfy exchange compliance requirements. But on-chain, actual users are overwhelmingly choosing the public path.

Could be that Phoenix's UX overhead (UTXO notes, proof generation) is still friction enough to push casual users toward Moonlight. Could also be staking-related flows Moonlight supports the Stake contract and most delegation activity is public by nature. I'm honestly not sure which use case is dominating.

What I can't confirm is whether that 21 Phoenix count reflects real privacy demand or just power users testing the model. There's no way to see who's behind those shielded notes which is kind of the point.
The question I'm sitting with: if privacy is the core value proposition why is it the minority behavior at this stage?
·
--
Bullisch
#dusk $DUSK @Dusk_Foundation nachdem das DuskEVM-Testnetz am 10. August live gegangen ist. Die Schlagzeile lautet EVM-Kompatibilität Solidity, Hardhat, vertraute Tools. Gut. Aber was mich tatsächlich aufmerksam gemacht hat, ist eine Ebene tiefer Hedger. Hedger ist Dusk' Privacy-Engine, die innerhalb von DuskEVM sitzt. Sie kombiniert ElGamal-homomorphe Verschlüsselung mit ZK-Beweisen, um Transaktionsbeträge und Gegenparteien zu verschleiern – und ermöglicht gleichzeitig, dass das Netzwerk die Korrektheit überprüfen kann. Das In-Browser-Proving liegt bei unter 2 Sekunden. Das ist keine Whitepaper-Aussage mehr; das Testnetz ist live und diese Funktion steht jedem zur Verfügung, der darauf bereitstellt. Was das nahelegt: Dusk baut nicht einfach nur eine EVM-Kette mit einem Privacy-Label darauf. Das ZK-Proving passiert auf der Ebene der Transaktionsausführung – nicht als optionaler Wrapper. Das ist eine bedeutsame architektonische Entscheidung. Aber hier meine ehrliche Zurückhaltung: Die Aktivität im Testnetz wird von Entwicklern getragen. Ich habe keine öffentlichen Daten gesehen, wie viele Contracts seit dem 10. August tatsächlich deployt wurden, oder ob die ZK-geschützten Transaktionen von externen Teams kommen oder eher aus internem Testing. Also lautet die eigentliche Frage: Nutzen Builder wirklich Hedger, oder wartet es nur darauf, genutzt zu werden? Es gibt einen Unterschied zwischen einer Funktion, die live ist, und einer Funktion, die tatsächlich verwendet wird. $ACE
#dusk $DUSK @Dusk nachdem das DuskEVM-Testnetz am 10. August live gegangen ist. Die Schlagzeile lautet EVM-Kompatibilität Solidity, Hardhat, vertraute Tools. Gut. Aber was mich tatsächlich aufmerksam gemacht hat, ist eine Ebene tiefer Hedger.

Hedger ist Dusk' Privacy-Engine, die innerhalb von DuskEVM sitzt. Sie kombiniert ElGamal-homomorphe Verschlüsselung mit ZK-Beweisen, um Transaktionsbeträge und Gegenparteien zu verschleiern – und ermöglicht gleichzeitig, dass das Netzwerk die Korrektheit überprüfen kann. Das In-Browser-Proving liegt bei unter 2 Sekunden. Das ist keine Whitepaper-Aussage mehr; das Testnetz ist live und diese Funktion steht jedem zur Verfügung, der darauf bereitstellt.
Was das nahelegt: Dusk baut nicht einfach nur eine EVM-Kette mit einem Privacy-Label darauf. Das ZK-Proving passiert auf der Ebene der Transaktionsausführung – nicht als optionaler Wrapper. Das ist eine bedeutsame architektonische Entscheidung.

Aber hier meine ehrliche Zurückhaltung: Die Aktivität im Testnetz wird von Entwicklern getragen. Ich habe keine öffentlichen Daten gesehen, wie viele Contracts seit dem 10. August tatsächlich deployt wurden, oder ob die ZK-geschützten Transaktionen von externen Teams kommen oder eher aus internem Testing.

Also lautet die eigentliche Frage: Nutzen Builder wirklich Hedger, oder wartet es nur darauf, genutzt zu werden? Es gibt einen Unterschied zwischen einer Funktion, die live ist, und einer Funktion, die tatsächlich verwendet wird.
$ACE
·
--
Bullisch
Teilweise korrekt
$DUSK docs und ihr Beitrag vom 15. August zu SME-Tokenisierung – und eine Sache lässt mich nicht los. Das Dual-Transaction-Modell von Moonlight (öffentlich, kontobasiert) und Phoenix (geschützte UTXO + ZK-Beweise) ist der Kern des gesamten Pitch. Privatsphäre ist Opt-in, nicht Standard. Das ist tatsächlich der interessante Teil. Moonlight legt Bilanzen und Transaktionsdetails offen, geeignet für Compliance-Reporting und Exchange-Integrationen. Phoenix verbirgt Beträge, Sender-Empfänger-Verbindungen und Bilanzänderungen hinter kryptografischen Zusagen und Nullifizierern. Aber das ist es, was ich beim Durchstöbern ihres Beitrags vom 15. August zu Private-Market-Workflows bemerkt habe: Der gesamte NPEX-Use-Case, auf dem die €200M+-SME-Wertpapierpipeline basiert, setzt auf selektive Offenlegung für regulatorische und Service-Zwecke – nicht auf uneingeschränkte Privatsphäre. Das bedeutet: Die tatsächliche „Privatsphäre“ im Betrieb ist eng begrenzt, von Regulatoren genehmigte Sicht, nicht das, was sich die meisten Krypto-Nutzer vorstellen, wenn sie „Zero-Knowledge“ hören. Was mich wirklich überrascht hat: 210M+ @Dusk_Foundation ist gestaked und sichert das Netzwerk (Dusk), doch DuskEVM und Hedger (die vertrauliche EVM-Schicht) sind immer noch im Testnet. Das ist eine große Staking-Basis, die Infrastruktur stützt, die bisher noch kein echtes institutionelles Transaktionsvolumen gesehen hat. Ich kann nicht bestätigen, welcher Anteil der tatsächlichen Mainnet-Transaktionen derzeit Phoenix vs. Moonlight ist – der Explorer zeigt zwar Tx-Typen, aber keine saubere Aufschlüsselung, die ich schnell abrufen könnte. Lässt mich fragen: Ist Privatsphäre hier wirklich ein Feature für Endnutzer – oder eher Compliance-Infrastruktur für die Institutionen? Und macht dieser Unterschied etwas aus für die Richtung, in die sich das Netzwerk entwickelt? #dusk @Dusk_Foundation $ACE $TUT
$DUSK docs und ihr Beitrag vom 15. August zu SME-Tokenisierung – und eine Sache lässt mich nicht los.

Das Dual-Transaction-Modell von Moonlight (öffentlich, kontobasiert) und Phoenix (geschützte UTXO + ZK-Beweise) ist der Kern des gesamten Pitch. Privatsphäre ist Opt-in, nicht Standard. Das ist tatsächlich der interessante Teil.

Moonlight legt Bilanzen und Transaktionsdetails offen, geeignet für Compliance-Reporting und Exchange-Integrationen. Phoenix verbirgt Beträge, Sender-Empfänger-Verbindungen und Bilanzänderungen hinter kryptografischen Zusagen und Nullifizierern.

Aber das ist es, was ich beim Durchstöbern ihres Beitrags vom 15. August zu Private-Market-Workflows bemerkt habe: Der gesamte NPEX-Use-Case, auf dem die €200M+-SME-Wertpapierpipeline basiert, setzt auf selektive Offenlegung für regulatorische und Service-Zwecke – nicht auf uneingeschränkte Privatsphäre.

Das bedeutet: Die tatsächliche „Privatsphäre“ im Betrieb ist eng begrenzt, von Regulatoren genehmigte Sicht, nicht das, was sich die meisten Krypto-Nutzer vorstellen, wenn sie „Zero-Knowledge“ hören.
Was mich wirklich überrascht hat: 210M+ @Dusk ist gestaked und sichert das Netzwerk (Dusk), doch DuskEVM und Hedger (die vertrauliche EVM-Schicht) sind immer noch im Testnet. Das ist eine große Staking-Basis, die Infrastruktur stützt, die bisher noch kein echtes institutionelles Transaktionsvolumen gesehen hat.

Ich kann nicht bestätigen, welcher Anteil der tatsächlichen Mainnet-Transaktionen derzeit Phoenix vs. Moonlight ist – der Explorer zeigt zwar Tx-Typen, aber keine saubere Aufschlüsselung, die ich schnell abrufen könnte.
Lässt mich fragen: Ist Privatsphäre hier wirklich ein Feature für Endnutzer – oder eher Compliance-Infrastruktur für die Institutionen? Und macht dieser Unterschied etwas aus für die Richtung, in die sich das Netzwerk entwickelt?
#dusk @Dusk
$ACE
$TUT
·
--
Bullisch
#dusk $DUSK @Dusk_Foundation Entdecker-Daten von heute und eine Zahl ließ mich eiskalt. Gerade jetzt gibt es On-Chain 252 Transaktionen in den letzten 24 Stunden. 231 davon sind Moonlight, vollständig öffentlich. Nur 21 sind Phoenix-geschützt. Das ist ungefähr eine 91/9-Aufteilung. Das, was mich getroffen hat, ist die Ironie daran. @Dusk_Foundation Das gesamte Pitch ist finanzielle Privatsphäre an erster Stelle. Moonlight ist das kontobasierte, vollständig transparente Modell. Phoenix nutzt ZK-Beweise und UTXO-Commitments, um Beträge, Absender-Empfänger-Verknüpfungen und Kontostandsänderungen zu verbergen. Zwei Modelle, die für das Nebeneinander gebaut sind, aber die Nutzer entscheiden sich überwältigend für das öffentliche. Jetzt weiß ich nicht, warum das so ist. Vielleicht ist die Tooling von Phoenix mit mehr Reibung verbunden. Vielleicht besteht die aktuelle Nutzerbasis hauptsächlich aus Stakern und Provisionierern, die operative Transaktionen ausführen, bei denen keine Privatsphäre nötig ist. Oder es liegt ganz etwas anderes vor. Ich kann den Grund ehrlich gesagt nicht allein aus dem Explorer bestätigen. Was ich sagen kann: Wenn dieses Verhältnis auch dann bestehen bleibt, wenn regulierte Wertpapiere anfangen, sich durch das Netzwerk zu bewegen, würde das etwas Interessantes darüber aussagen, was „compliance-fähige Privatsphäre“ in der Praxis tatsächlich bedeutet — denn Institutionen könnten trotz regulatorischer Beobachtung weiterhin standardmäßig auf Transparenz setzen. Die Compliance-Schicht und die Privatsphäre-Schicht sind so gebaut, dass sie zusammen funktionieren. Aber im Moment nutzen die Nutzer die eine und greifen kaum auf die andere zu. Ist das ein UX-Problem, ein Reifeproblem oder einfach… normal für diese Phase? $PORTAL $GPS
#dusk $DUSK @Dusk Entdecker-Daten von heute und eine Zahl ließ mich eiskalt.

Gerade jetzt gibt es On-Chain 252 Transaktionen in den letzten 24 Stunden. 231 davon sind Moonlight, vollständig öffentlich. Nur 21 sind Phoenix-geschützt. Das ist ungefähr eine 91/9-Aufteilung.

Das, was mich getroffen hat, ist die Ironie daran. @Dusk Das gesamte Pitch ist finanzielle Privatsphäre an erster Stelle. Moonlight ist das kontobasierte, vollständig transparente Modell. Phoenix nutzt ZK-Beweise und UTXO-Commitments, um Beträge, Absender-Empfänger-Verknüpfungen und Kontostandsänderungen zu verbergen. Zwei Modelle, die für das Nebeneinander gebaut sind, aber die Nutzer entscheiden sich überwältigend für das öffentliche.

Jetzt weiß ich nicht, warum das so ist. Vielleicht ist die Tooling von Phoenix mit mehr Reibung verbunden. Vielleicht besteht die aktuelle Nutzerbasis hauptsächlich aus Stakern und Provisionierern, die operative Transaktionen ausführen, bei denen keine Privatsphäre nötig ist. Oder es liegt ganz etwas anderes vor. Ich kann den Grund ehrlich gesagt nicht allein aus dem Explorer bestätigen.

Was ich sagen kann: Wenn dieses Verhältnis auch dann bestehen bleibt, wenn regulierte Wertpapiere anfangen, sich durch das Netzwerk zu bewegen, würde das etwas Interessantes darüber aussagen, was „compliance-fähige Privatsphäre“ in der Praxis tatsächlich bedeutet — denn Institutionen könnten trotz regulatorischer Beobachtung weiterhin standardmäßig auf Transparenz setzen.

Die Compliance-Schicht und die Privatsphäre-Schicht sind so gebaut, dass sie zusammen funktionieren. Aber im Moment nutzen die Nutzer die eine und greifen kaum auf die andere zu. Ist das ein UX-Problem, ein Reifeproblem oder einfach… normal für diese Phase?
$PORTAL
$GPS
·
--
Bullisch
$HOLO Marktrichtung: Bärisch. Scharfer Anstieg wurde nahe $0.10 mit starkem Verkaufsdruck abgewiesen. Einstiegszone: $0.0890–$0.0940 Stop-Loss: $0.1025 Take Profit: TP1: $0.0820 TP2: $0.0760 TP3: $0.0700 Der Kurs zeigt eine klare Zurückweisung im Bereich von $0.10. Eine gescheiterte Erholung in die Einstiegszone würde eine Short-Fortsetzung hin zu den vorherigen Ausbruchsniveaus begünstigen. Invalidierung oberhalb von $0.1025. #Write2Earn {future}(HOLOUSDT) $PROM {future}(PROMUSDT) $BABY {future}(BABYUSDT)
$HOLO Marktrichtung: Bärisch. Scharfer Anstieg wurde nahe $0.10 mit starkem Verkaufsdruck abgewiesen.

Einstiegszone: $0.0890–$0.0940
Stop-Loss: $0.1025

Take Profit:
TP1: $0.0820
TP2: $0.0760
TP3: $0.0700

Der Kurs zeigt eine klare Zurückweisung im Bereich von $0.10. Eine gescheiterte Erholung in die Einstiegszone würde eine Short-Fortsetzung hin zu den vorherigen Ausbruchsniveaus begünstigen.

Invalidierung oberhalb von $0.1025.
#Write2Earn

$PROM
$BABY
·
--
Bullisch
$SOL /USDT Short Setup Marktrichtung: Short-Bias unterhalb des Widerstands bei 77,00 Einstiegszone: 76,40–76,90 Stop Loss: 78,05 Take Profit 1: 75,20 Take Profit 2: 73,80 Take Profit 3: 72,30 Der Preis konsolidiert nahe dem Widerstand nach einem starken Anstieg. Eine Abweisung aus dem Bereich 76,50–77,00 könnte einen Rücksetzer in Richtung der unteren Unterstützungszonen auslösen. Die Invalidierung ist ein klarer Bruch und ein Halten über 78,00. {future}(SOLUSDT) $HOLO {future}(HOLOUSDT) $PROM {future}(PROMUSDT)
$SOL /USDT Short Setup

Marktrichtung: Short-Bias unterhalb des Widerstands bei 77,00

Einstiegszone: 76,40–76,90
Stop Loss: 78,05

Take Profit 1: 75,20
Take Profit 2: 73,80
Take Profit 3: 72,30

Der Preis konsolidiert nahe dem Widerstand nach einem starken Anstieg. Eine Abweisung aus dem Bereich 76,50–77,00 könnte einen Rücksetzer in Richtung der unteren Unterstützungszonen auslösen. Die Invalidierung ist ein klarer Bruch und ein Halten über 78,00.
$HOLO
$PROM
·
--
Bullisch
$PROM Short Setup Marktrichtung: Bärisch nach einer scharfen Zurückweisung aus dem Bereich 3.50. Einstiegszone: 2.65–2.85 Stop Loss: 3.10 Ziel 1: 2.35 Ziel 2: 2.05 Ziel 3: 1.85 Der Preis hat nach dem Anstieg Richtung 3.50 eine starke Zurückweisung gezeigt. Ein Scheitern, die Zone 2.85–3.00 zurückzuerobern, könnte den Weg für einen tieferen Rücksetzer hin zu den vorherigen Konsolidierungszonen öffnen. Warte auf Bestätigung, bevor du einsteigst; die Volatilität ist extrem hoch. {future}(PROMUSDT) $HOLO {future}(HOLOUSDT)
$PROM Short Setup

Marktrichtung: Bärisch nach einer scharfen Zurückweisung aus dem Bereich 3.50.

Einstiegszone: 2.65–2.85
Stop Loss: 3.10
Ziel 1: 2.35
Ziel 2: 2.05
Ziel 3: 1.85

Der Preis hat nach dem Anstieg Richtung 3.50 eine starke Zurückweisung gezeigt. Ein Scheitern, die Zone 2.85–3.00 zurückzuerobern, könnte den Weg für einen tieferen Rücksetzer hin zu den vorherigen Konsolidierungszonen öffnen.

Warte auf Bestätigung, bevor du einsteigst; die Volatilität ist extrem hoch.
$HOLO
·
--
Bullisch
$ETH Short Setup Marktrichtung: Bärischer Kurs hat die Widerstandszone von 1.900–1.920 zurückgewiesen und zeigt Schwäche. Einstiegszone: 1.865–1.885 Stop Loss: 1.925 Ziel 1: 1.840 Ziel 2: 1.810 Ziel 3: 1.780 Auf einen Re-Test und eine Zurückweisung im Bereich der Einstiegszone warten, statt der aktuellen Kerze hinterherzulaufen. $BANANA {future}(BANANAUSDT) {future}(ETHUSDT) #Write2Earn
$ETH Short Setup
Marktrichtung: Bärischer Kurs hat die Widerstandszone von 1.900–1.920 zurückgewiesen und zeigt Schwäche.
Einstiegszone: 1.865–1.885
Stop Loss: 1.925
Ziel 1: 1.840
Ziel 2: 1.810
Ziel 3: 1.780
Auf einen Re-Test und eine Zurückweisung im Bereich der Einstiegszone warten, statt der aktuellen Kerze hinterherzulaufen.
$BANANA


#Write2Earn
Anmelden und weiter Inhalte entdecken
Krypto-Nutzer weltweit auf Binance Square kennenlernen
⚡️ Bleib in Sachen Krypto stets am Puls.
💬 Die weltgrößte Kryptobörse vertraut darauf.
👍 Erhalte verlässliche Einblicke von verifizierten Creators.
E-Mail-Adresse/Telefonnummer
Sitemap
Cookie-Präferenzen
Nutzungsbedingungen der Plattform