Abstract: On November 3, 2025, the decentralized exchange Balancer V2 suffered its most serious security incident in history, resulting in the theft of assets ranging from $116.6 million to $128.6 million. Attackers exploited vulnerabilities in Balancer V2's smart contracts related to the swap/imbalance mechanism, successfully withdrawing funds from liquidity pools on multiple blockchains, including the Ethereum mainnet, Arbitrum, Base, and Optimism. This attack not only exposed long-standing security vulnerabilities in the Balancer V2 architecture but also revealed systemic risks in cross-chain protocol deployments. The core vulnerability of this attack was related to flaws in Balancer V2's smart contract inspection mechanism, particularly insufficient verification when handling swap operations and pool balance states. In contrast, Balancer V3 successfully avoided the impact of this attack by introducing transient storage (EIP-1153), an improved Vault architecture, and stricter security mechanisms. The attackers were able to launch attacks on multiple chains simultaneously primarily because Balancer V2 deployed the same smart contract code on different blockchains, making the same vulnerability exploitable in all deployment environments. I. Introduction 1.1 Background Overview Balancer is a crucial Automated Market Maker (AMM) protocol in the DeFi ecosystem, providing critical liquidity infrastructure for decentralized finance since its launch in 2020. As a programmable liquidity protocol, Balancer allows users to create custom pools containing up to eight different tokens and supports flexible weighting. Prior to the attack, Balancer managed over $750 million in Total Value Locked (TVL), with over $350 million held on the Ethereum mainnet. However, in the early morning of November 3, 2025, blockchain security firm PeckShield first detected abnormal fund outflows, and subsequently, multiple security agencies, including Nansen, confirmed that Balancer V2 was under a large-scale attack. Initial reports indicated losses of $70.9 million, but as the attack continued, the final estimated losses climbed to between $116.6 million and $128.6 million, making it one of the most serious security incidents in the DeFi space in 2025. The stolen assets primarily included 6,851 osETH (approximately $26.86 million), 6,590 WETH (approximately $24.5 million), and 4,260 wstETH (approximately $19.3 million). 1.2 Analysis Objectives This report aims to provide a comprehensive technical analysis of the Balancer V2 attack, delving into the root causes of the smart contract vulnerability, the attack mechanism, the cross-chain propagation path, and its correlation with other DeFi vulnerabilities. Through a systematic analysis of the architectural differences between Balancer V2 and V3, we will reveal why V3 was able to avoid this attack and provide valuable references for the future security design of DeFi protocols. Furthermore, this report will assess the technical complexity of vulnerability remediation and propose feasible solutions and preventative measures. 1.3 Research Methodology This study employs a multi-source information comprehensive analysis method, integrating real-time monitoring data from blockchain security companies, official post-incident reports, academic research results, and historical vulnerability cases. By comparing and analyzing the smart contract code of different versions of Balancer, reviewing on-chain transaction records, and studying security events similar to AMM protocols, we have constructed a comprehensive technical analysis framework. The research referenced analysis reports from authoritative security organizations such as PeckShield, SlowMist, and BlockSec, as well as Balancer's official documentation and technical white papers. II. Technical Details of Balancer V2 Smart Contract Vulnerabilities 2.1 Overview of Balancer V2 Core Architecture When Balancer V2 was launched in 2021, it introduced a revolutionary architectural design. Its core innovation lies in the complete separation of token management from pool logic. This design is implemented through a single Vault contract, which acts as the central hub for all Balancer pools, responsible for managing all token holding, accounting, and transfer operations. This "separation of concerns" architecture should theoretically provide higher security and efficiency, as sensitive token operations are centralized in a rigorously audited contract. In Balancer V2's three-layer architecture, the Router contract acts as the entry point for the protocol, receiving user transaction requests and routing them to the Vault. The Vault contract maintains the token balance ledger for all pools and uses delegatecalls to call specific pool contracts to perform swap calculations. The pool contract itself does not hold any tokens; it is only responsible for implementing specific pricing curve logic (such as the constant product formula for weighted pools or the StableSwap invariant for stable pools). This design allows Balancer to support multiple pool types, including weighted pools, stable pools, linear pools, and composable stable pools. 2.2 Swap Mechanism and Imbalance Issues Balancer V2's swap mechanism is a core function of the entire protocol, allowing users to exchange any two tokens within a pool. In normal operation, the swap function calculates the number of tokens that should be given or received according to the pool's invariant formula and then updates the internal ledger in the Vault. However, this seemingly simple process actually hides complex state management challenges, especially when dealing with multi-hop transactions and batch swaps. This attack likely exploited a validation flaw in the swap operation, similar to the rounding error vulnerability Balancer encountered in 2023. In the 2023 attack, attackers discovered that when linear pools processed very small amounts of token swaps, some output values were zeroed out due to rounding down, but the corresponding input tokens were still added to the pool's virtual balance. This asymmetry allowed attackers to unilaterally add value to the pool, thereby manipulating the exchange rate. Although the 2023 vulnerability was patched at the time, the 2025 attack indicated that similar or related flaws might exist in Balancer V2's core swap mechanism. The Imbalance mechanism was originally designed to ensure that the pool remained invariant after a swap operation, but in practice, there could be issues with improper handling of boundary conditions. When dealing with special types of tokens (such as interest-bearing tokens, rebased tokens, or deflationary tokens), the pool's internal ledger might deviate from the actual token balance. Attackers could exploit this deviation to manipulate the pool's state through carefully crafted transaction sequences, ultimately extracting value beyond its actual contribution. 2.3 Flawed Smart Contract Check Function According to preliminary reports, the root cause of this attack was a "faulty smart contract check." This description points to shortcomings in Balancer V2's validation of swap operation legitimacy. In robust AMM implementations, rigorous invariant checks should be performed after each state change to ensure the core properties of the pool are maintained. However, Balancer V2's implementation may have omitted or weakened these checks at certain critical points. Specifically, the problems may arise in the following areas: First, Vault needs to track net token flows between multiple pools when handling batchSwap operations. If a validation step fails in this complex settlement process, an attacker could construct a seemingly legitimate sequence of transactions that actually violates pool invariants. Second, the interaction between linear pools and composable stable pools involves complex exchange rate calculations and virtual supply management; any precision issues or mishandling of boundary conditions in these calculations can be exploited. Third, Vault's token balance caching mechanism may return outdated data in some cases, causing subsequent operations to be based on incorrect states. Historical vulnerability analysis reveals a fundamental problem: the deflationary token attack that Balancer suffered in 2020 exposed a fundamental issue: the protocol assumes that all ERC20 token transferFrom operations will transfer a precise specified amount, but in reality, some tokens incur transfer fees. While this specific issue has been fixed, similar "hypothesis-based" patterns may reappear elsewhere. The 2025 attack may have involved incorrect assumptions about certain edge cases, allowing attackers to bypass security checks with carefully crafted inputs. 2.4 Attack Flow Reconstruction Based on on-chain transaction data and analysis by security agencies, we can reconstruct the general flow of the attack. Attackers first obtain large flash loan from platforms like dYdX, allowing them to manipulate huge sums of money in a single transaction without actually owning these assets. Next, attackers utilize Vault's batchSwap feature to carefully construct a series of seemingly normal swap operations that actually exploit validation flaws. The key to the attack lies in manipulating the internal state of the pool to create inconsistencies with the actual token balance. This can be achieved in the following ways: First, by using specific token combinations and swap paths to trigger Vault's boundary conditions, causing certain validation checks to be bypassed or return incorrect results. Second, by exploiting exchange rate calculation flaws in linear or composable stable pools, creating rounding errors through extremely small or large swap volumes. Third, by constructing circular swap paths between multiple pools, amplifying profits by exploiting exchange rate differences and time delays between different pools. After successfully manipulating the pool state, the attackers performed withdrawals, extracting more value than they had actually deposited. These obviously unbalanced transactions passed verification due to flaws in Vault's final settlement checks. Finally, the attackers repaid the flash loan and transferred the stolen assets to newly created wallet addresses. Notably, these wallets had no ETH balance used to pay gas fees before the attack, indicating that the attackers used some form of bulk operation or meta transaction to bypass normal gas payment requirements. 2.5 Relevance of Historical Vulnerabilities Balancer's security history provides important context for understanding this attack. The deflationary token attack in June 2020 was Balancer's first major security incident, resulting in approximately $500,000 in losses. The attackers exploited a flawed assumption in Balancer's ERC20 token transfer behavior: the protocol assumes that transferFrom(amount) always transfers the exact amount of tokens, but deflationary tokens (such as STA) deduct a 1% fee on each transfer. By repeatedly exchanging WETH and STA, the attackers gradually depleted the STA balance in the pool, while manipulating the exchange rate by exploiting the mismatch between the internal ledger and the actual balance. The rounding error vulnerability in August 2023 represented a more sophisticated attack vector. This vulnerability affected Balancer V2's Boosted Pools, where attackers discovered that when performing very small swaps in linear pools, the output amount could be zeroed out due to rounding down, while the input tokens would still increase the virtual balance. By exploiting this, attackers could manipulate the exchange rate of BPT (Balancer pool token), thereby acquiring assets in the pool at a lower-than-market price. This attack resulted in approximately $2.1 million in losses, with Balancer itself losing $1 million and the fork protocol Beethoven X losing $1.1 million. The attack in November 2025 is likely an evolution or combination of these historical vulnerabilities. Attackers may have discovered a new way to trigger similar ledger inconsistencies or exchange rate manipulation, or found a previously undiscovered boundary condition. Importantly, although the Balancer team implemented fixes after each attack, some fundamental flaws in the underlying architecture do not appear to have been completely resolved. This suggests that the problem is not merely a specific code bug, but may involve systemic weaknesses in the V2 architecture design. III. Comparison of Security Differences between Balancer V2 and V3 3.1 Balancer V3 Architectural Innovation Balancer V3 represents a fundamental shift in the protocol's design philosophy. Launched at the end of 2024, it aims to address the technical debt and security vulnerabilities accumulated in V2. The core improvements of V3 revolve around a more standardized Vault architecture, native support for transient storage, and stronger security mechanisms. These improvements not only enhance the protocol's performance and flexibility but, more importantly, fundamentally strengthen its security. The most significant innovation of V3 is the full adoption of transient storage introduced by EIP-1153. This new storage mechanism uses the TLOAD and TSTORE opcodes, allowing data to exist within the lifecycle of a single transaction and be automatically cleared after the transaction ends. Compared to traditional persistent storage, transient storage significantly reduces gas costs, and more importantly, it naturally prevents certain types of reentrancy attacks. In V3, all intermediate transaction states are tracked through transient storage, making it impossible for external contracts to read inconsistent states during transaction execution, thus fundamentally blocking certain attack vectors. V3 also introduces a "til"-mode accounting system, tracking net balance changes across a series of operations within a single transaction and performing final settlement only at the end of the transaction. This approach not only improves gas efficiency but also enhances security by ensuring the atomicity of all intermediate state changes. If any step in a transaction fails, the entire sequence of operations is rolled back, leaving no inconsistent state. This contrasts sharply with the partial execution issues that could occur in certain situations in V2. 3.2 Comparison of Core Security Mechanisms In terms of token balance management, V2 and V3 employ fundamentally different approaches. V2's Vault stores the token balance of each pool as an independent mapping and uses a sophisticated caching mechanism to optimize gas consumption. However, this caching mechanism can return expired data in certain boundary cases, especially when dealing with interest-bearing or rebased tokens. V3 ensures the atomicity of updates to the underlying pool token balance and BPT supply by implementing the Vault itself as a multi-token ERC20 contract, natively managing all Balancer pool tokens (BPT). This design eliminates the window of unsynchronized balances and supplies that could occur in V2. In terms of reentrancy protection, V3's approach is more comprehensive and modern. V2 uses the traditional nonReentrant modifier to prevent reentrancy attacks, but this approach has a subtle vulnerability: so-called "read-only reentrancy." An external protocol might call its public query function while the Vault is "unlocked," reading inconsistent intermediate states and making decisions based on incorrect price information. V3 completely blocks this attack path through transient storage flags and stricter state checks. Any operation attempting to query the Vault state during transaction execution is rejected unless explicitly using a query pattern. Exchange rates and precision handling are another key area of differentiation. V2 uses scaling factors to normalize tokens with different decimal places, but this transformation can lead to precision loss or overflow in extreme cases. V3's Vault automatically scales all token balances to a uniform 18 decimal places for calculations and is deeply integrated with exchange rate providers, natively supporting interest-bearing assets such as Liquidity Staking Tokens (LSTs). More importantly, V3 implements a "protocol-first" rounding strategy in all mathematical operations: output amounts are rounded down (to avoid overpaying) and input amounts are rounded up (to avoid underpaying). This simple yet crucial principle permeates the entire codebase, effectively preventing a recurrence of rounding error vulnerabilities like the one in 2023. 3.3 How V3 Avoided This Attack V3's survival in this attack is primarily attributed to its multi-layered security enhancements. First, the transient accounting system rigorously tracks all token flows in every transaction through the functions _supplyCredit(), _takeDebt(), and _accountDelta(). These functions ensure that the net change in all tokens must be zero at the end of the transaction; any imbalance will result in a transaction rollback. Verification flaws that might exist in V2 are eliminated in V3 by this mandatory final check. Second, V3's Vault recalculates the pool balance and exchange rate at key points in each pool operation, especially after executing any Hooks. This prevents malicious or flawed Hooks from attacking the main pool logic through reentrancy or state manipulation. V2's defenses in this regard are weaker, potentially allowing certain specially crafted sequences of interactions to bypass verification. Third, V3 introduces minimum transaction amount limits (_MINIMUM_TRADE_AMOUNT and _MINIMUM_WRAP_AMOUNT), which prevent attacks that trigger rounding errors or boundary conditions through extremely small transactions. This simple yet effective defense directly addresses the micro-manipulation attacks that V2 has repeatedly encountered in its history. Finally, the V3 codebase has undergone more systematic security audits and formal verification. The protocol team made the codebase publicly available for community review before the V3 release and collaborated with several top security companies on competitive audits. This "security-first" development culture, coupled with lessons learned from historical vulnerabilities in V2, has enabled V3 to avoid many potential security pitfalls during its design phase. 3.4 Upgrade Path and Compatibility Challenges Although V3 has significant security advantages, migrating from V2 to V3 is not a simple contract upgrade, but requires a complete protocol redeployment and liquidity migration. This process faces multiple challenges. First, V2 and V3 are incompatible in terms of APIs and data structures, and DeFi applications that integrate Balancer require significant code modifications to support V3. Secondly, liquidity providers need to withdraw funds from V2 pools and re-deposit them into V3 pools, a process involving transaction costs and temporary liquidity fragmentation. A more serious problem lies in the non-pauseable nature of V2 pools. Balancer V2 implements a "pause window" mechanism, allowing pool operations to be paused and users to withdraw funds when an urgent vulnerability is discovered. However, this window expires after a certain period, and the pool cannot be paused after that. Furthermore, earlier pool types (such as some linear pools) do not support pause functionality at all. This means that when a vulnerability is discovered, the protocol team cannot enforce protection for all users' funds and can only rely on users to withdraw funds promptly. The 2025 attack likely exploited these older, non-pauseable pools. From a technical perspective, the most thorough solution is to completely abandon V2 and force all liquidity to migrate to V3. However, this is difficult to achieve in a decentralized environment because the protocol team cannot force user action. A more realistic solution is to implement emergency patches on V2; while this cannot completely eliminate the architectural weaknesses, it can at least block known attack vectors. Meanwhile, incentives (such as token rewards or higher transaction fee sharing) encourage liquidity providers to voluntarily migrate to V3. IV. Cross-Chain Attack Mechanism Analysis 4.1 Balancer's Cross-Chain Deployment Architecture As a multi-chain protocol, Balancer deploys its V2 version on multiple blockchain networks, including the Ethereum mainnet, Arbitrum, Optimism, Base, Polygon, and Avalanche. This multi-chain strategy aims to leverage the advantages of different networks: Ethereum offers the highest security and liquidity, Layer 2 networks like Arbitrum and Optimism offer lower transaction costs, while other chains like Polygon and Avalanche attract specific user communities and application ecosystems. Technically, Balancer deploys independent but almost identical smart contract instances on each chain. This "copy-and-paste" deployment model is very common in the DeFi field because it simplifies development and maintenance: the same audited code can be reused on multiple networks, theoretically providing consistent security guarantees. The bytecode of Vault contracts, Pool contracts, and Router contracts is almost identical across different chains, with only minor differences in deployment parameters (such as initial liquidity or governance addresses). A key feature of this architecture is the independence between the chains. Each Balancer instance on each chain has its own independent liquidity pool and token balance, and they do not communicate directly with each other. A user's liquidity share in a Balancer pool on Ethereum cannot be used directly on Arbitrum unless transferred via a cross-chain bridge. This isolation helps limit the spread of risk under normal circumstances, but when faced with vulnerabilities at the smart contract level, this independence becomes a systemic weakness. 4.2 Systemic Risks of Same Source Code The most alarming feature of this attack is its ability to affect multiple blockchains simultaneously. Attackers do not need to develop different exploits for each chain; instead, they can use almost the same attack script to execute repeatedly on all networks that have Balancer V2 deployed. This "build once, attack everywhere" model stems from the practice of using the same code in cross-chain deployments. When a smart contract vulnerability exists in the core code logic, that vulnerability is replicated in all deployment instances using the same code. In the case of Balancer V2, both the Ethereum Vault contract and the Arbitrum Vault contract contain the same swap verification flaw. Once an attacker discovers and verifies an exploit targeting the Ethereum mainnet, they can repeat the same attack on other EVM-compatible chains simply by modifying the target contract address and adjusting gas parameters. This systemic risk is known as a "single point of failure" in traditional software security, but its impact is far more profound in the blockchain environment. Due to the immutability of smart contracts, even if a vulnerability is discovered on one chain and a fix is developed, it cannot be quickly applied to all chains. Each chain needs to independently deploy a new version of the contract and migrate liquidity, a process that can take days or even weeks. During this time, attackers have ample time to continue exploiting on unpatched chains. More seriously, the concurrency of cross-chain attacks amplifies financial losses. If a vulnerability only affects a single blockchain, attackers are limited by the available liquidity and gas costs on that chain. However, when an attack can be executed simultaneously on multiple chains, the total loss can be several times that of a single chain. In the Balancer attack, although the Ethereum mainnet suffered the largest loss (approximately $91 million), the additional losses on Arbitrum, Base, and Optimism pushed the total amount past the $100 million mark. 4.3 Attacker's Cross-Chain Coordination Strategy Analysis of on-chain data reveals that the attackers demonstrated a high level of technical skill and meticulous planning. The attacks were launched almost simultaneously on multiple chains, indicating that the attackers used automated scripts or bot networks to coordinate their actions. This coordination is crucial for maximizing profits, as the protocol team might implement defensive measures (such as suspending pools or warning users) on other chains once an attack on one chain is detected. The attackers likely first validated the exploit on lower-cost test networks or sidechains to ensure the correctness and reliability of the attack logic. Subsequently, they chose to launch the attack during periods of relatively low liquidity to reduce the risk of detection by real-time monitoring systems. The construction of the attack transactions indicates that the attackers had a deep understanding of the internal mechanisms of Balancer V2, enabling them to accurately calculate the number of tokens and the order of exchanges required to trigger the vulnerability. Particularly noteworthy is the attackers' focus on gas optimization. In an environment like the Ethereum mainnet where gas costs are high, the attackers used various techniques to reduce transaction costs, including batch operations, efficient use of flash loan, and streamlined contract call chains. On Layer 2 networks, although gas costs are lower, the attackers still optimized the transaction structure to maximize the profit margin of each attack. This professionalism suggests that the attack was likely orchestrated by an experienced team, rather than a single hacker. The post-attack fund transfer strategy also reveals a cross-chain mindset. Stolen assets were rapidly dispersed to multiple newly created wallet addresses and then laundered through various paths. Some funds remained on the original chain and were exchanged through decentralized exchanges, while others were transferred to other networks via cross-chain bridges. This dispersion strategy increases the difficulty of tracking and freezing funds and provides attackers with multiple monetization channels. 4.4 Security Governance Challenges of Cross-Chain Protocols This attack highlights the unique challenges faced by cross-chain protocols in terms of security governance. In a single-chain environment, the protocol team can focus on monitoring the state of one network and respond quickly to anomalies. However, in a multi-chain environment, monitoring resources are dispersed, while the attack surface expands exponentially. The Balancer team needs to monitor more than a dozen blockchain networks simultaneously, each with its own block time, transaction patterns, and user behavior characteristics. Incident response mechanisms are also more complex in a cross-chain environment. When an attack is detected on one chain, the team needs to quickly assess whether all chains are threatened and then coordinate multi-chain defense measures. However, as mentioned earlier, some legacy pools lack pause functionality, making protocol-level global defense impossible. Teams can only notify users through social media and front-end alerts, but this reliance on user initiative has limited effectiveness in rapidly evolving attack scenarios. Code upgrades and patch deployments are equally challenging in cross-chain environments. Even if a new version of the contract is developed to fix vulnerabilities, deploying it across all chains requires significant work and coordination. Each chain may have different deployment requirements, gas price fluctuations, and network congestion. More importantly, upgrades require governance voting on all chains (if the protocol uses decentralized governance), and governance participation and voting speed can vary greatly across different chains. In the long run, the DeFi industry needs to develop new security paradigms to address the challenges of cross-chain deployment. Some possible directions include: implementing cross-chain monitoring and alerting systems capable of detecting anomalous behavior on one chain and automatically triggering defensive measures on other chains; developing formal verification tools to mathematically prove smart contracts before deployment, ensuring that core security attributes are satisfied on all chains; establishing cross-chain security alliances to allow different protocols to share threat intelligence and defense strategies; and exploring modular architectures that allow security patches to be quickly applied to all chains through upgradeable proxy contracts. V. Case Studies of Vulnerabilities in Similar DeFi Protocols 5.1 Common Security Issues of AMM Protocols Automated Market Maker (AMM) protocols play a central role in the DeFi ecosystem, but their complex mathematical logic and state management make them prime targets for attackers. By analyzing historical vulnerabilities in major AMM protocols such as Balancer, Uniswap, and Curve, we can identify several recurring security issues, the root of which often lies in the inherent complexity of the AMM model itself. Reentrancy attacks are one of the most persistent threats to AMM protocols. While the concept of reentrancy attacks has been widely known since the DAO attacks, the specificities of AMMs make defense more nuanced. In 2023, Balancer suffered a specific form of reentrancy attack—"read-only reentrancy." In this attack, instead of re-entering the function that modifies the state, the malicious contract calls its read-only query functions (such as getPoolTokens) when the Vault is in an inconsistent state. External protocols using Balancer pools as price oracles may read incorrect price data, leading to flawed decisions in their own protocols. The Vyper compiler vulnerability that Curve Finance encountered in 2023 was essentially a reentrancy problem: a compiler bug caused different functions' @nonreentrant decorators to use independent locks, making cross-function reentrancy possible. Precision loss and rounding errors constitute another serious threat. AMM protocols involve a large number of division and multiplication operations, requiring unit conversions when handling tokens with different decimal places. In Balancer's Boosted Pools attack in 2023, attackers systematically manipulated the BPT exchange rate by exploiting the down-rounding behavior of linear pools when handling extremely small amounts. Similarly, Velodrome Protocol was attacked due to rounding errors in calculating invariants: when x*y was less than 1e18, an intermediate variable was zeroed out, causing the product constant verification to fail and allowing attackers to empty the pool. These cases demonstrate that even seemingly trivial precision handling issues can be amplified into major vulnerabilities in a well-designed attack sequence. Price manipulation is a structural challenge faced by AMM protocols. Since the price of a pool is entirely determined by the proportion of its internal tokens, any operation that can significantly alter this proportion can cause the price to deviate from the market. While such deviations are usually quickly corrected by arbitrageurs, attackers can exploit this brief window in certain situations. Flash loan significantly lower the barrier to price manipulation attacks because attackers do not need a large amount of capital to temporarily influence the state of the pool. In the PancakeSwap BH token incident in 2023, attackers used flash loan to exchange BH at an extremely low price and then withdrew liquidity from a specific pool at an inflated price, profiting $1.27 million. 5.2 Curve Finance Vyper Compiler Vulnerability Depth Comparison The attack on Curve Finance in July 2023 provides an important case study for understanding the impact of compiler-level vulnerabilities. The root cause of this attack lies not in the Curve protocol's code logic itself, but in a critical bug in the Vyper compiler (versions v0.2.15, v0.2.16, and v0.3.0). This bug causes all functions using the `@nonreentrant` decorator to be assigned independent storage slots, instead of sharing a lock according to the key specified by the developer. This means that even if two functions declare the use of the same reentrant lock, the compiler actually creates independent locks for them, making cross-function reentrancy possible. The attacker exploited this vulnerability to attack multiple Curve liquidity pools, particularly the pETH/ETH pool. The attack flow involves first calling the pool's `remove_liquidity` function, which sends ETH to the user (triggering an external call). In the callback of this external call, the attacker re-enters and calls the `add_liquidity` function. Although both functions use the `@nonreentrant("lock")` decorator, due to the compiler bug, they actually use different locks, so the second call is not blocked. By re-entering `add_liquidity` before updating the state using `remove_liquidity`, the attacker was able to manipulate the pool based on the outdated state, ultimately stealing approximately $11 million from the pETH/ETH pool. This case shares several important similarities and implications with the Balancer situation. First, both involve seemingly robust security mechanisms (Curve's reentrancy lock and Balancer's verification checks) that have flaws in their actual implementation. Second, neither vulnerability is easily detected by routine audits because they involve boundary conditions or issues with the underlying toolchain. Third, both attacks demonstrate how attackers can leverage flash loan and sophisticated transaction sequences to amplify the impact of vulnerabilities in the modern DeFi environment. However, the Curve case also reveals a key difference: when a vulnerability originates in the compiler rather than the application code, the fix becomes much more complex. The Curve team had to wait for the Vyper community to release a fix before recompiling and deploying all affected contracts. In contrast, if the Balancer V2 vulnerability originated in the contract logic (rather than the underlying tools), a patch could theoretically be developed and deployed much faster. However, as we will discuss in the remediation section, Balancer V2's non-upgradeability and expired pause window make it difficult to quickly fix even when problems are identified. 5.3 Lessons from Cross-Chain Bridge Attacks While Balancer itself is not a cross-chain bridge, attacks on cross-chain bridges provide valuable lessons for understanding the security risks of cross-chain deployments. The Ronin Bridge attack in March 2022 was one of the largest hacks in cryptocurrency history, resulting in a loss of $620 million. Attackers obtained five of the nine validator private keys through social engineering and phishing attacks, thereby gaining control of the bridge's multi-signature mechanism. Most shockingly, the attack was only discovered six days after it occurred, a delay that gave attackers ample time to transfer and launder funds. The $320 million attack on Wormhole Bridge in February 2022 stemmed from a flaw in the smart contract verification logic. Attackers discovered that the bridge's signature verification function could be bypassed, allowing them to mint uncollateralized wETH tokens on Solana. The root of this vulnerability lies in improper assumptions about Solana's unique programming model, highlighting a key risk in cross-chain deployments: differences in execution environments and security models across different blockchains can cause code secure on one chain to become vulnerable on another. The Nomad Bridge attack in August 2022 demonstrated a "chaotic robbery." Due to an initialization error in a contract upgrade, anyone could withdraw funds from the bridge. Once the first attacker discovered and exploited the vulnerability, their transactions were publicly visible on the blockchain, leading to hundreds of copycats (including MEV bots and ordinary users) imitating them, ultimately resulting in the theft of approximately $200 million within hours. This case demonstrates that in the transparent environment of blockchains, once a vulnerability is publicly exploited, its impact can spread rapidly. These cross-chain bridge cases offer several insights into understanding Balancer attacks. First, while private key management is not the root cause of Balancer's problems, it highlights the risks of centralized control points. Some of Balancer's administrative functions (such as the pause pool) require privileged access, and if these permissions are abused or leaked, it can have serious consequences. Second, the importance of smart contract verification logic is crucial in both types of protocols. Whether it's the bridge's signature verification or the AMM's swap verification, any flaw can be exploited. Third, the value of proactive monitoring and rapid response cannot be overstated. If Ronin Bridge had a better monitoring system, the losses could have been significantly reduced. 5.4 The Enduring Challenges of Deflationary Tokens and Non-Standard ERC20s The deflationary token attack that Balancer suffered in 2020 was not only the protocol's first major security incident, but also represented a persistent challenge facing the entire DeFi space: how to securely handle non-standard ERC20 tokens. Theoretically, the ERC20 standard defines how token contracts should behave, but in practice, many tokens implement various non-standard characteristics that may be incompatible with the assumptions of DeFi protocols. Besides deflationary tokens, DeFi protocols also need to deal with various other non-standard token types. Rebase tokens (such as Ampleforth) periodically adjust the balances of all holders, which can lead to a mismatch between the internal ledger of the AMM pool and the actual balance. Tokens with transaction fees (such as some governance tokens) deduct a certain percentage from each transaction, similar to deflationary tokens but with a different mechanism. Dual-address tokens (like TUSD) may have multiple contract addresses pointing to the same asset, causing the protocol to incorrectly treat them as different tokens. Some tokens' transfer or transferFrom functions do not return a boolean value or always return true (regardless of whether the operation succeeds), violating the ERC20 standard but still being widely used. Uniswap V3 explicitly states in its documentation that it does not support certain types of non-standard tokens, especially those with transfer fees. The protocol's router contract assumes that transferFrom will transfer an exact specified amount; if the actual transfer is less than expected, subsequent swap calculations will be incorrect. Similarly, while rebased tokens can be used in Uniswap V3 pools, liquidity providers may face irreparable losses because the pool does not automatically adjust to reflect balance changes. These cases highlight a fundamental security principle: do not make unverified assumptions about external dependencies. In a smart contract environment, "trust but verify" is not even enough—the protocol should "distrust and enforce verification." For token interactions, this means that the actual amount transferred should be checked after each transferFrom, rather than assuming it equals the requested amount. For balance queries, the possibility of rebase or other balance change mechanisms should be considered. For external calls, it should be assumed that they are potentially reentrant and defenses should be implemented accordingly. Balancer V3 makes significant improvements in this regard. By using OpenZeppelin's SafeERC20 library, V3 performs additional security checks on all token interactions. The protocol also introduces a token whitelist and risk rating system, allowing governance to control the supported token types. More importantly, V3's architecture natively supports yield tokens and rebase tokens through ERC4626 wrappers, which correctly handle non-standard behavior, translating it into a standard interface that the protocol can safely handle. 5.5 Precision Engineering: Underestimated Attack Vectors The prevalence of precision loss and rounding error attacks in the DeFi space is worrying because they are often not considered "real" security vulnerabilities. Developers may think that losing a few wei due to extremely small amounts is acceptable, but attackers can accumulate substantial profits through thousands or millions of tiny losses. The Balancer 2023 attack is a classic counterexample to this thinking, where attackers systematically exploited rounding errors, causing losses of over $2 million. The root of precision issues often lies in the limitations of the Solidity language itself. Solidity does not support floating-point arithmetic; all decimals must be represented as integers (by multiplying by a power of 10). When performing division, the result is truncated instead of rounded, resulting in a default round-down behavior. This may be insignificant in simple single-step calculations, but in complex multi-step algorithms (such as pricing formulas in AMMs), errors can accumulate or be amplified. A particular risk in Balancer V2 stems from its supported extreme flexibility. The protocol allows the creation of pools containing up to eight tokens, each with potentially different decimal places (from 0 to 18 or more). When calculations involve swaps of multiple tokens, the protocol requires multiple unit conversions, each a potential point of precision loss. Attackers could systematically extract value from the pool by maximizing these losses through specific token combinations and swap paths. Defending against precision attacks requires a multi-layered approach. First, the impact of precision must be considered when designing mathematical formulas, choosing algorithms that minimize intermediate computational steps. Second, a consistent rounding strategy must be implemented, ensuring that the rounding direction always benefits the protocol, not the user (or attacker). Balancer V3's "protocol-first rounding" principle embodies this approach. Third, set a minimum operation amount threshold to prevent boundary conditions from being triggered by extremely small amounts. Fourth, use higher-precision intermediate calculations (e.g., using 256-bit integers for calculations, even if the final result only requires 128 bits), and then round only in the last step. Formal verification is particularly valuable in detecting accuracy issues. Through mathematical proof, it can be verified that certain invariants of the protocol are maintained under all possible inputs, including extreme boundary cases. For example, it can be proven that the total value of the pool (measured against a certain benchmark) will not decrease after any swap sequence (except for the expected cost). If this invariant is violated, even by a very small amount, the formal verification tool will detect and report it. November 3, 2025 - Author X @OutageVictfzev Creating this was not easy, please like and share.
