Executive Summary

On August 27th, 2025, BetterBank, a lending protocol on PulseChain, suffered a $5 million exploit due to insufficient validation of liquidity pairs in its reward distribution mechanism. The attack exploited a critical vulnerability in how the protocol handled reward minting, allowing attackers to create unauthorized liquidity pools and drain protocol funds through manipulated bonus rewards.

Timeline of Events

• July 2025: Security audit conducted, vulnerability identified but misclassified as low severity
• August 26–27, 2025: Attacker exploits the vulnerability, draining $5M from the protocol
• Post-exploit: BetterBank freezes trading and successfully negotiates return of 550M pDAI
• Post-incident: Olympix analysis confirms the vulnerability as High severity

Technical Details of the Exploit

The Vulnerability

The core issue resided in two functions within FavorRouterWrapper.sol:

• swapETHForFavorAndTrackBonus()
• swapExactTokensForFavorAndTrackBonus()

These functions were designed to reward users with ESTEEM tokens when purchasing FAVOR tokens. However, the validation logic only verified that the swap path began or ended with a FAVOR token address — it did not validate which liquidity pair contract was being used.

Attack Methodology

1. Pool Creation: The attacker created unauthorized liquidity pools on PulseX, pairing FAVOR tokens with worthless tokens under their control
2. Bulk Swapping: Using the vulnerable swap functions, the attacker executed repeated bulk trades of their worthless tokens for FAVOR
3. Bonus Minting: Each swap triggered IFavorToken.logBuy(), minting substantial ESTEEM token bonuses
4. Tax Evasion: Because the attacker’s pool was not recognized as an “official” BetterBank pair, they bypassed the tax fees that would normally make such attacks unprofitable
5. Value Extraction: The attacker converted accumulated bonuses into native tokens and stablecoins, ultimately extracting $5M

What Went Wrong: The Pre-Deployment Audit

Initial Audit Findings

A security audit conducted in July 2025 identified vulnerabilities related to:

1. Flashloan/High-Volume Exploits — potential for cycling large trades to exploit the bonus system
2. Bogus Tokens via Swap Wrapper — ability to deploy custom contracts and use unauthorized tokens to qualify for bonuses

The Critical Misclassification

Despite identifying the vulnerability, the finding was classified as “Informational” severity rather than Critical or High. This misclassification occurred because:

• The proof-of-concept demonstration used test ETH (a legitimate token) rather than worthless tokens
• This made the attack appear financially non-viable to the development team
• The severity was downgraded, signaling that the issue was not urgent
• Recommended patch code was provided but not fully implemented before deployment

The Communication Gap

The audit identified the technical vulnerability but failed to explicitly demonstrate that any attacker-controlled worthless token could be used to exploit the system. This subtle but critical detail was lost in translation, leading the BetterBank team to believe the attack was theoretical rather than practical.

How Olympix Would Have Flagged This Vulnerability

Olympix’s Analysis Framework

Olympix conducted a thorough analysis of the vulnerability and identified it with the correct severity classification:

[High] Unvalidated Liquidity Pair Leads to Reward Manipulation

Location: FavorRouterWrapper.sol:416–465
Affected Functions:

• swapETHForFavorAndTrackBonus
• swapExactTokensForFavorAndTrackBonus

Why Olympix’s Approach Would Have Prevented This

1. Accurate Severity Classification

Olympix classified this as High severity, which would make it a deployment blocker. Unlike an “Informational” classification that allows teams to proceed at their discretion, a High-severity finding demands immediate remediation before launch.

2. Clear, Unambiguous Vulnerability Description

Olympix’s finding explicitly states:

“The validation only checks that the swap path begins or ends with a FAVOR token address. It does not enforce that the swap must occur through a specific, authorized Uniswap V2 pair contract.”

This leaves no room for misinterpretation. The vulnerability is crystal clear: the contract doesn’t validate which pair is being used.

3. Direct Impact Analysis

Olympix clearly outlined the attack path:

“An attacker can create a new, unauthorized liquidity pool for a FAVOR token, execute a swap through it using the wrapper, and illegitimately trigger the IFavorToken.logBuy() function. This allows the attacker to mint bonus tokens or claim rewards without contributing to the token’s legitimate market liquidity, enabling them to drain the protocol’s reward reserves.”

This description maps exactly to what occurred in the actual exploit. There’s no ambiguity about token types or economic feasibility — just a straightforward explanation of how unauthorized pools could be used maliciously.

4. Focus on the Architectural Flaw

While the initial audit got caught up in whether the attack was economically viable with different token types, Olympix’s analysis focuses on the fundamental flaw: lack of pair contract authorization. This architectural issue is independent of which tokens are used and represents a systemic vulnerability in the protocol’s design.

Recommended Mitigations (Based on Olympix’s Analysis)

1. Implement Pair Whitelisting

mapping(address => bool) public authorizedPairs;

modifier onlyAuthorizedPair(address[] memory path) {

address pair = UniswapV2Library.pairFor(factory, path[0], path[1]);

require(authorizedPairs[pair], “Unauthorized liquidity pair”);

_;

}

2. Validate Pair Contract in Swap Functions

function swapExactTokensForFavorAndTrackBonus(

uint amountIn,

uint amountOutMin,

address[] calldata path,

address to,

uint deadline

) external onlyAuthorizedPair(path) {

// Swap logic continues only after pair validation

// This prevents unauthorized pools from triggering bonus minting

}

3. Additional Defense Layers

Beyond the core fix, protocols should implement defense-in-depth strategies:

• Rate limiting on bonus minting: Cap the amount of bonuses that can be claimed per block/transaction
• Gradual vesting of rewards: Time-lock bonus tokens to prevent immediate liquidation
• Monitoring and alerts: Implement real-time tracking of unusual bonus minting patterns
• Emergency pause functionality: Enable quick response to suspicious activity
• Whitelist validation for reward-triggering functions: Ensure all functions that mint or distribute rewards verify the source of the transaction

Root Cause Analysis

Primary Cause

Insufficient validation of liquidity pair contracts in the reward distribution mechanism. The contract validated token addresses but not the pair contract itself, allowing attackers to create unauthorized pools and exploit the bonus system.

Contributing Factors

1. Severity Misclassification: The vulnerability was identified but not properly prioritized
2. Proof-of-Concept Limitations: Using test tokens instead of worthless tokens obscured the real-world exploitability
3. Incomplete Patch Implementation: Recommended fixes were not fully applied to deployed contracts
4. Communication Gap: The full scope of the attack vector was not clearly conveyed
5. Deployment Decision: The team proceeded despite an unresolved vulnerability that should have been critical

Lessons Learned

For Protocol Teams

1. Treat High-severity findings as deployment blockers. Never launch with unresolved High or Critical vulnerabilities, regardless of how theoretical they may seem.

2. Seek explicit clarity on attack scenarios. If a vulnerability involves token swaps or user-controlled inputs, explicitly ask auditors about worst-case scenarios involving attacker-controlled or worthless assets.

3. Question severity downgrades. If a vulnerability is initially flagged as critical but later downgraded, demand clear justification and consider seeking a second opinion.

4. Implement comprehensive fixes. Partial implementations of recommended patches leave protocols vulnerable. Either implement the full solution or don’t deploy.

5. Engage multiple auditors. Different auditing firms have different methodologies and strengths. Multiple perspectives can catch nuances that a single audit might miss.

6. Assume worst-case scenarios. If a mechanism allows arbitrary inputs (tokens, contracts, addresses), assume attackers will use the worst possible values. Design validation accordingly.

For Auditors

1. Use realistic attack scenarios in PoCs. Demonstrate vulnerabilities with the exact conditions an attacker would use. If the vulnerability involves token swaps, use worthless tokens in your proof-of-concept, not test tokens.

2. Focus on architectural flaws over economic assumptions. Issues like “lack of authorization validation” are critical regardless of whether the attack seems economically viable. Economic conditions change; architectural flaws remain.

3. Provide clear, actionable severity classifications. Severity ratings directly impact deployment decisions. Be explicit about why a vulnerability is High vs. Informational, and ensure the client understands the real-world risk.

4. Explicit, jargon-free communication. Describe the attack path in plain language that non-technical stakeholders can understand. Leave no room for misinterpretation.

5. Verify patch implementation. Follow up to ensure recommended mitigations are correctly deployed before the protocol goes live.

For the Web3 Ecosystem

1. Validation is non-negotiable. Always validate that operations occur through authorized, expected contracts — not just that they involve the correct token types.

2. Economic viability is not a security guarantee. Just because an attack seems unprofitable today doesn’t mean it won’t be exploited tomorrow. Technical feasibility = eventual exploitation.

3. Security is a shared responsibility. Auditors must identify and clearly communicate risks. Protocol teams must prioritize and implement fixes. Neither party can succeed alone.

4. Architectural validation matters. In DeFi protocols with reward mechanisms, validating the source of transactions (which pair/contract) is as important as validating the content (which tokens).

The Value of Accurate Severity Classification and Clear Communication

The BetterBank incident illustrates a critical truth: how a vulnerability is communicated can be as important as identifying it in the first place.

The vulnerability was identified before deployment, but it was misclassified as “Informational” and presented in a way that obscured its real-world exploitability. This allowed the protocol to launch with a critical flaw unaddressed.

Olympix’s approach would have prevented this exploit because:

✅ High severity classification = deployment blocker requiring immediate action
✅ Clear vulnerability description = no room for misinterpretation about the core flaw
✅ Focus on architectural issues = immune to debates about economic viability
✅ Explicit attack path = team understands the real-world risk immediately
✅ Direct language = accessible to both technical and non-technical stakeholders

When auditors properly classify severity and clearly communicate attack vectors, protocol teams can make informed decisions about deployment readiness. This is the difference between a $5M exploit and a prevented vulnerability.

Conclusion

The BetterBank exploit resulted in a $5M loss due to a vulnerability that was identified during audit but inadequately addressed before deployment. The core issue — lack of liquidity pair validation — was exploitable regardless of which tokens were used, but miscommunication about the attack vector and incorrect severity classification led to a dangerous oversight.

This exploit could have been prevented through:

• Proper severity classification (High, not Informational)
• Clear communication of the attack vector using realistic scenarios
• Focus on the architectural flaw rather than economic assumptions
• Implementation of recommended pair validation controls before deployment

Olympix’s analysis framework demonstrates how accurate severity assessment and direct communication of vulnerabilities can prevent costly exploits. By clearly stating that the issue was unvalidated liquidity pairs with an explicit attack path involving unauthorized pools, Olympix’s approach would have made the risk undeniable and the need for remediation obvious.

While BetterBank successfully recovered the protocol from bad debt and negotiated the return of significant funds, this incident serves as a critical reminder: in DeFi, if an attack is technically possible, it must be assumed that it will eventually be exploited.

Proper validation, accurate severity assessment, clear communication between auditors and protocol teams, and a commitment to fixing all high-severity issues before deployment are essential to preventing such incidents.

Recommendations for the DeFi Community

For Protocols with Reward Mechanisms:

• Implement strict whitelisting for all liquidity pairs that can trigger reward functions
• Validate the source contract of transactions, not just token addresses
• Use defense-in-depth strategies including rate limiting, vesting, and monitoring
• Treat High-severity audit findings as non-negotiable deployment blockers

For Protocols Seeking Audits:

• Engage auditors who provide clear severity classifications with explicit justifications
• Request realistic proof-of-concepts that demonstrate worst-case attack scenarios
• Don’t launch until all High and Critical findings are fully resolved
• Consider multiple audits from firms with different methodologies

Olympix’s approach — combining accurate severity classification, clear vulnerability descriptions, and focus on architectural flaws — represents the standard that DeFi security audits should meet. When auditors flag issues this clearly and protocols respond appropriately, million-dollar exploits become preventable incidents rather than inevitable disasters.

Get Started with Olympix

Explore Olympix’s suite of smart contract tools and learn more about the Olympix-led automated smart contract audit process. Empower your team to take control of your smart contract security from the start. Book a free demo!

‍