On August 26, 2025, BetterBank - a decentralized finance (DeFi) protocol operating on the PulseChain network - was exploited through unauthorized bonus minting and liquidity manipulation. The attack resulted in an initial loss of approximately $5 million in digital assets.

This article provides a transparent overview of the incident: what happened, what our audit flagged, where communication fell short, and the lessons we take forward.

What Happened

The exploit targeted BetterBank's reward system, specifically the mechanism for minting ESTEEM bonus tokens. The attacker was able to create a liquidity pool on PulseX, or alternatively deploy a custom contract, paired with BetterBank's registered Favor token.

Using the swapExactTokensForFavorAndTrackBonus function, the attacker executed bulk swaps to mint substantial ESTEEM bonuses, later converting them into native tokens or stablecoins.

While bulk swapping typically incurs large tax fees through BetterBank's built-in sell tax mechanism, the attacker's liquidity pool was not recognized as an official BetterBank pair. This allowed them to bypass taxes entirely and make the exploit profitable.

How the Exploit Worked

The vulnerability stemmed from a fundamental flaw in the protocol's bonus reward system - specifically in the swapExactTokensForFavorAndTrackBonus function. This function was designed to mint ESTEEM reward tokens whenever a swap resulted in FAVOR tokens, but critically, it lacked the necessary validation to ensure that the swap occurred within a legitimate, whitelisted liquidity pool.

Step-by-Step Attack Flow

1. Capital acquisition: The attacker obtained substantial assets through flash loans and drained the legitimate DAI-PDAIF liquidity pool.
2. Fake infrastructure: A worthless ERC-20 token was deployed and paired with PDAIF on PulseX, creating a fraudulent liquidity pool under the attacker's control.
3. Reward exploitation: Rapid swaps between the fake token and PDAIF triggered the vulnerable bonus system repeatedly. Each swap minted approximately 44% in ESTEEM bonuses - without incurring any taxes.
4. Value extraction: Newly minted ESTEEM was converted to FAVOR, enabling further swaps in an escalating loop that systematically drained protocol reserves.

Why It Succeeded

The exploit succeeded because of three compounding design flaws:

• Unvalidated bonus minting: The logBuy function required only that the caller be an approved wrapper. It never validated the trading pair's legitimacy or the source of the swap itself.
• Tax bypass mechanism: The _transfer function only assessed sell taxes for addresses marked as isMarketPair. Unauthorized pools were not recognized as market pairs, meaning the attacker's fake pool bypassed the 50% maximum sell tax entirely.
• Convertible rewards loop: ESTEEM tokens could be converted back to FAVOR, enabling a recursive value generation cycle. Infinite bonus generation minus zero taxes equals protocol death spiral.

What Our Audit Flagged

During our July 2025 audit, Zokyo explicitly identified this class of exploit and reported it to BetterBank. Two findings directly related to the exploit:

• Flashloan / High-Volume Exploits: Malicious actors could exploit the Favor bonus system by cycling large trades through the protocol's reward mechanism.
• Bogus Tokens via UniswapWrapper: Malicious actors could deploy their own contract and liquidity pool, then use bogus tokens to qualify for bonuses. This finding was titled "A Malicious User Can Trade Bogus Tokens To Qualify For Bonus Favor Through The UniswapWrapper."

Both findings outlined the core attack vector that was ultimately used in the August exploit.

Where Communication Fell Short

While the vulnerability was correctly identified and reported, there was a lapse in communication on our part.

Our proof of concept (PoC) used test Ether - a legitimate token - to demonstrate how the logic would behave with tokens like PLS, PLSX, or PDAI. However, the issue could also be reproduced with any bogus token, and this was not explicitly stated in the PoC.

Based on the documented PoC, which used test Ether, the severity of the vulnerability was downgraded to "Informational" and marked as "Resolved" in the report. The BetterBank team did not fully implement the patched code snippet that was provided.

The severity downgrade reflected client feedback, but we recognize that our explanation could have been more precise and left less room for misinterpretation. The finding itself was correct, but the way it was communicated contributed to the misunderstanding.

Technical Details

Vulnerable Functions

The logBuy function required only that the caller be an approved wrapper - it never validated the trading pair's legitimacy. The vulnerable logic lacked checks for:

• Valid liquidity pair sources
• Minimum liquidity requirements
• Verified trading partners
• Transaction amount limits

The _transfer function only assessed taxes for addresses marked as isMarketPair, meaning unauthorized pools bypassed the 50% maximum sell tax.

Attacker Infrastructure

On-chain analysis revealed sophisticated attack infrastructure. The primary attacker address (0x48c9...869B) deployed coordinated contracts through a factory contract that contained 18,219 bytes of embedded bytecode with three critical functions:

• An initialization handler
• A cleanup function
• A flash loan callback (executeOperation)

The callback function matched standard DeFi protocols like Aave and dYdX, enabling sophisticated parameter parsing and dynamic contract deployment. Initial funding came through Tornado Cash, suggesting premeditation rather than opportunistic discovery.

Fund Tracing

The attacker swapped stolen assets for liquid tokens, bridged approximately $922,000 in ETH to Ethereum mainnet via secondary addresses, then utilized mixers to obscure fund origins. Following on-chain negotiations, the attacker voluntarily returned approximately 550 million pDAI to the protocol.

Key Takeaways

This incident highlights a critical reality of blockchain security - one that extends beyond any single audit or protocol:

• Auditors must communicate thoroughly: Identifying a vulnerability is not enough. Findings must be communicated as explicitly as possible, leaving no room for ambiguity about the potential impact or the range of attack vectors.
• Clients must prioritize fixes: Projects must prioritize and implement fixes for identified risks, even when they appear theoretical. A finding downgraded to "Informational" can still represent a critical attack vector.
• Severity is context-dependent: A PoC using test Ether may appear low-risk. The same logic exploited with worthless tokens becomes catastrophic. Severity assessments must account for the full range of possible inputs.
• Security is a shared responsibility: Neither the auditor nor the client can ensure security alone. Effective security requires alignment between the teams identifying risks and those implementing fixes.

Our Response

The Zokyo team regrets that the incident occurred and recognizes its impact on the BetterBank community. While the vulnerability was identified on our part, we recognize that a more thorough explanation could have prevented the exploit.

We remain committed to full transparency - even when it is uncomfortable - and to continuous improvement in how we communicate risks. This incident has led to internal changes in how we document and present proof-of-concept demonstrations, with a focus on enumerating all possible attack paths rather than demonstrating only the most representative one.

Recommendations for Protocols

Based on this incident, we recommend the following protective measures for DeFi protocols with similar reward mechanics:

• LP validation: Implement checks for valid LP pairs, minimum liquidity requirements, verified trading partners, and transaction amount limits within any bonus or reward function.
• Universal tax application: Extend sell taxes to all transfers rather than just whitelisted market pairs. This ensures unverified pools cannot bypass fee mechanisms.
• Rate limiting: Impose daily bonus caps and hourly claim restrictions to prevent rapid exploitation even if other safeguards fail.
• Audit implementation: Treat every audit finding as actionable. Implement or explicitly document the reasoning for deferral - and have the auditor confirm they agree with the assessment.

Conclusion

DeFi security failures more often stem from design-level architectural oversights than from simple coding errors. The combination of unvalidated reward mechanisms, tax exemptions for unvetted entities, and cyclical token conversion systems created an exploitable surface that a single finding could not adequately convey when organizational prioritization failed to follow through on recommendations.

The partial fund recovery represents an unusual positive outcome in DeFi exploits, reflecting successful on-chain negotiation rather than technical remediation. But it does not diminish the seriousness of the incident or the lessons it carries.

Comprehensive security requires multilayered validation, immediate audit implementation, and accountability from both the teams that identify threats and the teams that build on top of them.