DxSale veröffentlicht Klarstellung nach Vorfall: v2 und neuere Liquiditäts-Lock-Verträge bleiben unberührt
DxSale veröffentlicht Klarstellung nach Vorfall: v2 und neuere Liquiditäts-Lock-Verträge bleiben unberührt
Ein kürzlicher Exploit von Liquiditätssperren auf der BNB Chain entfachte eine altbekannte Frage im DeFi-Bereich: Kann „alte Infrastruktur“ wieder gefährlich werden, wenn sich die zugrundeliegende Kette weiterentwickelt? Ende Mai 2026 griffen Angreifer ältere DxSale-Liquiditätssperren aus dem Jahr 2021 an, was zu On-Chain-Transaktionen von Geldern und einer Welle der Besorgnis bei Projekten auslöste, die einst auf DxSales frühe Sperrarchitektur setzten.
In einer anschließenden Klarstellung, die etwa vom 30. bis 31. Mai 2026 (abhängig von der Zeitzone) veröffentlicht wurde, teilte DxSale mit, dass das Problem auf seinen v1 Lock-Vertrag beschränkt sei und dass v2 und spätere Versionen (v2, v3 usw.) nicht betroffen waren. Neuere Verträge wurden demnach geprüft, und die gesperrten Vermögenswerte der Nutzer blieben sicher.
Im Folgenden finden Sie eine praktische Aufschlüsselung dessen, was passiert ist, warum „atomare“ Ausführungsfunktionen auf Kettenebene Randfälle in älteren Verträgen aufzeigen können und was LPs und Token-Teams als Nächstes tun sollten.
Was auf der BNB Chain geschah (29. Mai 2026)
Am 29. Mai 2026 tauchten Berichte auf, dass ungefähr 1.400 ältere LP-Positionen – hauptsächlich aus der Ära von 2021 – auf der BNB Chain geleert wurden, mit geschätzten Verlusten von rund 7,3 Millionen US-Dollar. Mehrere Berichte, die den Vorfall verfolgten, stellten fest, dass der Angreifer einen Ansatz verfolgte, der mit der Manipulation der Eigentümerschaft / privilegierten Kontrolle vereinbar war, und dann Vermögenswerte über Swaps und Einzahlungen leitete.
Eine weithin zitierte Adresse des Angreifers in diesem Vorfall ist:
- 0xC4574DDE...2EeaFA69 – einsehbar auf BscScan-Adressenverfolgung
Öffentliche Zusammenfassungen beschrieben auch, wie der Angreifer Gelder in BNB konsolidierte, 2.958 BNB (zu der Zeit ~1,87 Mio. USD) an zwei Haupt-Wallets überwies, dann zu Börseneinzahlungsadressen leitete und über PancakeSwap wechselte. Für einen verständlichen Überblick über den Vorfall siehe CoinTelegraphs Bericht, gespiegelt auf TradingView.
DxSales Kernpunkt: Der Auswirkungenradius ist auf v1 beschränkt
DxSales Klarstellung betont drei zentrale Aussagen:
- Die betroffenen Verträge sind die frühen „v1“-Liquiditäts-Lock-Verträge, die 2021 gestartet wurden
- v2 und spätere Lock-Verträge sind nicht betroffen
- Neuere Verträge wurden unter einer anderen Architektur entwickelt und haben eine Sicherheitsprüfung / Audits durchlaufen
Obwohl Nutzer immer die Vertragsadressen und den Umfang der Audits für ihre spezifische Sperre überprüfen sollten, können Sie die Sicherheit und Audit-Historie der DxSale-Projekte über CertiKs Skynet-Projektseite für DxSale abgleichen.
Für Nutzer, die mit Versionierungen auf DxSale nicht vertraut sind, unterscheidet die eigene Dokumentation von DxSale neuere Locker (z. B. DxLock V2 Liquiditäts-Locking-Dokumentation), was bei der Überprüfung hilft, welche Tools und Vertragsgeneration ein bestimmtes Projekt verwendet hat.
Warum „atomare Transaktionen“ alte Annahmen brechen können
DxSale führte die Grundursache auf ein Kompatibilitätsproblem zwischen dem neueren „atomaren Transaktions“-Ausführungsstil der BNB Chain und dem frühen v1 Locker-Design zurück.
In modernen EVM-Ökosystemen bezieht sich „atomar“ oft auf die Bündelung mehrerer Aktionen in einer Alles-oder-Nichts-Transaktion (sodass keine Zwischenzustände bestehen bleiben). Diese Richtung beschleunigte sich 2025–2026 durch die breitere Einführung von Account Abstraction und Batching-Primitiven, einschließlich Mechanismen im Stil von EIP-7702.
Die BNB Chain hat Smart-Wallet- und Account-Abstraction-Upgrades öffentlich diskutiert – siehe Ankündigung des Pascal Hard Forks der BNB Chain. Für den zugrundeliegenden Standard, der Konzepte der Einzeltransaktionsdelegation / Batching populär gemacht hat, siehe EIP-7702 auf Ethereum EIPs.
Die wichtigste Lektion für die DeFi-Sicherheit
Auch wenn ein Legacy-Vertrag „jahrelang funktionierte“, können neue Transaktionsmuster alte Bedrohungsmodelle ungültig machen – insbesondere wenn der Vertrag auf Administratorprivilegien, ungewöhnliche Eigentümerflüsse oder Annahmen über die Zusammensetzung von Aufrufen angewiesen war.
Dies ist einer der Gründe, warum sich die DeFi-Sicherheitsgespräche in den Jahren 2025–2026 zunehmend auf folgende Punkte konzentrieren:
- Risiko von unveränderlichen vs. aufrüstbaren Verträgen,
- Privilegierte Rollen und Eigentumsgrenzen,
- und ob Verträge unter neuen Chain-Funktionen und Ausführungsumgebungen sicher bleiben.
Was Liquiditätsanbieter und Token-Teams jetzt tun sollten
1) Überprüfen Sie, welche Sperrversion Ihr LP verwendet hat
Wenn Sie ein Community-Mitglied eines älteren BNB Chain-Projekts sind, gehen Sie nicht davon aus, dass „gesperrt“ sicher bedeutet. Bitten Sie das Team um Folgendes:
- die genaue Adresse des Sperrvertrags,
- die Lock-ID / Lock-Seite,
- und die Bestätigung, ob es sich um v1 vs. v2+ handelt.
Wenn Sie nur eine Adresse haben, beginnen Sie mit BscScan und prüfen Sie die Erstellungszeit des Vertrags, die Eigentümerfunktionen und die historischen Transaktionen.
2) Behandeln Sie „Audit“ als notwendig, aber nicht ausreichend
Audits reduzieren das Risiko, eliminieren es aber nicht – insbesondere, wenn sich das Chain-Verhalten weiterentwickelt. Verwenden Sie Audit-Referenzen als Ausgangspunkt und werten Sie dann aus:
- Sind privilegierte Funktionen noch vorhanden?
- Kann die Eigentümerschaft geändert werden?
- Gibt es vom Administrator gesteuerte Parameter, die Auszahlungen beeinflussen?
3) Gehen Sie davon aus, dass Angreifer vergessene Verträge ins Visier nehmen werden
Der Exploit veranschaulicht ein wiederkehrendes Muster: Angreifer jagen oft nach ruhender Liquidität und Legacy-Verträgen, da die Überwachung schwächer ist und die Reaktion langsamer erfolgt.
4) Schützen Sie Ihre Signaturschlüssel während Migrationen und Notfallmaßnahmen
Vorfälle wie dieser führen oft zu „dringenden Migrationen“, die die beste Zeit für Phishing und böswillige Signaturanfragen sind.
Eine Hardware-Wallet wie OneKey kann helfen, indem sie private Schlüssel offline hält und eine Bestätigung von Transaktionen auf dem Gerät erfordert – wodurch die Wahrscheinlichkeit verringert wird, dass ein kompromittierter Computer oder eine Browser-Erweiterung stillschweigend schädliche Genehmigungen unterzeichnet. Dies behebt keinen anfälligen DeFi-Vertrag, verbessert aber die persönliche operative Sicherheit erheblich, wenn Sie unter Druck mit dApps interagieren.
Fazit
- Der Vorfall im Mai 2026 verdeutlicht, wie Legacy-Liquiditäts-Lock-Verträge wieder zu einem systemischen Risiko werden können – insbesondere auf sich schnell entwickelnden Ketten, bei denen Ausführungsfunktionen schnell weiterentwickelt werden.
- DxSales Aussage rahmt das Problem als auf v1-Sperren aus der Ära von 2021 beschränkt ein, wobei v2 und neuere Verträge nicht betroffen sind.
- Für Nutzer und Teams ist die umsetzbare Erkenntnis, alte Sperren zu inventarisieren, Vertragsversionen zu überprüfen und die Sicherheitspraktiken an die Realitäten von 2026 anzupassen: atomares Batching, delegierte Ausführung und schnellere Angreifer-Playbooks.
Wenn Sie die Schatzkammer verwalten oder regelmäßig DeFi-Transaktionen auf der BNB Chain signieren, sollten Sie OneKey als Teil einer umfassenderen Sicherheitsstrategie in Betracht ziehen: hardwaregestützte Schlüsselisolierung, sorgfältige Genehmigungsverwaltung und ruhige, überprüfbare Arbeitsabläufe für die Reaktion auf Vorfälle.
