Bunni DEX Hack: Lessons Learned
In September 2025, Bunni DEX was the victim of an $8.4 million exploit. This incident featured a complicated flash-loan attack that exploited a subtle rounding issue in Bunni’s internal calculations that was used to steal from Ethereum and Unichain liquidity pools. This attack was so ruinous that Bunni was forced to shut down, showing how disastrous a seemingly minor bug can be. It also represents a growing body of unique web3 attacks that go beyond the realm of traditional hacks and unauthorized access, instead maliciously manipulating the math and economics that underpin modern DEXs.
This article goes in-depth into Bunni’s operations and the subtle assumptions that resulted in this multimillion-dollar attack. There are plenty of articles covering the broad strokes of this attack and very few covering the exact mechanics. This article will attempt to precisely explain the attack chain in an intuitive and accessible manner, and further explain the legal implications behind the hack. Reach out to Dynamis LLP to discuss further.
Uniswap Models and Bunni DEX Innovations
Bunni was built on Uniswap v3 and inherited many features of Uniswap while also adding new innovations to the DEX ecosystem. More specifically, Bunni improved Uniswap concepts like price ticks and active vs. idle liquidity to more efficiently allocate liquidity and provide better returns for liquidity providers (LP).
In a DEX, a pool is a collection of two tokens that is used for trades between those tokens. Pools are run autonomously via smart contracts that control the math and economics necessary to maintain functional and well-priced trading between tokens. Uniswap v2 DEXs accept liquidity contributions from traders and then calculate exchange rates based on a price curve. All contributed liquidity was available for trades across the entire price curve, but most contributions sat unused (and therefore not earning fees) since trades are concentrated at market prices. In Uniswap v3, active and idle liquidity was introduced. LPs could decide a range of prices in which they wanted their contributions to be traded and collecting fees, but if the ratios of tokens in the pool caused the price to move out of that price range, their tokens would become idle and no longer used for trades. The protocol would generate various price ranges (called “ticks”) that quantized prices and then let LPs decide which ticks their contributions would trade in.
Bunni built on this model with two main features. The first was the use of liquidity density functions (LDF). LDFs took price ticks as an input and then output a value in [0,1] representing the percentage of that token’s total liquidity that should be active. So, if a pool with token 0 and token 1 has token 0 trading at a rate of 1.3 token 1, the LDF would take the tick encompassing 1.3 and output, say, 0.35, meaning 35% of 0’s total reserves will be active. These LDFs tend to be some variation on a geometric distribution so that, generally, the more expensive a token gets, the smaller the active liquidity becomes. This improved Uniswap’s price tick model by automating active and idle distributions as opposed to letting LPs decide when their tokens would be used.
Bunni’s second innovation was in the way it used idle reserves. Idle tokens in other DEXs usually just sit unused. Bunni, however, would loan some idle tokens to other DEXs, staking protocols, or other financial structures that could generate returns. This meant liquidity could earn fees even when it wasn’t being actively traded in the pool, generating much higher returns for LPs.
Legal Implications of Bunni Attack
The Bunni exploit is not just a technical failure. It raises concrete legal questions for founders, DAOs, investors, and liquidity providers.
An attacker used a flash loan and a rounding bug in Bunni’s smart contracts to drain about $8.4 million in value from Ethereum and Unichain pools and ultimately forced the protocol to shut down. When code is the business, a bug like this is the business problem and the legal problem. Some of the key issues that incidents like Bunni’s put on the table:
1. Who bears responsibility for smart contract bugs
When an exploit arises from a math or rounding error in protocol code, courts will ask who, if anyone, is responsible for the loss.
Core developers and the company or foundation that shipped the contracts may face negligence or misrepresentation theories if investors or LPs argue that the protocol was marketed as safe or “audited” when it was not.
Auditors can be targets if their reports were used to attract capital and glossed over or failed to detect obvious risks in the design.
DAO tokenholders and multisig signers can be pulled in if they effectively ran the protocol, approved upgrades, or directed treasury decisions around security.
Even where contracts disclaim liability, courts often scrutinize those clauses when there is asymmetric information, retail participation, or allegations of gross negligence.
2. Duties to LPs and users
Bunni’s model depended on third-party capital being parked in its pools, including idle balances that were lent out to other protocols for extra yield. That structure raises questions about:
What risks had to be disclosed to LPs about smart contract bugs, flash loan attacks, and the way idle liquidity was reused.
Whether interfaces, docs, and marketing created an impression of “safe” yield that conflicts with the reality of experimental code and complex economic design.
What standard of care applies when a protocol takes discretionary steps with user liquidity, for example lending idle tokens into other DeFi strategies.
These issues matter both for private litigation and for regulators looking at whether investors were misled.
3. Regulatory and enforcement exposure
An exploit like Bunni’s does not happen in a vacuum. It lands in the middle of active enforcement by agencies like the SEC, CFTC, and FinCEN.
Incidents like this can raise:
Securities and commodities questions if governance tokens, LP tokens, or structured products around the DEX are characterized as securities or derivatives.
Disclosure and fraud theories if the protocol was raising money or selling tokens while downplaying material smart contract or economic risks.
AML and sanctions issues if exploited or laundered funds flow through U.S. touchpoints or centralized venues.
Even if the attacker is unknown, protocol teams often find themselves answering subpoenas and inquiries about what they knew, when they knew it, and how they responded.
4. Governance, incident response, and recovery
Once an exploit hits, there is a second wave of legal risk around how the team and DAO respond.
Key questions include:
Who had authority to pause contracts, update code, or negotiate with the attacker.
What communications went out to LPs, users, investors, and the public, and whether they were accurate and timely.
How the project handled forensic work, potential clawbacks, and decisions around shutting down vs rebuilding.
Good incident response planning is not just a technical runbook. It is also a legal and governance plan that can be defended later.
You can then flow directly into your existing “Uniswap Models and Bunni DEX Innovations” section and the step-by-step analysis of the attack.
Attack Overview
With this background on DEXs and Bunni out of the way, we are ready to begin analyzing the attack. At a high level, this attack exploited a rounding function used in Bunni’s calculation of idle balances, effectively tricking the target pool into gravely underestimating its liquidity. After artificially deflating the liquidity, the attacker could easily distort prices to buy tokens at an egregiously low price. The attack can be roughly split into three stages:
Stage 1: Flash loan borrow token 1 and then trade token 1 for token 0 so there is almost no token 0 left in the pool. These tiny levels of token 0 position the attacker to exploit rounding errors in the next step.
Stage 2: Make many small consecutive withdrawals of token 0 in such a way that a single rounding function causes the pool to vastly underestimate its true liquidity.
Stage 3: Now that the pool “thinks” liquidity is low, prices are very sensitive to swaps. Trade token 1 for token 0 to effectively use all the reserves of 0. This causes the pool to now think its liquidity is relatively normal but the price of 0 is still very high. Trade token 0 for token 1 at this artificially high price. Pay back the token 1 flash loan and pocket the difference.
Let’s break down each of these steps to really understand the precise mechanisms driving this attack.
Stage 1
The attacker began by using a flash-loan to borrow large amounts of token 1. They then swapped 1 for 0 until the amount of active 0 was pushed into the territory of low double-digit wei and the price tick for 0 was pushed to abnormally high levels.
In the exploit on Bunni’s USDC/USDT pool, for example, the price tick of the pool was pushed to 5000, which corresponds to 1 USDC = 1.68 USDT. More importantly, the pool’s active USDC balance decreased to just 28 wei.
Stage 2
This is the core of the attack. At this stage, the attacker made many tiny liquidity withdrawals of token 0 that caused rounding discrepancies to convince the pool that its liquidity was much lower than it actually was. To understand how this happened, let’s look at the problematic function itself. When LP shares are removed from a pool, the pool’s smart contract decreases both active and idle balances in an amount proportional to what was removed. The below Solidity function shows how Bunni calculates a new idle balance after LP shares are burnt. Note that mulDiv (Solidity) and the square brackets (math) are functions that round down.
As we can see, the amount deducted from the new idle balance is rounded down. This has the ultimate effect of overestimating the idle balance and underestimating the active balance. This is normally a safe assumption — assuming you have too little to actively swap is more conservative than assuming you have too much. The lower liquidity that comes out of this assumption also means there is more price impact during swaps, which also works in favor of the pool.
However, with token 0 at such low wei, this assumption worked in favor of the attacker. Conducting a series of tiny withdrawals meant that the resulting difference in actual balance vs. recorded balance was proportionally large. To see how this affected the pool’s liquidity calculation, let’s once again look at the code (and a math translation) to see how exactly Bunni calculates liquidity:
Let’s break this down: for token 0 and token 1, liquidity is calculated by balance times Q96 (a scaling factor) divided by the density of that token. If balance or density are 0, then liquidity is set to 0. This is calculated for both tokens. Again, under the assumption that underestimating liquidity is safer, Bunni chooses the lowest liquidity to represent the pool’s overall liquidity. In the attack, since balance was artificially deflated and density stayed the same, L0 was lower than L1. Thus, Bunni chose an artificially low liquidity even though the true balances of the pool would have necessitated a higher one. To give a sense of scale, in the attack on Bunni’s USDT/USDC pool, the liquidity erroneously decreased by 84%.
Stage 3
To recap where things stand after stage 2: liquidity was artificially low; token 0 balances were extremely low; the pool’s internal accounting recorded token 0 balances as even lower than they were; 0 was artificially expensive; token 1 levels were normal and recorded normally. With these conditions, the attacker was now postured to profit.
This stage was executed in two transactions. The attacker first swapped a large amount of token 1 for token 0. Because there was so little token 0 left in the pool, this effectively removed all token 0 from the pool. Artificially low liquidity and token 0 balances mean that this swap caused token 0 to become absurdly expensive. Recalling the per-token liquidity calculation, we see that liquidity is inversely proportional to density, so the huge uptick in price caused density to plummet, ultimately causing the token 0 liquidity estimate to explode. Remember that Bunni pools estimate liquidity based on the lowest estimate between both tokens. Once L0 was much larger than L1, the pool used L1 to estimate the pool’s liquidity.
This left the attacker with a large amount of token 0 in their possession and access to a pool with normal recorded liquidity where token 0 was incredibly overpriced. Trading their token 0 reserves for token 1 let the attacker sell token 0 at this artificially high price and profit. After repaying their initial token 1 flash loan, the attacker absconded with an unfairly acquired profit.
Conclusion
The Bunni exploit shows how a “small” rounding decision in smart contract math can wipe out an entire protocol and leave investors and LPs holding the bag. In a single incident, you see almost every live issue in crypto litigation and enforcement today: responsibility for protocol design, duties to users, the legal status of DAO governance, and the reach of U.S. regulators over global DeFi activity.
For founders and protocol teams, the lesson is simple. Security audits and formal verification are necessary, but they are not the whole story. You also need to think through how your code, docs, governance, and incident response will look to a regulator, a judge, or a jury after something goes wrong.
For LPs, investors, and other market participants, these exploits are a reminder to diligence not just the code but the people, entities, and jurisdictions behind a project. The legal structure matters as much as the yield.
Dynamis LLP works with both builders and investors in this space. We help teams design and document protocols with litigation and enforcement risk in mind, and we represent victims and defendants when things go sideways, including:
Internal investigations and technical forensics with outside experts
Regulatory response and engagement with U.S. agencies
Civil litigation around token losses, LP capital, and governance disputes
If you are dealing with the fallout from an exploit or want to get ahead of these risks before the next one, you should talk with experienced counsel early, not after value disappears. Reach out to Dynamis today.
Sources
https://blog.bunni.xyz/posts/exploit-post-mortem/
https://gist.github.com/giovannidisiena/716324d50b6649be3a0e91395890917e
https://docs.bunni.xyz/docs/v2/overview
https://finance.yahoo.com/news/bunni-dex-shuts-down-8-080126416.html
