Detecting Precision Rounding Errors in Smart Contracts: An Advanced Technical Walkthrough

The $128 million Balancer V2 exploit on November 5, 2025, was caused by a class of vulnerability that is both extremely subtle and devastatingly effective: a precision rounding error in token decimal scaling operations. For smart contract developers and security auditors, this incident serves as a detailed case study in how mathematical edge cases can create exploitable flaws even in well-audited code. This walkthrough provides a technical deep dive into detecting and preventing similar vulnerabilities.

The Objective

This tutorial will walk you through the specific type of rounding vulnerability exploited in the Balancer V2 attack — asymmetric rounding in upscaling and downscaling operations — and demonstrate techniques for detecting such flaws during code review and formal verification. By the end, you should be able to identify similar patterns in any smart contract that handles multi-decimal token arithmetic.

The Balancer exploit worked because the protocol’s Vault Swap function applied different rounding directions during token amount scaling. When upscaling token amounts to 18-decimal precision, the code consistently rounded down. When downscaling back to the token’s native precision, rounding direction depended on the specific values involved. Over repeated EXACT_OUT batch swaps, this asymmetry created extractable value that the attacker accumulated into a multi-million dollar theft.

Prerequisites

This walkthrough assumes familiarity with Solidity, the EVM execution model, and basic DeFi concepts like automated market makers and liquidity pools. You should understand how fixed-point arithmetic works in Solidity — specifically, that Solidity does not support floating-point numbers, so all decimal calculations are done using integer arithmetic with implicit scaling factors.

You will also need a basic understanding of ERC-20 token decimals. Most tokens use 18 decimals (matching wei in Ethereum), but stablecoins like USDC and USDT use only 6 decimals, and some tokens use other precision levels. Any protocol that handles multiple tokens with different decimal precisions must perform scaling operations, and each scaling step is a potential source of rounding errors.

Tools that will be helpful: Foundry or Hardhat for testing, Slither for static analysis, and Certora or Halmos for formal verification. All are open source and well-documented.

Step-by-Step Walkthrough

Step 1: Identify all scaling operations. Begin your audit by searching the codebase for all instances where token amounts are multiplied or divided by powers of 10. In Solidity, this typically appears as multiplication or division by 10 raised to the power of the difference between two tokens’ decimal values. For example, converting a 6-decimal USDC amount to 18-decimal precision requires multiplying by 10^12.

Step 2: Analyze rounding direction for each operation. In Solidity, integer division always rounds toward zero (which for positive numbers means rounding down). Multiplication does not introduce rounding. The key insight is that any division operation inherently discards the remainder, and the direction of that rounding must be consistent with the protocol’s invariants.

In Balancer’s case, the upscaling path (multiplication) did not lose precision because it was always multiplying by a power of 10. But the downscaling path (division) did lose precision, and the lost fractional amount varied depending on the input values. This meant that the round-trip — upscale, compute, downscale — was not guaranteed to return the same value, even in the absence of any actual trading.

Step 3: Check for asymmetric rounding paths. The critical question is: are there code paths where rounding direction depends on the specific values involved? If so, an attacker who can control those values can choose inputs that maximize the rounding discrepancy. In batch swap operations like EXACT_OUT, the attacker could structure trades to consistently benefit from the rounding asymmetry.

Create a test matrix that exercises all scaling paths with boundary values: the smallest possible amounts, the largest possible amounts, amounts that exactly divide by the scaling factor, and amounts that leave maximum remainder. For each test case, verify that the rounding direction is consistent and that no value is created or destroyed by the scaling round-trip.

Step 4: Verify invariant preservation across swap operations. DeFi pool protocols maintain invariants — mathematical relationships between pool balances that must hold true before and after every operation. For Balancer’s weighted pools, the value function invariant must be preserved across swaps. The rounding error effectively allowed the attacker to violate this invariant by tiny amounts on each swap, accumulating violations across many operations.

Use formal verification tools to prove that your invariants hold under all possible input combinations. Certora’s Prover can express these invariants as specifications and automatically search for violations. Halmos can symbolically execute the code with symbolic inputs to find edge cases that violate invariants.

Step 5: Implement defensive rounding. The defensive approach is to ensure that all rounding in a protocol consistently favors the protocol (or the pool) and disfavors the user. This means that rounding errors should always reduce the user’s output or increase their input — never the reverse. If every individual operation is conservative, the cumulative effect of many operations cannot extract value from the protocol.

In practice, this means auditing every division operation in scaling code and verifying that the rounding direction is explicitly controlled. Do not rely on Solidity’s default rounding-toward-zero behavior if it might favor the user in some cases. Use explicit rounding functions that make the intent clear: roundDown() and roundUp() helpers that any reviewer can immediately understand.

Troubleshooting

If your analysis reveals asymmetric rounding that you believe is safe because the discrepancy is too small to exploit, reconsider. The Balancer exploit worked precisely because each individual rounding discrepancy was negligible — but the attacker could amplify it through repeated operations within a single transaction. Batch operations and callback patterns are particularly dangerous because they allow many operations to be composed atomically.

If your protocol uses external libraries for decimal handling, audit those libraries with the same rigor as your own code. The OpenZeppelin Math library and similar utilities provide safe arithmetic functions, but the way you use them still determines whether rounding is consistent. A safe function used in an unsafe context is still unsafe.

If formal verification tools report that your invariant holds for all tested values but you cannot construct a formal proof, treat this as a finding, not a pass. The absence of a counterexample is not the same as a proof of correctness. Consider whether there are input combinations your test suite does not cover — especially edge cases involving maximum uint256 values and interactions between multiple scaling steps.

Mastering the Skill

Detecting precision rounding errors is a specialized skill that improves with practice. Study past exploits — not just Balancer, but also the Cream Finance flash loan attack, the Yearn yUSD vault exploit, and other incidents where mathematical edge cases were exploited. Each case study builds your pattern recognition for spotting similar flaws in new code.

Contribute to open-source audit reports. Many security firms publish detailed findings from their audits, including mathematical vulnerability classes. Reading these reports and trying to find the bugs before reading the findings is excellent practice. The more patterns you internalize, the faster you will spot them in new codebases.

Finally, stay current with the evolving tooling. The formal verification ecosystem for smart contracts is advancing rapidly, and new tools are constantly emerging that can catch classes of bugs that were previously detectable only through manual review. The Balancer exploit — a mathematical flaw in audited code that persisted for four years — is exactly the type of vulnerability that better formal methods could have caught.

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