First Flight #3: Thunder Loan

Vulnerability Details

The ThunderLoan protocol's smart contracts are found to be incompatible with rebasing tokens and tokens that implement a fee-on-transfer mechanism. The core issue stems from the fact that the contract's functions for depositing, redeeming, repaying, and handling flash loans do not account for the possibility of the token balances changing outside of the direct control of the contract (such as through rebasing) or the actual transfer amount differing from the requested transfer amount (due to fees).

For example, in the deposit function, the protocol calculates the amount to mint based on the deposited amount without considering that a fee-on-transfer token might deduct a fee, resulting in less than the expected amount being actually transferred to the contract:

Similarly, the redeem, flashloan, and repay functions make calculations based on the assumption that the token's balance before and after transfers will change predictably and linearly, which is not the case with rebasing or fee-on-transfer tokens:

Impact

This incompatibility can lead to incorrect accounting of tokens, potential loss of funds for users, and a mismatch in the expected and actual token balances held by the protocol. For fee-on-transfer tokens, the protocol may end up with fewer tokens than expected, disrupting the token economics and potentially leading to insolvency issues. For rebasing tokens, the protocol's accounting may become inconsistent with the actual token supply, leading to incorrect minting of asset tokens and potentially creating a vulnerability that can be exploited by attackers.

Recommendations

To address this issue, the ThunderLoan protocol should implement logic to handle the unique characteristics of rebasing and fee-on-transfer tokens:

1. Fee-on-Transfer Tokens: Before any token transfer, the contract should calculate the expected balance changes by querying the balance before and after a test transfer of a small amount of tokens (if feasible). Alternatively, a more complex integration could be developed, where the token contract informs the ThunderLoan protocol of the fee so that it can be accounted for.

2. Rebasing Tokens: The protocol should either disallow rebasing tokens altogether or implement a mechanism to track the proportional share of the underlying tokens rather than a fixed amount. This would require a fundamental redesign of the token accounting system.