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.
$ETH versuchte, über die Marke von 2.550 $ auszubrechen, scheiterte aber erneut.
Für jetzt denke ich, dass der größte Teil des kurzfristigen Aufwärtspotenzials bei Ethereum bereits eingepreist sein dürfte.
In den nächsten Tagen ist mit mehr Seitwärtsbewegung in diesem Bereich zu rechnen, mit der Möglichkeit einer weiteren kleinen Kapitulation, bevor es zu einer echten Trendwende kommt.
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.
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? 👀
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.
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?
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.
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? 👇
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?