Part 2

The refundSwap() function incorrectly calculates the refund amount by only deducting the base fee, while completely ignoring the swap fee, which is normally charged when fulfilling a swap. This allows an attacker to repeatedly initiate swaps, wait for them to expire, and claim refunds while avoiding the swap fee entirely. Since the swap fee is a core part of the protocol’s revenue model, this exploit can be used to drain protocol earnings. The issue stems from the refund logic:

Here, only the base fee is deducted, while the swap fee is never charged. This allows an attacker to loop initiateSwap() and refundSwap() indefinitely, repeatedly reclaiming their funds while avoiding the intended swap settlement fee, leading to a systematic loss of protocol revenue.

Impact:

Attackers can drain protocol earnings by repeatedly cycling swaps and refunds without ever paying the swap fee, causing a significant financial loss.

Mitigation:

Modify refundSwap() to deduct both the base fee and swap fee before refunding, ensuring that attackers cannot bypass protocol fees through refund loops.