On August 26, BetterBank was exploited in an attack that allowed the unauthorized minting of Favor tokens.

The exploit was made possible by the ability to create a liquidity pool on PulseX, or alternatively deploy a custom contract paired with BetterBank’s registered Favor token.

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

While bulk swapping typically incurs large tax fees, 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.

Audit Findings

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

1. Flashloan / High-Volume Exploits – malicious actors could exploit the Favor bonus system by cycling large trades. (PoC here)
   
   

2. Bogus Tokens via UniswapWrapper – malicious actors could deploy their own contract and liquidity pool, then use bogus tokens to qualify for bonuses. (PoC here)

The second finding was formally documented in our report as “A Malicious User Can Trade Bogus Tokens To Qualify For Bonus Favor Through The UniswapWrapper” (Informational-6, marked Resolved).

Our recommended mitigation was to enforce a direct swap path (path.length == 2) and restrict bonuses only to whitelisted Favor tokens. The patched code snippet we provided implemented exactly this safeguard. Unfortunately, the deployed contract did not fully apply these controls, leaving the system vulnerable to bogus-pair bonus qualification.

Where We Could Have Been More Thorough

While the exploit vector was correctly identified and reported, we acknowledge there was a lapse in communication from our part.

• Our PoC used test ETH (a legitimate token), which represented how the logic would behave with tokens like PLS, PLSX, or PDAI.
  
  

• However, the issue could also be reproduced with any bogus token, and we did not explicitly state that in the PoC.
  
  

• 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.

Lessons Learned

This incident highlights a critical reality of blockchain security:

• Auditors must not only identify risks but also ensure findings are communicated as thoroughly and explicitly as possible.
  
  

• Clients must prioritize and implement fixes for identified risks, even when they appear theoretical.

Security is a shared responsibility. Auditors can flag issues and provide recommended fixes, but ultimately, it is the project’s responsibility to apply and verify those fixes prior to deployment.

Mitigation and Supporting BetterBank

We are actively supporting BetterBank as they recover from this incident. Encouragingly, the team has already been able to recover the protocol from bad debt. To protect affected users, Zokyo recommended that BetterBank consider a debt pool mechanism similar to the one adopted by Conic Finance:

1. Create a debt pool
   
   

2. Issue debt tokens equal to the lost value
   
   

3. Use protocol fees to gradually repay the pool, allowing users to redeem or trade debt tokens

Closing Remarks

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 continuous improvement in how we communicate risks. We stand with BetterBank and its community as they recover and move forward.