Binance Square
C Y R O N
5.5k Beiträge

C Y R O N

Binance KOL & Web3 Mentor
XPL Halter
XPL Halter
Regelmäßiger Trader
4.8 Jahre
291 Following
18.3K Follower
18.0K+ Like gegeben
Beiträge
·
--
Bullisch
Übersetzung ansehen
·
--
Bullisch
BITCOIN HAT $79.500 SOEBEN IN SUPPORT UMGELTET 🚨 Bitcoin hat die $79.500 Widerstandsmarke durchbrochen, die ich im Blick hatte, und ist über $80K gestiegen. $BTC wird nun um etwa $80,9K gehandelt, nachdem es kurzzeitig über $82K lag. Die entscheidende Marke ist jetzt ganz einfach: $79,5K. Wenn Bitcoin darüber hält, beobachte ich als Nächstes $82K. Wenn $79,5K fällt, wirkt dieser Ausbruch deutlich weniger überzeugend. Für den Moment hat sich die Struktur erheblich verbessert. {spot}(BTCUSDT) #USWeeklyInitialJoblessClaimsRiseTo206000 #HousePressesSenateOnCLARITYAct
BITCOIN HAT $79.500 SOEBEN IN SUPPORT UMGELTET 🚨

Bitcoin hat die $79.500 Widerstandsmarke durchbrochen, die ich im Blick hatte, und ist über $80K gestiegen.

$BTC wird nun um etwa $80,9K gehandelt, nachdem es kurzzeitig über $82K lag.

Die entscheidende Marke ist jetzt ganz einfach: $79,5K.

Wenn Bitcoin darüber hält, beobachte ich als Nächstes $82K.

Wenn $79,5K fällt, wirkt dieser Ausbruch deutlich weniger überzeugend.

Für den Moment hat sich die Struktur erheblich verbessert.

#USWeeklyInitialJoblessClaimsRiseTo206000
#HousePressesSenateOnCLARITYAct
·
--
Bullisch
Der ETH/BTC-Monatschart fängt an, interessant auszusehen. Der Preis hat den MA 20 nach oben geschlossen. Das letzte saubere Reclaim auf diesem Niveau gab es im Juli 2020. Was folgte danach? ETH/BTC: 0.0315 → 0.088 ETH: $225 → $4,372 Im August 2025 hat der Preis diese Durchschnittslinie ebenfalls berührt, konnte sie jedoch nicht halten und ist schließlich wieder Richtung der Tiefs zurückgefallen. Das ist jetzt der entscheidende Unterschied. ETH/BTC muss über dem MA 20 bleiben. Auch der MACD dreht von einem ähnlichen Bereich nach oben, wie der, der dem Ausbruch 2020 vorausging. Wenn der Halt funktioniert: Erstes Ziel → 0.050 Weiteres Ziel → 0.088 Unterdessen kam der ISM bei 54,6 heraus, gegenüber 55,2 erwartet, was zeigt, dass das Wachstum zwar weiterhin anhält, aber langsamer wird. Wenn sich die makroökonomischen Bedingungen weiter in Richtung einer lockeren Geldpolitik bewegen, könnte ETH mehr Spielraum haben, um besser abzuschneiden. Dieses Setup ist definitiv ein Beobachten wert. 👀 {spot}(BTCUSDT) {spot}(ETHUSDT) #BitcoinETFBuyersReturn #FedHikeOddsRiseTo68% #G20StatementCitesDigitalAssets
Der ETH/BTC-Monatschart fängt an, interessant auszusehen.

Der Preis hat den MA 20 nach oben geschlossen.

Das letzte saubere Reclaim auf diesem Niveau gab es im Juli 2020.

Was folgte danach?

ETH/BTC: 0.0315 → 0.088
ETH: $225 → $4,372

Im August 2025 hat der Preis diese Durchschnittslinie ebenfalls berührt, konnte sie jedoch nicht halten und ist schließlich wieder Richtung der Tiefs zurückgefallen.

Das ist jetzt der entscheidende Unterschied.

ETH/BTC muss über dem MA 20 bleiben.

Auch der MACD dreht von einem ähnlichen Bereich nach oben, wie der, der dem Ausbruch 2020 vorausging.

Wenn der Halt funktioniert:

Erstes Ziel → 0.050
Weiteres Ziel → 0.088

Unterdessen kam der ISM bei 54,6 heraus, gegenüber 55,2 erwartet, was zeigt, dass das Wachstum zwar weiterhin anhält, aber langsamer wird.

Wenn sich die makroökonomischen Bedingungen weiter in Richtung einer lockeren Geldpolitik bewegen, könnte ETH mehr Spielraum haben, um besser abzuschneiden.

Dieses Setup ist definitiv ein Beobachten wert. 👀

#BitcoinETFBuyersReturn
#FedHikeOddsRiseTo68%
#G20StatementCitesDigitalAssets
·
--
Bärisch
·
--
Bullisch
Hier ist der Trend der vergangenen Jahre. Die Daten zu den Non-Farm-Payrolls unterliegen stets einer Überarbeitung, da die anfängliche Zahl nur eine erste Schätzung ist. Die überarbeiteten Zahlen können ein sehr anderes Bild zeigen. Seit 2022 haben wir ein klares Muster überwiegend abwärtsgerichteter Revisionen gesehen. So könnte zum Beispiel ein Bericht, der +50K Arbeitsplätze ausweist, später auf +25K revidiert werden. Das würde bedeuten, dass der Arbeitsmarkt schwächer war als zunächst gemeldet. Nun liegt die jährliche NFP-Revision für 2025 bei -911K Arbeitsplätzen, was zeigt, wie groß diese Anpassungen sein können. Wenn die heutigen NFP-Daten also stark ausfallen, hat der Markt möglicherweise weniger Anlass dafür, dass die Fed die Zinsen senkt. Das könnte risikoreiche Assets wie $BTC {spot}(BTCUSDT) #SOLJumps20%OnTheWeek #CaliforniaBillWouldBarOfficialMemeCoins #TRONMainnetActivatesTVMPragueOsaka unter Druck setzen.
Hier ist der Trend der vergangenen Jahre.

Die Daten zu den Non-Farm-Payrolls unterliegen stets einer Überarbeitung, da die anfängliche Zahl nur eine erste Schätzung ist.

Die überarbeiteten Zahlen können ein sehr anderes Bild zeigen.

Seit 2022 haben wir ein klares Muster überwiegend abwärtsgerichteter Revisionen gesehen.

So könnte zum Beispiel ein Bericht, der +50K Arbeitsplätze ausweist, später auf +25K revidiert werden.

Das würde bedeuten, dass der Arbeitsmarkt schwächer war als zunächst gemeldet.

Nun liegt die jährliche NFP-Revision für 2025 bei -911K Arbeitsplätzen, was zeigt, wie groß diese Anpassungen sein können.

Wenn die heutigen NFP-Daten also stark ausfallen, hat der Markt möglicherweise weniger Anlass dafür, dass die Fed die Zinsen senkt.

Das könnte risikoreiche Assets wie $BTC
#SOLJumps20%OnTheWeek
#CaliforniaBillWouldBarOfficialMemeCoins
#TRONMainnetActivatesTVMPragueOsaka unter Druck setzen.
·
--
Bullisch
Ich habe diese Woche die CreatorPad-Aufgabe unter @Dusk_Foundation durchlaufen und das, was mir besonders im Kopf geblieben ist, war überhaupt nicht in der Aufgabenbeschreibung enthalten: Die $DUSK -Bridge wurde mittlerweile seit über zehn Tagen pausiert, und bei Dusk scheint niemand eilig zu sein, sie wieder zu öffnen. #dusk Kurzer Kontext für alle, die es verpasst haben: Am 16. August hat das Team eine ungewöhnliche Aktivität auf einer Wallet festgestellt, die für Bridge-Operationen genutzt wurde, hat die betroffenen Adressen recycelt und eine Recipient-Blocklist über die Web Wallet durchgeschoben, nachdem ein Teil des Ablaufs Binance berührt hatte. Das DuskDS-Mainnet selbst hat nie mit dem Blockproduzieren aufgehört. Genau zu diesem Punkt bin ich immer wieder zurückgekehrt. Ich hatte angenommen, dass ein L1 mit Fokus auf Privatsphäre sein Risiko an einem Ort bündelt – in der Basisschicht. Zu sehen, wie die Chain sauber weiterläuft, während die Bridge eingefroren ist, hat deutlich gemacht, dass sich die Vertrauensgrenzen hier nicht so aufteilen. Die Bridge ist ihre eigene Haftungs- und Risikostelle; sie wird an ihrem eigenen Zeitplan festgemacht, unabhängig von der Gesundheit des Konsenses. Binance-User waren möglicherweise zuerst geschützt – allein dadurch, dass die Blocklist bereits existierte, bevor Abhebungen so geroutet werden konnten. Alle anderen warten immer noch auf „vorübergehend“. Ich bin mir nicht sicher, was die tatsächliche Schwelle ist, bevor „vorübergehend“ anfängt, etwas anderes zu bedeuten. {spot}(DUSKUSDT) {spot}(BMTUSDT) {spot}(EDENUSDT) Was ist hier wichtiger?
Ich habe diese Woche die CreatorPad-Aufgabe unter @Dusk durchlaufen und das, was mir besonders im Kopf geblieben ist, war überhaupt nicht in der Aufgabenbeschreibung enthalten: Die $DUSK -Bridge wurde mittlerweile seit über zehn Tagen pausiert, und bei Dusk scheint niemand eilig zu sein, sie wieder zu öffnen. #dusk

Kurzer Kontext für alle, die es verpasst haben: Am 16. August hat das Team eine ungewöhnliche Aktivität auf einer Wallet festgestellt, die für Bridge-Operationen genutzt wurde, hat die betroffenen Adressen recycelt und eine Recipient-Blocklist über die Web Wallet durchgeschoben, nachdem ein Teil des Ablaufs Binance berührt hatte. Das DuskDS-Mainnet selbst hat nie mit dem Blockproduzieren aufgehört. Genau zu diesem Punkt bin ich immer wieder zurückgekehrt.

Ich hatte angenommen, dass ein L1 mit Fokus auf Privatsphäre sein Risiko an einem Ort bündelt – in der Basisschicht. Zu sehen, wie die Chain sauber weiterläuft, während die Bridge eingefroren ist, hat deutlich gemacht, dass sich die Vertrauensgrenzen hier nicht so aufteilen. Die Bridge ist ihre eigene Haftungs- und Risikostelle; sie wird an ihrem eigenen Zeitplan festgemacht, unabhängig von der Gesundheit des Konsenses.

Binance-User waren möglicherweise zuerst geschützt – allein dadurch, dass die Blocklist bereits existierte, bevor Abhebungen so geroutet werden konnten. Alle anderen warten immer noch auf „vorübergehend“.

Ich bin mir nicht sicher, was die tatsächliche Schwelle ist, bevor „vorübergehend“ anfängt, etwas anderes zu bedeuten.

Was ist hier wichtiger?
🟢 Mainnet's clean uptime
100%
🔴 Bridge still closed
0%
⚖️ Both equally
0%
🤷 Too early to say
0%
1 Stimmen • Abstimmung beendet
·
--
Bullisch
Ich habe diese Woche früher eine kleine Überweisung über Dusk's Web Wallet gemacht, während ich einen CreatorPad-Task abschloss, und wurde mitten im Ablauf von einer Blocklist-Warnung gestoppt, mit der ich nicht gerechnet hatte. Nichts Dramatisches, nur ein rotes Flag, bevor die Transaktion überhaupt abgeschickt werden konnte. Für eine Kette, die um $DUSK s selektives-Disclosure-Privacy-Modell herum gebaut ist, #dusk , @Dusk_Foundation , wirkte das wie etwas Ungewöhnliches, das man antreffen könnte. Wie sich herausstellte, lässt sich die Warnung auf die Empfänger-Blocklist zurückführen, die das Team nach dem Zwischenfall Mitte August mit einer kompromittierten Bridge-Operations-Wallet an das Web Wallet ausgeliefert hat. Es prüft ausgehende Transfers gegen bekannte, als auffällig markierte Adressen, bevor du sie senden kannst. Ich hatte angenommen, dass „privacy-first“ weniger Checkpoints bedeutet, nicht mehr. Es live zu sehen, wie es bei einem echten Versuch auslöst, hat das etwas verändert. Das Mechanismus funktioniert nur, wenn jemand diese Liste in nahezu Echtzeit pflegt und aktualisiert – das heißt, darunter sitzt eine kuratorische Ebene, die still und leise unter dem „confidential by default“-Versprechen liegt. Ich sage nicht, dass das falsch ist, nur dass ich es bemerkte. Selektive Offenlegung und Adress-Screening sind nicht dasselbe, aber sie leben jetzt in derselben Wallet. Ich arbeite noch heraus, wie wohl ich mich damit fühle – und wer genau entscheidet, was künftig zur Liste hinzugefügt wird. {spot}(DUSKUSDT) {spot}(ONGUSDT) {spot}(JASMYUSDT) Welcher Teil davon ist dir am meisten aufgefallen? 👀
Ich habe diese Woche früher eine kleine Überweisung über Dusk's Web Wallet gemacht, während ich einen CreatorPad-Task abschloss, und wurde mitten im Ablauf von einer Blocklist-Warnung gestoppt, mit der ich nicht gerechnet hatte. Nichts Dramatisches, nur ein rotes Flag, bevor die Transaktion überhaupt abgeschickt werden konnte. Für eine Kette, die um $DUSK s selektives-Disclosure-Privacy-Modell herum gebaut ist, #dusk , @Dusk , wirkte das wie etwas Ungewöhnliches, das man antreffen könnte.

Wie sich herausstellte, lässt sich die Warnung auf die Empfänger-Blocklist zurückführen, die das Team nach dem Zwischenfall Mitte August mit einer kompromittierten Bridge-Operations-Wallet an das Web Wallet ausgeliefert hat. Es prüft ausgehende Transfers gegen bekannte, als auffällig markierte Adressen, bevor du sie senden kannst.

Ich hatte angenommen, dass „privacy-first“ weniger Checkpoints bedeutet, nicht mehr. Es live zu sehen, wie es bei einem echten Versuch auslöst, hat das etwas verändert. Das Mechanismus funktioniert nur, wenn jemand diese Liste in nahezu Echtzeit pflegt und aktualisiert – das heißt, darunter sitzt eine kuratorische Ebene, die still und leise unter dem „confidential by default“-Versprechen liegt.

Ich sage nicht, dass das falsch ist, nur dass ich es bemerkte. Selektive Offenlegung und Adress-Screening sind nicht dasselbe, aber sie leben jetzt in derselben Wallet. Ich arbeite noch heraus, wie wohl ich mich damit fühle – und wer genau entscheidet, was künftig zur Liste hinzugefügt wird.

Welcher Teil davon ist dir am meisten aufgefallen? 👀
🚫 The blocklist itself
50%
🔑 Who maintains the list
50%
⚖️ Privacy vs. gatekeeping
0%
💭 Something else
0%
2 Stimmen • Abstimmung beendet
·
--
Bullisch
Ich habe diese Woche die Statusseite der Dusk-Brücke erneut überprüft, und sie zeigt immer noch „pausiert“ an – genauso wie seit dem Zwischenfall vom 16. August. Damals hatte das Team verdächtige Aktivitäten auf einer Wallet gemeldet, die für den Betrieb der Brücke genutzt wird. Genau diese Einzelheit ist mir im Gedächtnis geblieben, als ich diese CreatorPad-Aufgabe abgeschlossen habe: @Dusk_Foundation , $DUSK , #dusk – neun plus Tage später: Die Adressen werden recycelt, die Blocklist ist aktiv, aber die Brücke selbst ist noch immer nicht wieder online. Die offizielle Darstellung war sauber: kein Problem auf Protokollebene. DuskDS hat weiterhin normal Blöcke erzeugt, und keine Nutzerfonds waren betroffen. Technisch stimmt das. Aber ich bin mit der Annahme hineingegangen, dass „kein Protokollfehler“ „schnelle Behebung“ bedeutet. War nicht so. Operative Infrastruktur, die von einem Team verwaltet wird – selbst auf einer Chain, die um deterministische Abrechnung und Audit-Grade-Privatsphäre herum gebaut ist – bewegt sich, sobald etwas in einen zentralisierten Ablauf gerät, trotzdem nach menschlichen Zeitplänen. Was mich mehr als der Zwischenfall selbst beschäftigt hat, war die Lücke zwischen der Art, wie selbstsicher die Kommunikation beruhigt, und der Zeit, die die tatsächliche Behebung in Anspruch nimmt. Diese beiden Dinge müssen nicht zwangsläufig im Widerspruch stehen, aber nebeneinander gelesen wirkt es anders. Ich bin mir noch nicht sicher, ob das einfach ein sorgfältiger Prozess ist oder etwas Strukturelleres daran, wie Brücken nach einem Vorfall behandelt werden. Ich schaue, wann sie tatsächlich wieder geöffnet wird. {spot}(DUSKUSDT) {spot}(ZROUSDT) {spot}(ENAUSDT) Welcher Teil sticht für dich heraus? 🤔
Ich habe diese Woche die Statusseite der Dusk-Brücke erneut überprüft, und sie zeigt immer noch „pausiert“ an – genauso wie seit dem Zwischenfall vom 16. August. Damals hatte das Team verdächtige Aktivitäten auf einer Wallet gemeldet, die für den Betrieb der Brücke genutzt wird. Genau diese Einzelheit ist mir im Gedächtnis geblieben, als ich diese CreatorPad-Aufgabe abgeschlossen habe: @Dusk , $DUSK , #dusk – neun plus Tage später: Die Adressen werden recycelt, die Blocklist ist aktiv, aber die Brücke selbst ist noch immer nicht wieder online.

Die offizielle Darstellung war sauber: kein Problem auf Protokollebene. DuskDS hat weiterhin normal Blöcke erzeugt, und keine Nutzerfonds waren betroffen. Technisch stimmt das. Aber ich bin mit der Annahme hineingegangen, dass „kein Protokollfehler“ „schnelle Behebung“ bedeutet. War nicht so. Operative Infrastruktur, die von einem Team verwaltet wird – selbst auf einer Chain, die um deterministische Abrechnung und Audit-Grade-Privatsphäre herum gebaut ist – bewegt sich, sobald etwas in einen zentralisierten Ablauf gerät, trotzdem nach menschlichen Zeitplänen.

Was mich mehr als der Zwischenfall selbst beschäftigt hat, war die Lücke zwischen der Art, wie selbstsicher die Kommunikation beruhigt, und der Zeit, die die tatsächliche Behebung in Anspruch nimmt. Diese beiden Dinge müssen nicht zwangsläufig im Widerspruch stehen, aber nebeneinander gelesen wirkt es anders.

Ich bin mir noch nicht sicher, ob das einfach ein sorgfältiger Prozess ist oder etwas Strukturelleres daran, wie Brücken nach einem Vorfall behandelt werden. Ich schaue, wann sie tatsächlich wieder geöffnet wird.

Welcher Teil sticht für dich heraus? 🤔
🛠️ The framing
50%
⏳ The timeline
0%
🔐 Wallet risk
0%
🤷 Just normal caution
50%
2 Stimmen • Abstimmung beendet
·
--
Bullisch
Ich habe den CreatorPad-Überblick zu $DUSK gelesen und bin bei einer Zeile in Dusk’ eigener Mitteilung zum Brücken-Vorfall hängen geblieben: Das Team hat eine Reihe von Adressen deaktiviert und recycelt, nachdem es eine ungewöhnliche Aktivität auf einer teamverwalteten Wallet gemeldet hatte, die für Brücken-Operationen genutzt wird, und dann die Brücken-Dienste vollständig pausiert, während es das geklärt hat. #dusk Das war der Teil, der mich beschäftigt hat. Nicht der Vorfall selbst, sondern die Reaktionsform. @Dusk_Foundation verwendet den Großteil seiner Kommunikation auf Benutzerseite: Privatsphäre, selektive Offenlegung, Compliance-„Rails“ – alles, was für die Person gedacht ist, die die Wallet hält. Das war hier nicht das. Es war ein interner operativer Schlüssel, dessen Verhalten durch daran gekoppelte Signale auffällig geworden ist, und die Lösung war brutal: alles pausieren, die Adressmenge neu aufbauen und eine Empfänger-Blacklist ausspielen, um alles abzufangen, was versucht, über die Web-Wallet zu wechseln. Ich hatte angenommen, dass der Rahmen „regulierte Infrastruktur“ bedeutet, dass die operative Seite ebenfalls gehärtet ist – vielleicht sogar mehr als bei den meisten L1s, angesichts des institutionellen Verkaufsgesprächs. Aber der Ausfallmodus war kein Smart-Contract-Exploit und auch keine Governance-Abstimmung, die schiefgelaufen ist; es war eine verwaltete Wallet – ein viel langweiligeres und zugleich universelleres Problem. Trotzdem bin ich nicht sicher, ob das beruhigend ist oder das Gegenteil. {spot}(DUSKUSDT) {spot}(SPKUSDT) {spot}(MORPHOUSDT) Was ist bei Dusk’ Brücken-Reaktion am stärksten aufgefallen?
Ich habe den CreatorPad-Überblick zu $DUSK gelesen und bin bei einer Zeile in Dusk’ eigener Mitteilung zum Brücken-Vorfall hängen geblieben: Das Team hat eine Reihe von Adressen deaktiviert und recycelt, nachdem es eine ungewöhnliche Aktivität auf einer teamverwalteten Wallet gemeldet hatte, die für Brücken-Operationen genutzt wird, und dann die Brücken-Dienste vollständig pausiert, während es das geklärt hat. #dusk

Das war der Teil, der mich beschäftigt hat. Nicht der Vorfall selbst, sondern die Reaktionsform. @Dusk verwendet den Großteil seiner Kommunikation auf Benutzerseite: Privatsphäre, selektive Offenlegung, Compliance-„Rails“ – alles, was für die Person gedacht ist, die die Wallet hält. Das war hier nicht das. Es war ein interner operativer Schlüssel, dessen Verhalten durch daran gekoppelte Signale auffällig geworden ist, und die Lösung war brutal: alles pausieren, die Adressmenge neu aufbauen und eine Empfänger-Blacklist ausspielen, um alles abzufangen, was versucht, über die Web-Wallet zu wechseln.

Ich hatte angenommen, dass der Rahmen „regulierte Infrastruktur“ bedeutet, dass die operative Seite ebenfalls gehärtet ist – vielleicht sogar mehr als bei den meisten L1s, angesichts des institutionellen Verkaufsgesprächs. Aber der Ausfallmodus war kein Smart-Contract-Exploit und auch keine Governance-Abstimmung, die schiefgelaufen ist; es war eine verwaltete Wallet – ein viel langweiligeres und zugleich universelleres Problem.

Trotzdem bin ich nicht sicher, ob das beruhigend ist oder das Gegenteil.


Was ist bei Dusk’ Brücken-Reaktion am stärksten aufgefallen?
🛑 Full pause
60%
🔑 Team wallet risk
40%
🧊 "No impact" claim
0%
🤷 Not surprised
0%
5 Stimmen • Abstimmung beendet
·
--
Bullisch
Habe die Woche damit verbracht, in die Brücken-Infrastruktur von Dusk für diese CreatorPad-Runde einzutauchen, und das, was mich aufgehalten hat, war kein Feature – es war die Benachrichtigung zum Vorfall vom 16. August. Das Team hat verdächtige Aktivitäten auf einer Wallet festgestellt, die sie für Bridge-Operationen kontrollierten, und musste vor Ort einen Stapel von Adressen deaktivieren und recyceln. $DUSK , #dusk , @Dusk_Foundation – ich war mit der Erwartung reingegangen, über den Testnet-Impuls von DuskEVM zu schreiben. Ich bin mit etwas ganz anderem im Kopf rausgekommen. Das hier hat es mir klar gemacht: Die Brücke selbst ist nicht gebrochen. Die zk-Schicht, der Konsens – nichts davon wurde angetastet. Was nachgegeben hat, war eine teamverwaltete Wallet, also eine Art operativer Komponente, von der jede Bridge leise abhängt und die niemand wirklich öffentlich auditiert. Dusk reagierte schnell, stoppte Services, und koordinierte sich mit Binance, sobald dort ein Teil des Ablaufs sichtbar wurde. Eine vernünftige Reaktion. Aber sie hat die Lücke zwischen „protokollbasierter Sicherheit“ und „den Menschen, die die Infra-Ebene betreiben“ aufgezeigt – zwei Dinge, die ich bis dahin für eins gehalten hatte. Ich war davon ausgegangen, dass das Bridge-Risiko hauptsächlich im Vertragscode lebt. Aber die weichere Angriffsfläche – die operative – ist genauso tragfähig. Immer noch nicht sicher, wie man das auditieren sollte. {spot}(TRUMPUSDT) {spot}(STXUSDT) {spot}(POLUSDT) Was ist das echte Bridge-Risiko?
Habe die Woche damit verbracht, in die Brücken-Infrastruktur von Dusk für diese CreatorPad-Runde einzutauchen, und das, was mich aufgehalten hat, war kein Feature – es war die Benachrichtigung zum Vorfall vom 16. August. Das Team hat verdächtige Aktivitäten auf einer Wallet festgestellt, die sie für Bridge-Operationen kontrollierten, und musste vor Ort einen Stapel von Adressen deaktivieren und recyceln. $DUSK , #dusk , @Dusk – ich war mit der Erwartung reingegangen, über den Testnet-Impuls von DuskEVM zu schreiben. Ich bin mit etwas ganz anderem im Kopf rausgekommen.

Das hier hat es mir klar gemacht: Die Brücke selbst ist nicht gebrochen. Die zk-Schicht, der Konsens – nichts davon wurde angetastet. Was nachgegeben hat, war eine teamverwaltete Wallet, also eine Art operativer Komponente, von der jede Bridge leise abhängt und die niemand wirklich öffentlich auditiert. Dusk reagierte schnell, stoppte Services, und koordinierte sich mit Binance, sobald dort ein Teil des Ablaufs sichtbar wurde. Eine vernünftige Reaktion. Aber sie hat die Lücke zwischen „protokollbasierter Sicherheit“ und „den Menschen, die die Infra-Ebene betreiben“ aufgezeigt – zwei Dinge, die ich bis dahin für eins gehalten hatte.

Ich war davon ausgegangen, dass das Bridge-Risiko hauptsächlich im Vertragscode lebt. Aber die weichere Angriffsfläche – die operative – ist genauso tragfähig. Immer noch nicht sicher, wie man das auditieren sollte.

Was ist das echte Bridge-Risiko?
🔐 Contract code
0%
👤 Team wallets
50%
🌉 Message relay
0%
🧩 Upgrade keys
50%
2 Stimmen • Abstimmung beendet
·
--
Bullisch
Führte vor jeder Bereitstellung einen schnellen RPC-Check gegen das DuskEVM-Testnet durch, nur um sicherzustellen, dass ich wirklich im richtigen Netzwerk war. Ein kleiner Schritt, aber er hat die CreatorPad-Aufgabe auf etwas Reales gestützt – statt auf Doku-Screenshots. Überbrückte eine Charge von $DUSK from DuskDS, um die Deployment-Wallet zu finanzieren, und schob dann einen einfachen Solidity-Vertrag durch Hardhat. #dusk @Dusk_Foundation Was mich tatsächlich aufhielt, war nicht, dass das Deployment erfolgreich war, sondern die Gebührenaufstellung danach. Ich hatte angenommen, dass „privacy-preserving EVM“ bedeutet, dass die Privatsphäre standardmäßig in jede Transaktion eingebaut ist. Dem ist nicht so. Die Ausführungsgebühr und die Data-Availability-Gebühr fürs Posten der Batch-Backs an DuskDS waren beide vollständig sichtbar – ganz im Standard-OP-Stack-Stil. Nichts ist abgeschirmt, außer du leitest gezielt über Hedger. Das ist eine nachvollziehbare Annahme, die man falsch haben kann. Dusks Kommunikation setzt stark auf Vertraulichkeit, daher liegt es nahe zu erwarten, dass die EVM-Schicht das standardmäßig übernimmt – statt dass man es separat explizit dazubucht. Architektonisch ergibt das Sinn: Settlement- und Privacy-Tools bleiben entkoppelt von genereller Ausführung. Trotzdem bin ich neugierig, wie viele Entwickler, die hier gerade bauen, tatsächlich zu Hedger greifen – statt einfach nur Standard-EVM-Verträge zu shippen und weiterzumachen. Das ist meine eigene Beobachtung aus Tests, keine finanzielle Beratung. Wenn du das Ökosystem einschätzt, lohnt es sich, das nicht weiter zu verbeißen. {spot}(DUSKUSDT) {spot}(PROMUSDT) {spot}(NEIROUSDT) Welchen Teil beim Bauen auf DuskEVM würdest du zuerst angehen? 👇
Führte vor jeder Bereitstellung einen schnellen RPC-Check gegen das DuskEVM-Testnet durch, nur um sicherzustellen, dass ich wirklich im richtigen Netzwerk war. Ein kleiner Schritt, aber er hat die CreatorPad-Aufgabe auf etwas Reales gestützt – statt auf Doku-Screenshots. Überbrückte eine Charge von $DUSK from DuskDS, um die Deployment-Wallet zu finanzieren, und schob dann einen einfachen Solidity-Vertrag durch Hardhat. #dusk @Dusk

Was mich tatsächlich aufhielt, war nicht, dass das Deployment erfolgreich war, sondern die Gebührenaufstellung danach. Ich hatte angenommen, dass „privacy-preserving EVM“ bedeutet, dass die Privatsphäre standardmäßig in jede Transaktion eingebaut ist. Dem ist nicht so. Die Ausführungsgebühr und die Data-Availability-Gebühr fürs Posten der Batch-Backs an DuskDS waren beide vollständig sichtbar – ganz im Standard-OP-Stack-Stil. Nichts ist abgeschirmt, außer du leitest gezielt über Hedger.

Das ist eine nachvollziehbare Annahme, die man falsch haben kann. Dusks Kommunikation setzt stark auf Vertraulichkeit, daher liegt es nahe zu erwarten, dass die EVM-Schicht das standardmäßig übernimmt – statt dass man es separat explizit dazubucht.

Architektonisch ergibt das Sinn: Settlement- und Privacy-Tools bleiben entkoppelt von genereller Ausführung. Trotzdem bin ich neugierig, wie viele Entwickler, die hier gerade bauen, tatsächlich zu Hedger greifen – statt einfach nur Standard-EVM-Verträge zu shippen und weiterzumachen. Das ist meine eigene Beobachtung aus Tests, keine finanzielle Beratung. Wenn du das Ökosystem einschätzt, lohnt es sich, das nicht weiter zu verbeißen.

Welchen Teil beim Bauen auf DuskEVM würdest du zuerst angehen? 👇
🔧 Standard Solidity contract
0%
🕶️ Hedger private execution
0%
🌉 Just the bridge
0%
🤔 Still deciding
0%
0 Stimmen • Abstimmung beendet
·
--
Bullisch
Absolut HISTORISCH. Bitcoin ist gerade 140-mal schneller unterwegs als der Aktienmarkt. $BTC ist in weniger als fünf Tagen um mehr als 20% gestiegen – von rund 63.000 $ auf über 77.000 $. Zum Vergleich: Der S&P 500 hat historisch etwa 10% pro Jahr zurückgebracht. Bitcoin hat genau diese Art von Rendite in weniger als fünf Tagen geliefert. Fast 3 Monate an Verlusten wurden in nur 5 Tagen wieder wettgemacht. Und das ist jetzt Bitcoins stärkster wöchentlicher Kursanstieg seit Februar 2024. Das ist unglaublich. 🚀 {spot}(BTCUSDT) #USJoblessClaimsFallTo206000 #TrumpPressesCongressToPassClarityAct
Absolut HISTORISCH.

Bitcoin ist gerade 140-mal schneller unterwegs als der Aktienmarkt.

$BTC ist in weniger als fünf Tagen um mehr als 20% gestiegen – von rund 63.000 $ auf über 77.000 $.

Zum Vergleich: Der S&P 500 hat historisch etwa 10% pro Jahr zurückgebracht.

Bitcoin hat genau diese Art von Rendite in weniger als fünf Tagen geliefert.

Fast 3 Monate an Verlusten wurden in nur 5 Tagen wieder wettgemacht.

Und das ist jetzt Bitcoins stärkster wöchentlicher Kursanstieg seit Februar 2024.

Das ist unglaublich. 🚀
#USJoblessClaimsFallTo206000
#TrumpPressesCongressToPassClarityAct
·
--
Bullisch
Diese Woche habe ich einen Teil des Testnetzes DUSK auf DuskEVM überbrückt, nur um diese Woche einen einfachen Vertrag über Hardhat zu deployen – vor allem, um zu sehen, wie nah „EVM-äquivalent“ in der Praxis tatsächlich herankommt. @Dusk_Foundation , $DUSK , #dusk Der Deploy selbst verlief ereignislos: Chain-ID passte, die Adresse hatte Bytecode. Nichts Dramatisches. Was mich dann aufgehalten hat: Anschließend wollte ich die Transaktion im Mempool vor der Bestätigung beobachten – so, wie man es bei jeder beliebigen EVM-Chain ganz beiläufig macht. Einen gibt es nicht. DuskEVM läuft derzeit nur sequencer-basiert; es gibt keinen öffentlichen Mempool, in den man reinschauen könnte. Ich hatte angenommen, „EVM-äquivalent“ bedeutet, dass die gesamte Oberfläche sich identisch verhält – inklusive der Teile, an die man erst denkt, wenn sie weg sind. Es ist nur eine Kleinigkeit, aber es rückt das neu, was „kompatibel“ hier eigentlich macht. Die Tools passen, Solidity und Hardhat funktionieren wie erwartet – aber das zugrunde liegende Ausführungsmodell trifft eine andere Auswahl an Tradeoffs, vermutlich im Dienst der Datenschutz- und Settlement-Garantien, die das Projekt immer wieder betont. Ich bin immer noch nicht sicher, wie sich das auf die MEV-Exponierung oder die Reihenfolge von Transaktionen auswirkt, sobald Mainnet-Traffic auftaucht. Das sollte man sich genauer ansehen, bevor man Schlussfolgerungen zieht. {spot}(DUSKUSDT) {spot}(ONGUSDT) {spot}(PEOPLEUSDT) Was ist dir auf einer EVM-kompatiblen Chain wichtiger?
Diese Woche habe ich einen Teil des Testnetzes DUSK auf DuskEVM überbrückt, nur um diese Woche einen einfachen Vertrag über Hardhat zu deployen – vor allem, um zu sehen, wie nah „EVM-äquivalent“ in der Praxis tatsächlich herankommt. @Dusk , $DUSK , #dusk Der Deploy selbst verlief ereignislos: Chain-ID passte, die Adresse hatte Bytecode. Nichts Dramatisches.

Was mich dann aufgehalten hat: Anschließend wollte ich die Transaktion im Mempool vor der Bestätigung beobachten – so, wie man es bei jeder beliebigen EVM-Chain ganz beiläufig macht. Einen gibt es nicht. DuskEVM läuft derzeit nur sequencer-basiert; es gibt keinen öffentlichen Mempool, in den man reinschauen könnte. Ich hatte angenommen, „EVM-äquivalent“ bedeutet, dass die gesamte Oberfläche sich identisch verhält – inklusive der Teile, an die man erst denkt, wenn sie weg sind.

Es ist nur eine Kleinigkeit, aber es rückt das neu, was „kompatibel“ hier eigentlich macht. Die Tools passen, Solidity und Hardhat funktionieren wie erwartet – aber das zugrunde liegende Ausführungsmodell trifft eine andere Auswahl an Tradeoffs, vermutlich im Dienst der Datenschutz- und Settlement-Garantien, die das Projekt immer wieder betont.

Ich bin immer noch nicht sicher, wie sich das auf die MEV-Exponierung oder die Reihenfolge von Transaktionen auswirkt, sobald Mainnet-Traffic auftaucht. Das sollte man sich genauer ansehen, bevor man Schlussfolgerungen zieht.


Was ist dir auf einer EVM-kompatiblen Chain wichtiger?
🔍 Mempool visibility
100%
🛡️ Privacy over transparency
0%
⚡ Speed and low gas
0%
🤷 Never thought about it
0%
1 Stimmen • Abstimmung beendet
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