Flash Loans are one of DeFi’s strangest inventions: money you can borrow without owning a cent. Brilliant developers keep inventing new ways for money to flow, lending, borrowing, swapping, and staking, all governed by code instead of banks. But just like any lab experiment, one wrong assumption in the design can cause an explosion.
Between August 27 and September 2, 2025, two major DeFi protocols, BetterBank on PulseChain and Bunni v2 on Ethereum, learned this lesson the hard way. In less than a week, attackers exploited small weaknesses in their systems to steal a combined $13.3 million.
At first glance, the two attacks look very different. BetterBank’s problem was reward logic gone wild, while Bunni’s was math errors in custom hooks. But at the root, both stories are about the same issue: protocols assumed the system would always behave “normally,” when in reality, attackers thrive on bending those assumptions.
In this article, we’ll unpack these hacks step by step. We’ll explain how the protocols were meant to work, what went wrong, and why terms like “flash loan” or “hook” matter. This is an article on how fragile DeFi’s trust in code can be.
The BetterBank Exploit
BetterBank pitched itself as a next-generation lending and borrowing platform on PulseChain. To make it unique, it introduced a dual-token system:
Esteem ($ESTEEM): A governance token — essentially the “ownership” token. Holding Esteem meant you influenced the protocol. It was also given out as a reward.
Favor ($PDAIF, $PLSF, $PLSXF): A family of tokens used directly in lending and borrowing. Think of Favor as the fuel for the BetterBank engine.
The system was designed to keep users engaged in multiple ways:
- If you bought Favor, you got a 44% bonus in Esteem.
- If you staked Esteem, you could mint more Favor.
- If you deposited tokens into lending pools, you also got Esteem as a reward.
- If you didn’t want to hold Esteem, you could “smelt” (burn) it and receive 70% of its value in Favor.
This interconnected cycle was supposed to balance itself: Favor gave Esteem, Esteem gave Favor, and lending pools kept liquidity healthy.
Where It Went Wrong
BetterBank’s problem was in its reward logic. The contract rewarded Esteem whenever Favor was bought, but it didn’t check if the purchase was real. This is like a loyalty card that gives you points every time you scan it — even if you didn’t actually buy anything at the store.
An attacker realized they could create fake pools of Favor, run meaningless swaps, and farm huge amounts of Esteem. Since Esteem could then be turned back into Favor, and Favor could be swapped for real tokens like DAI, this reward bug quickly snowballed into millions of dollars in stolen value.
What Is a Liquidity Pool?
If you’re new to DeFi, a liquidity pool is like a vending machine filled with two different tokens. Instead of a person selling you candy for coins, the machine swaps one token for another based on supply and demand.For example, a DAI–PDAIF pool has both DAI (a stablecoin) and PDAIF (a Favor token). If you add DAI, you can pull out PDAIF. If you add PDAIF, you can pull out DAI. The ratio of tokens in the pool determines the price.
Now, if someone can create a fake pool that looks like it contains real tokens but actually doesn’t, they can trick systems that rely on “pool activity” as proof of real trades. That’s exactly what the attacker did in BetterBank.
How the Attack Unfolded
To understand how the attack happened, we must first break down how flash loan works:
- Flash Loan?
A flash loan is a type of loan in decentralized finance (DeFi) that allows borrowers to borrow money without providing collateral.
In traditional finance, if you go to a bank and ask for $100,000, they’ll want security — maybe your car, your house, or some kind of asset to guarantee repayment. If you don’t pay back, they seize the collateral.
Flash loans throw this idea out the window. They say: “You can borrow millions of dollars instantly… as long as you pay it back within the same transaction.”
- How Does It Work?
Think of a blockchain transaction like a single “moment” where many actions happen at once. A flash loan takes advantage of this by enforcing three steps inside that moment:
1. **Borrow** – You request the money from a protocol.
2. **Use** – You can do whatever you want with it: trade, swap, or interact with smart contracts.
3. **Repay** – Before the transaction ends, you must return the money plus a small fee.
If step 3 doesn’t happen, the whole transaction is canceled automatically — like it never existed. This is possible because blockchains operate on an “all or nothing” rule.
- Why Is This Possible?
Because blockchains process transactions atomically. “Atomic” means everything inside the transaction succeeds together or fails together. There’s no in-between.
That’s why a protocol doesn’t worry about risk. Either:
- You repay the loan, and they keep the fee, or
You don’t repay, and the loan is canceled instantly.
-
Flash Loans Use Case?
- Arbitrage: Traders borrow large sums to take advantage of tiny price differences between exchanges, then pay back immediately.
- Refinancing debt: You can use a flash loan to move debt between platforms in one transaction.
- Exploits (unfortunately): Hackers often use flash loans to maximize the money they can manipulate in an attack.
A flash loan is like being handed a suitcase with millions of dollars, but you’re standing in a room with one rule: before you leave the room, you must put the briefcase back with a small tip. If you don’t, the suitcase vanishes, and it’s like you never touched it.
Now back from our detour.
The attacker abused BetterBank’s automated distribution system by purchasing Favor to gain Esteem at 44% of Favor’s purchasing value as rewards in addition to Favor's daily minting rate, he successfully drained 891M DAI. 9.05B PLSX, and 7.40B WPLS.
First, he created 3 malicious contracts:
-
First Contract
- EOA: 0x48c9f537f3f1a2c95c46891332E05dA0D268869B
- Tx Hash: 0x9c7237a00fa276c5f10ca1c61d6821869a7fdcd1ade8059729cdc35c9ff7689a
- Contract Address: 0x18Dd9E3F039F319c854c389fC87b5295d3cb7f94
-
Second Contract
- EOA: 0x48c9f537f3f1a2c95c46891332E05dA0D268869B
- Tx Hash: 0xc651656d2f94476374ee1de240f6bcf4572a5fe732db92d319573a1727409f82
- Contract Address: 0x767C5a70CDa0D9469ccE3a56653E1d170D9849c3
-
Third Contract
- EOA: 0x48c9f537f3f1a2c95c46891332E05dA0D268869B
- Tx Hash: 0x74534b1f86a63c6c722d5845f2b4c08867c2e66b922a6c95cd6b4290664c19bd
- Contract Address: 0x792CDc4adcF6b33880865a200319ecbc496e98f8
Second, with the first contract, the attacker borrowed 50M DAI and 7.14B PLP tokens from the flash loan he initiated on BetterBank’s DAI-PDAIF pair.
Third, using the 7.14B PLP initially borrowed, the attacker invoked removeLiquidity on PulseXRouter02 that drained the real DAI-PDAIF pool from 1B DAI and 500M PDAIF.
The attacker uses a fake token to create a new fake-PDAIF pool on PulseXFactory, minting a quintillion of this fake token while adding minimal liquidity to the fake token and draining PDAIF.
Fifth, using this fake token attacker executed several swaps in the same fake attacker created to simulate high trading volume and mint Esteem rewards multiple times.
Sixth, attacker converted all Esteem rewards to almost 3.8B PDAIF which results in inflating PDAIF token supply.
Seventh, attacker used part of PDAIF gains to add liquidity into DAI-PDAIF pool with almost 1.09B DAI and 501M PDAIF, resulting in imbalanced pool with excess PDAIF.
Eighth, attacker exploited the imbalanced created in DAI-PDAIF pool to swap the surplus PDAIF for 891M DAI, to pay the original flash loan of DAI-PLP back to BetterBank and retained around 891M DAI.
attacker managed to repeat the same scheming exploit and successfully retained around 9B PLSX and 7.4B WPLS
Why It Worked
BetterBank failed to ask one critical question: “Is this trade real, or just someone gaming the system?”
- Rewards were tied to swaps, but swaps weren’t validated.
- No supply caps were enforced to limit how much Esteem or Favor could be minted.
- The system trusted that pools would always be real and honest.
The result was inevitable: once someone figured out they could farm Esteem out of thin air, it became a money-printing machine for the attacker.
The Bunni v2 Exploit
While BetterBank tried to innovate in lending, Bunni v2 aimed to improve liquidity provision. It was built on Uniswap v4, the latest version of the most popular decentralized exchange.
Uniswap v4 introduced something new called hooks. Hooks let developers add custom logic that runs before, during, or after swaps. Bunni used this to create a Uniform Distribution curve, which automatically rebalanced pools after every trade.
In plain terms:
- Imagine a seesaw with two tokens.
- After each trade, Bunni checked if the seesaw was tilted.
- If tilted, it was rebalanced by shifting tokens so the seesaw was level again.
This was supposed to make liquidity smoother and fairer.
Hooks?
Think of a hook as a “mini-program” attached to a bigger program. In Uniswap v4, every trade can “call” a hook, which can check balances, move tokens, or even apply fees.Hooks are powerful because they allow creativity. But with power comes risk: if the math inside the hook is wrong, the entire pool can be drained.
Where It Went Wrong
Bunni’s hook made a math mistake. It didn’t correctly handle flash accounting (temporary balance changes inside a transaction) and deltas (the before-and-after differences in pool state).
This meant that if someone carefully timed a series of swaps, the hook would miscalculate how much was owed. Each swap gave the attacker a little extra — and by repeating the process, they turned “a little extra” into $8.3M.
How the Attack Unfolded
- Flash Loan Setup
The attacker borrowed $3M in USDT from Uniswap v3.
- Entering the Bunni Pool
They directed swaps into Bunni’s USDC–USDT pool, triggering the hook logic.
- Hook Miscalculation
Each swap caused Bunni’s “Uniform Distribution” to miscalculate the token balance. The system thought the attacker owed more tokens than they actually did.
- Accumulating the Error
The attacker repeated the swaps, and each time the error compounded.
- Withdrawal and Repayment
Finally, they withdrew the inflated balance, paid back the flash loan, and pocketed about $8.3M.
Why It Happened
Bunni trusted its hook math too much.
- It didn’t account for flash loans, which can distort balances within a single transaction.
- It didn’t enforce strict delta checks, meaning it couldn’t detect when balances didn’t add up.
- It lacked safety nets like reentrancy locks or sanity checks.
In other words, Bunni’s math worked in a perfect world, but DeFi is not a perfect world — it’s an adversarial one.
Lessons From Both Exploits
When we compare the two attacks, a pattern emerges:
- BetterBank: Trusted that swaps meant real trades.
- Bunni v2: Trusted that math in the hook would always balance out.
Both forgot that attackers don’t play by the rules — they play against them.
Key Takeaways
- Never trust appearances. Fake pools can look real. Fake trades can look active.
- Always account for flash loans. If your system can’t survive an instant, large-scale imbalance, it’s vulnerable.
- Cap supply and rewards. Infinite rewards are an open invitation to infinite exploits.
- Test with adversarial scenarios. Don’t just test “happy paths” — test how your system behaves when someone tries to break it.
Conclusion
In less than a week, two different protocols on two different chains lost over $13M. Both teams had ambitious visions, but ambition without airtight safety measures is dangerous in DeFi.
BetterBank’s bug was about reward logic. Bunni’s was about math inside hooks. But the underlying message is the same: in DeFi, trust must be earned, not assumed.
For builders, the lesson is clear — code must be designed not just for normal users, but for the most determined attacker in the room. Because in DeFi, that attacker will always show up.
If you enjoyed this story, consider joining our mailing list. We share real stories, guides, and curated insights on web development, cybersecurity, blockchain, and cloud computing, no spam, just content worth your time.
Top comments (0)