Shared Library and Rounding Bugs Drain Hundreds of Millions. 

Hackers Don’t Care About Out of Scope 

In May and November of 2025, two of the year’s most expensive DeFi exploits had an uncomfortable amount in common. Neither one came down to a novel zero-day buried in core business logic. Both traced back to subtle arithmetic flaws, one in a third-party math library and the other in rounding behavior that had been sitting in production code for years, and in both cases auditors had either missed the issue or underestimated how bad it could get. Cetus Protocol lost roughly $223 million. Balancer V2’s Composable Stable Pools lost more than $100 million across multiple chains, with initial estimates as high as $128 million before recoveries brought the number down.

Over on r/defi, and in cross-posts to r/blockchain and other technical subs, the reaction followed a familiar script: disbelief that “audited” or battle-tested code could still bleed nine figures, followed by the same question everyone kept coming back to. How do you actually stop this class of bug from happening again?

Cetus: An Overflow Check That Checked the Wrong Thing

On May 22, 2025, attackers drained Cetus, at the time the leading concentrated-liquidity DEX on Sui, in under 15 minutes. The root cause lived in an open-source math library (usually referred to as integer-mate or inter_mate) that Cetus relied on for liquidity and pricing calculations. One helper function, checked_shlw, was meant to guard against overflow during a left-shift scaling step on u256 values. Instead, it validated inputs against the wrong bound, effectively checking for a 256-bit limit when the actual operation needed a 192-bit threshold.

The attackers strung together a flash swap to suppress prices, a batch of worthless spoof tokens, and a narrow tick range. That faulty check let a tiny deposit, in some cases a single token, get credited with an absurdly large liquidity position. From there, legitimate assets like SUI and USDC were pulled out far beyond what had actually gone in. Roughly $60 to $61 million was bridged out before anyone could react, and Sui validators eventually froze about $162 million on-chain. More than 200 liquidity positions were touched.

What made this one sting is that the library wasn’t unique to Cetus. It was shared. That single fact drove a lot of the discussion afterward, because it meant a bug in one dependency could turn into a systemic risk for everyone using it.

Balancer: A Rounding Direction That Quietly Favored Attackers

On November 3, 2025, Balancer V2’s Composable Stable Pools got hit by a coordinated exploit that spanned several chains at once. This time the issue was a rounding-direction inconsistency in the exact-out swap path. The _upscale operation (or its equivalent) consistently rounded the requested output amount down before feeding it into the invariant calculation. Under normal, high-liquidity conditions, losing a single wei here and there doesn’t matter. But when balances were pushed down into the range of 8 to 9 wei, and combined with rate providers and repeated batch swaps, that tiny precision loss compounded into something big enough to distort the invariant D, suppress BPT prices, and let value get pulled out.

The bug itself wasn’t new. It had been sitting in the V2 codebase for years. Trail of Bits and others later pointed out that similar rounding concerns had come up in earlier reviews, but the exact combination of conditions that made it exploitable had never been fully closed off. Losses initially topped $100 million, with figures around $128 million cited before freezes, white-hat recoveries, and other interventions brought the net impact down. Because several chains and forks shared the same pool logic, the damage wasn’t contained to one place.

What People Were Actually Saying on Reddit

The threads on r/defi, and the cross-posts that showed up on r/blockchain and nearby technical subs, followed a pretty consistent pattern after both incidents. A lot of frustration that “audited” protocols could still fail on basic arithmetic. Plenty of people were pointing out how easy it is to treat shared libraries and fixed-point scaling as black boxes during a review. Others focused on what happens after launch: a new token, a new rate provider, a low-liquidity state, or a dependency update can turn a precision loss that looked dormant into an active exploit path. The question that kept coming up wasn’t complicated. How do you keep re-checking math libraries and rounding assumptions after every meaningful change, instead of treating security like something you check off once before launch?

None of these conversations landed on one clear tool or fix. But there was broad agreement on one thing: a single, point-in-time human audit isn’t enough to catch this category of risk on its own.

Why Traditional Audits Struggle With This

Manual audits are good at business logic review, access control analysis, and high-level threat modeling. They’re a lot less reliable at exhaustively enumerating every edge case in a shared math library, or proving that rounding always favors the protocol across every possible combination of balances, scaling factors, and swap paths. Time and budget push auditors toward the protocol’s own code first, and dependencies often get lighter scrutiny or get marked out of scope entirely. Even when a rounding issue does get flagged, proving it stays unexploitable across every realistic state is genuinely hard to do without ongoing, automated support.

And an audit is just a snapshot in time. Code changes, libraries get upgraded, new rate providers show up, liquidity conditions shift, and any of that can quietly invalidate conclusions the audit team reached months earlier. Both 2025 incidents fit this pattern: the dangerous code was either a third-party primitive or a long-standing rounding assumption whose real risk only showed up under specific live conditions nobody had tested for.

Why Continuous Detection Matters

Continuous automated analysis is built to close that gap. Tools that hook into a repository can re-scan on every meaningful commit or pull request, run semantic and interprocedural checks on math utilities, trace how values move through scaling operations, and keep a version-linked record of what was actually checked and when. Machine-learning-assisted filtering helps cut down false positives, and broader coverage of real-world arithmetic patterns means the output is something a team can actually use day to day instead of noise they learn to ignore.

The point isn’t to replace human auditors. It’s to stop the value of that earlier audit work from eroding as the system keeps changing, to catch dependency-level and rounding issues sooner, and to give teams a living record of what’s been checked instead of a PDF that goes stale the day it’s published. Security becomes something the codebase keeps doing, not a milestone you hit once and move past.

What Builders Should Actually Do

Treat math libraries and fixed-point utilities like first-class risk, not plumbing. Write down what rounding direction you expect, and back it up with tests that specifically cover low-balance and boundary cases. Wire automated scanning into CI so dependency updates and scaling changes trigger a fresh look. Favor libraries with clearly documented overflow and rounding behavior, and re-check them whenever the upstream code changes. Keep a record of what was checked against which version of the code, both for your own team and for anyone asking questions later. And go in assuming that live conditions, whether that’s liquidity levels, new assets, or new rate providers, will eventually hit edge cases that looked purely theoretical on paper.

The Bottom Line

Cetus and Balancer were expensive reminders that arithmetic primitives and shared libraries are still high-value targets. The communities on r/defi and r/blockchain more or less got it right: a point-in-time audit is necessary, but it stops being sufficient the moment code goes live and starts composing with everything else in DeFi. Continuous, automated detection that scans on every relevant change, focuses on the specific classes of overflow, rounding, and dependency issues that caused these losses, and keeps a verifiable record of what’s been covered, is the practical next step. Security that stops at launch is security that ages badly, and 2025 made a pretty strong case that the industry can’t keep affording that approach.