#3 Balancer V2 Vorfall: Eine Rundungsinkonsistenz bricht die Invariante und breitet sich über Ketten aus

Am 3. November 2025 erlitten die Composable Stable Pools von Balancer V2 sowie mehrere davon abgeleitete Projekte auf verschiedenen Ketten einen koordinierten Exploit, der zu Gesamtverlusten von über 125 Millionen US-Dollar führte, wobei Berichten zufolge etwa 45 Millionen US-Dollar zurückgewonnen wurden. Die Grundursache war eine Preismanipulation, die durch Präzisionsverlust bei der Invariantenberechnung ermöglicht wurde, herrührend aus inkonsistenter Rundung zwischen den Aufskalierungs- und Abskalierungsoperationen, was letztendlich die BPT (Balancer Pool Token) Preislogik verzerrte.

Dieser Vorfall sticht nicht nur aufgrund des Ausmaßes der Verluste, sondern auch aufgrund der Subtilität des zugrunde liegenden Fehlers als einer der zehn bedeutendsten Sicherheitsvorfälle des Jahres 2025 hervor. Darüber hinaus breitete sich der Exploit schnell über mehrere Ketten aus und betraf sowohl Balancer als auch seine Forks, was hervorhebt, wie gemeinsame Codebasen und komponierbare DeFi-Infrastrukturen systemische Risiken erheblich verstärken können.

Wir haben einen ausführlichen Bericht veröffentlicht: "Detaillierte Analyse: Der Balancer V2 Exploit" [1], der eine detaillierte technische Aufschlüsselung liefert. Nachfolgend präsentieren wir eine prägnante Illustration des Vorfalls.

Hintergrund

Balancer V2 Composable Stable Pool

Die betroffene Komponente dieses Angriffs war der Composable Stable Pool [2] des Balancer V2 Protokolls. Diese Pools sind für Vermögenswerte konzipiert, die voraussichtlich nahe einer 1:1-Parität bleiben (oder zu einem bekannten Wechselkurs gehandelt werden) und ermöglichen große Swaps mit minimalen Preisimpact, wodurch die Kapitaleffizienz zwischen gleichartigen oder korrelierten Vermögenswerten erheblich verbessert wird. Jeder Pool hat seinen eigenen Balancer Pool Token (BPT), der den Anteil des Liquiditätsanbieters am Pool repräsentiert, zusammen mit den entsprechenden zugrunde liegenden Vermögenswerten.

Dieser Pool verwendet Stable Math (basierend auf Curves StableSwap Modell), wobei die Invariante D den virtuellen Gesamtwert des Pools darstellt.
Der BPT-Preis kann approximativ berechnet werden als:

Preis(BPT) \approx \frac{D}{totalSupply}

Aus der obigen Formel ergibt sich, dass, wenn D auf dem Papier kleiner gemacht werden kann (auch ohne tatsächlichen Verlust von Geldern), der BPT-Preis billiger erscheint.

`batchSwap()` und `onSwap()`

Balancer V2 stellt die Funktion batchSwap() bereit, die Multi-Hop-Swaps innerhalb des Vaults [3] ermöglicht. Es gibt zwei Arten von Swaps, die durch einen Parameter bestimmt werden, der an diese Funktion übergeben wird:

GIVEN_IN ("Gegeben Ein"): Der Aufrufer gibt den genauen Betrag des Eingabetokens an, und der Pool berechnet den entsprechenden Ausgabebetrag.
GIVEN_OUT ("Gegeben Aus"): Der Aufrufer gibt den gewünschten Ausgabebetrag an, und der Pool berechnet den erforderlichen Eingabebetrag.

Typischerweise besteht ein batchSwap() aus mehreren Token-zu-Token-Swaps, die über die onSwap() Funktion ausgeführt werden. Dieser Prozess beinhaltet unweigerlich Mengenberechnungen, die an die Invariante D [1] gebunden sind.

Skalierung und Rundung

Um die Berechnungen über verschiedene Token-Salden hinweg zu normalisieren, führt Balancer die folgenden beiden Operationen durch:

Aufskalierung: Skaliert Salden und Mengen auf eine einheitliche interne Präzision hoch, bevor Berechnungen durchgeführt werden.
Abskalierung: Konvertiert die Ergebnisse zurück in ihre native Präzision und wendet eine gerichtete Rundung an (z. B. Eingabemengen werden normalerweise aufgerundet, um sicherzustellen, dass der Pool nicht zu wenig berechnet, während Ausgabemengen oft abgerundet werden).

Aufskalierung und Abskalierung sind theoretisch gepaarte Operationen: Multiplikation bzw. Division. Es besteht jedoch eine Inkonsistenz in der Implementierung dieser beiden Operationen. Insbesondere hat die Abskalierungsoperation zwei Varianten oder Richtungen: divUp und divDown. Im Gegensatz dazu hat die Aufskalierungsoperation nur eine Richtung, nämlich mulDown.

Schwachstellenanalyse

Das zugrunde liegende Problem ergibt sich aus der Abrundung, die bei der Aufskalierung in der Funktion BaseGeneralPool._swapGivenOut() durchgeführt wird. Insbesondere rundet _swapGivenOut() swapRequest.amount durch die Funktion _upscale() falsch ab. Der resultierende abgerundete Wert wird anschließend als amountOut bei der Berechnung von amountIn über _onSwapGivenOut() verwendet. Dieses Verhalten widerspricht der gängigen Praxis, dass Rundungen so erfolgen sollten, dass sie dem Protokoll zugutekommen.

Daher unterschätzt der berechnete amountIn für einen gegebenen Pool (wstETH/rETH/cbETH) die tatsächlich erforderliche Eingabe. Dies ermöglicht es einem Benutzer, eine geringere Menge eines zugrunde liegenden Vermögenswerts (z. B. wstETH) gegen einen anderen (z. B. cbETH) auszutauschen, wodurch die Invariante D aufgrund der reduzierten effektiven Liquidität verringert wird. Infolgedessen wird der Preis des entsprechenden BPT (wstETH/rETH/cbETH) künstlich verbilligt, da BPT-Preis = D / totalSupply ist.

Angriffsübersicht

Der Angreifer führte einen zweistufigen Angriff durch, wahrscheinlich um das Entdeckungsrisiko zu minimieren:

In der ersten Stufe wurde der Kern-Exploit innerhalb einer einzigen Transaktion durchgeführt, ohne sofortigen Gewinn zu erzielen.
In der zweiten Stufe erzielte der Angreifer Gewinne, indem er Vermögenswerte in einer separaten Transaktion zurückzog.

Die erste Stufe kann weiter in zwei Phasen unterteilt werden: Parameterberechnung und Batch-Swap. Nachfolgend illustrieren wir diese Phasen anhand einer Beispiel-Angriffstransaktion (TX) auf Arbitrum.

Die Parameterberechnungsphase

In dieser Phase kombinierte der Angreifer Off-Chain-Berechnungen mit On-Chain-Simulationen, um die Parameter jedes Hops in der nächsten (Batch-Swap-)Phase präzise abzustimmen, basierend auf dem aktuellen Zustand des Composable Stable Pools (einschließlich Skalierungsfaktoren, Verstärkungskoeffizient, BPT-Rate, Swap-Gebühren und anderer Parameter). Der Angreifer setzte auch einen Hilfskontrakt ein, um bei diesen Berechnungen zu helfen, der möglicherweise dazu diente, die Exposition gegenüber Front-Running zu reduzieren. Weitere Einzelheiten finden Sie in [1].

Die Batch-Swap-Phase

Dann kann die batchSwap()-Operation in drei Schritte unterteilt werden:

Schritt 1: Der Angreifer tauscht BPT (wstETH/rETH/cbETH) gegen zugrunde liegende Vermögenswerte, um den Saldo eines Tokens (cbETH) präzise an den Rand einer Rundungsgrenze (Betrag = 9) anzupassen. Dies schafft die Bedingungen für Präzisionsverlust im nächsten Schritt.

Schritt 2: Der Angreifer tauscht dann zwischen einem anderen zugrunde liegenden Vermögenswert (wstETH) und cbETH unter Verwendung eines konstruierten Betrags (= 8). Aufgrund der Abrundung beim Skalieren von Token-Beträgen wird der berechnete Δx geringfügig kleiner (8,918 auf 8), was zu einem unterschätzten Δy und somit zu einer kleineren Invariante (D aus Curves StableSwap-Modell) führt. Da BPT-Preis = D / totalSupply ist, wird der BPT-Preis künstlich verbilligt.

Schritt 3: Der Angreifer tauscht die zugrunde liegenden Vermögenswerte um und wandelt sie zurück in BPT, stellt das Gleichgewicht wieder her und profitiert gleichzeitig vom verbilligten BPT-Preis.

Zusammenfassung

Dieser Vorfall umfasste eine koordinierte Reihe von Exploit-Transaktionen, die auf die Composable Stable Pools von Balancer V2 und mehrere abgeleitete Implementierungen auf verschiedenen Ketten abzielten und zu erheblichen Verlusten führten. Nach dem ersten Exploit tauchten schnell Nachahmer-Transaktionen auf, die zeigten, wie schnell sich ein Angriffsmuster verbreiten kann, sobald es bekannt wird.

Schlüsselerkenntnisse:

Rundungs- und Präzisionsbehandlung: Jede Skalierungs- und Präzisionsoperation bei Token-Beträgen sollte in der Richtung runden, die dem Protokoll zugutekommt. Eine einzige Inkonsistenz zwischen _upscale() (nur Abrundung) und den Abskalierungsoperationen (gerichtete Rundung) reichte aus, um eine ausnutzbare Preisverzerrung zu erzeugen.
Wettrüsten bei der Sicherheit: Der Angreifer teilte Manipulation und Gewinnentnahme auf separate Transaktionen auf, um der Entdeckung zu entgehen. Erkennungssysteme sollten verwandte Transaktionen korrelieren und nicht nur einzelne kennzeichnen.
Betriebssicherheit: Sobald das Exploit-Muster öffentlich bekannt war, replizierten Nachahmer es innerhalb von Minuten über verschiedene Ketten hinweg. Protokolle, die eine Codebasis teilen, benötigen eine koordinierte Überwachung und schnelle Cross-Chain-Pause-Fähigkeiten.

Referenz

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits (einschließlich Smart Contracts, Blockchain und Wallets) durchzuführen, Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zu verfolgen und AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen zu erfüllen.

BlockSec hat zahlreiche Blockchain-Sicherheitsarbeiten auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von Milliarden gesichert.