📈 Get daily crypto insights that make you smarter about your money

How the Balancer Constructor Attack Executed a $128 Million Heist in Under 30 Minutes

On November 3, 2025, the DeFi ecosystem witnessed one of the most technically sophisticated exploits in its history. An attacker drained $128.64 million from Balancer V2 ComposableStablePools across six blockchain networks, completing the entire operation within 30 minutes. What made this attack particularly remarkable was not just its scale, but its execution method: the theft occurred entirely within a smart contract constructor, making it atomic and irreversible from the moment of deployment.

The Exploit Mechanics

The attack targeted a rounding error vulnerability in Balancer V2’s _upscaleArray function, which handles arithmetic scaling during stable pool invariant calculations. When token balances are pushed to extremely small values — specifically in the 8-9 wei range — Solidity’s integer division via the mulDown function introduces precision losses of up to 10% per operation.

The attacker deployed a contract at address 0x54B53503c0e2173Df29f8da735fBd45Ee8aBa30d using a three-address structure for operational security. The exploit itself executed in three distinct phases within each batch swap cycle:

Phase 1 — Boundary Adjustment: Large swaps of BPT tokens for underlying assets pushed specific token balances to the critical rounding threshold where precision errors are maximized.

Phase 2 — Precision Loss Trigger: Small swaps involving the boundary-positioned token caused the _upscaleArray function to round down during scaling, underestimating the invariant D and artificially suppressing BPT prices.

Phase 3 — Value Extraction: The attacker minted BPT at the suppressed price, then immediately redeemed for underlying assets at full value. The price discrepancy represented pure profit extracted from the pool.

This three-phase cycle repeated 65 times within a single batchSwap transaction. All stages executed atomically, preventing any external intervention and ensuring precision losses compounded across the shared Vault balance state.

Affected Systems

The exploit impacted Balancer V2 deployments across six blockchain networks, with Ethereum bearing the heaviest losses at approximately $100 million. The attacker drained 6,586 WETH (worth $24.5 million), 6,851 osETH ($26.9 million), and 4,259 wstETH ($19.3 million) from the Ethereum deployment alone.

Critically, the vulnerability extended beyond Balancer’s own pools. At least 27 protocol forks were also affected, including Beets on the Sonic Chain and Beethoven on Optimism. The shared codebase meant that a single mathematical flaw propagated across the entire ecosystem of Balancer-based protocols. Balancer V3, however, was not impacted, as it uses a different architecture.

The attack occurred while Bitcoin traded at approximately $106,547 and Ethereum at $3,602, meaning the stolen assets represented a substantial capital extraction from the DeFi ecosystem during a period of significant market capitalization.

The Mitigation Strategy

Balancer’s engineering and security teams responded by immediately pausing affected V2 pools and coordinating with blockchain analytics firms including Nansen and PeckShield to track the stolen funds. Check Point Research’s blockchain monitoring systems detected the exploit in real-time, providing detailed technical analysis within 48 hours.

The broader mitigation lesson centers on the limitations of the current audit paradigm. Balancer had undergone 11 security audits by firms including OpenZeppelin, Trail of Bits, Certora, and ABKD — yet the rounding error vulnerability remained undetected. This demonstrates that even extensive audit coverage may fail to identify complex, composable smart contract flaws that only manifest under specific edge-case conditions.

Recommended mitigation approaches include implementing invariant change validation checks between swap operations, adding bounds on minimum token balance thresholds to prevent boundary-condition exploitation, and deploying real-time monitoring systems that flag unusual batch swap patterns.

Lessons Learned

The Balancer exploit of November 3, 2025, offers several critical lessons for the DeFi industry. First, constructor-based attacks represent an emerging threat pattern where exploit logic executes during contract deployment, making the attack atomic and preventing any responsive action. Second, shared codebases across protocol forks create systemic risk — a single vulnerability can cascade across dozens of platforms simultaneously. Third, mathematical precision handling in smart contracts requires more rigorous testing at boundary conditions, particularly when dealing with stable pool invariant calculations.

The $128.64 million lost in this single incident contributed to 2025’s record total of over $2 billion stolen in crypto hacks, underscoring that DeFi security remains an unresolved challenge even for the most battle-tested protocols.

User Action Required

Users who held liquidity in Balancer V2 ComposableStablePools on November 3, 2025, should verify whether their positions were affected. Check transaction history for any unusual withdrawals or balance changes on that date. If you currently provide liquidity to any Balancer V2 stable pool or its forks, consider withdrawing until the vulnerability has been fully patched and verified by independent security researchers. Always diversify your liquidity provisions across different protocols and pool types to limit exposure to single-point-of-failure risks.

Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any financial decisions.

🌱 FOR BUSINESSES BitcoinsNews.com
Reach 100K+ Crypto Readers
Sponsored content, press releases, banner ads, and newsletter placements. Put your brand in front of Bitcoin's most engaged audience.

12 thoughts on “How the Balancer Constructor Attack Executed a $128 Million Heist in Under 30 Minutes”

  1. 65 cycles in a single batchSwap. the attacker knew the code better than the auditors. constructor-level exploits are nearly impossible to catch in review

    1. 65 cycles means they ran extensive simulation on a fork first. nobody executes that many iterations live without testing

  2. _deploy_rekt

    constructor exploits are the scariest because you literally cannot front-run them. by the time the contract is deployed the damage is done. auditors need to review deployment scripts not just final bytecode

    1. the gap between audited bytecode and actual deployment scripts is where every major exploit lives. auditors review the product not the construction process

  3. Absolutely wild that a constructor-level flaw could survive for so long in the wild. You’d think the initialization phase would be the most scrutinized part of the codebase during any audit. This heist really highlights how fragile even the biggest protocols can be when there’s a single point of failure in the logic.

    1. 8-9 wei range precision loss in mulDown. the vulnerability was always there, just nobody thought to push balances that low. brilliant and terrifying

      1. audit_miss_ the 8-9 wei precision loss was documented in the Solidity spec. anyone who read the integer division behavior carefully could have flagged this years ago

  4. 30 minutes for $128 million… that’s a higher hourly rate than most small countries. It’s getting harder to defend DeFi to my friends when these massive heists happen every other week. We need more than just audits; we need formal verification as the industry standard to prevent these logic flaws.

    1. jonathan the issue is the attack was atomic. by the time anyone noticed the $128M was already being laundered across chains

    2. Jonathan Wu 30 minutes for $128M is fast but the prep work took weeks. the three address setup and cross-chain deployment across six networks was months of planning

  5. Wait, can someone explain how the constructor was called again? Usually, those are one-and-done during deployment. If the attacker found a way to re-initialize the contract state, then the architecture must have had some seriously weird permissions settings. Great technical write-up, even if the outcome is brutal.

  6. Elena Rodriguez

    I’ve been using Balancer for years and always considered them one of the ‘safe’ ones. Seeing the step-by-step breakdown of how this heist was executed is a serious wake-up call. It doesn’t matter how ‘blue-chip’ a project is if the underlying smart contract has a fundamental vulnerability like this.

Leave a Comment

Your email address will not be published. Required fields are marked *

BTC$62,618.00-4.8%ETH$1,687.34-4.8%SOL$68.78-6.8%BNB$577.10-4.9%XRP$1.14-5.8%ADA$0.1612-5.8%DOGE$0.0824-5.5%DOT$0.9534-7.8%AVAX$6.30-9.5%LINK$7.82-5.5%UNI$3.00-9.8%ATOM$1.80-10.1%LTC$43.30-5.2%ARB$0.0821-7.0%NEAR$2.20-7.0%FIL$0.7672-7.0%SUI$0.7145-11.1%BTC$62,618.00-4.8%ETH$1,687.34-4.8%SOL$68.78-6.8%BNB$577.10-4.9%XRP$1.14-5.8%ADA$0.1612-5.8%DOGE$0.0824-5.5%DOT$0.9534-7.8%AVAX$6.30-9.5%LINK$7.82-5.5%UNI$3.00-9.8%ATOM$1.80-10.1%LTC$43.30-5.2%ARB$0.0821-7.0%NEAR$2.20-7.0%FIL$0.7672-7.0%SUI$0.7145-11.1%
Scroll to Top