Potential Issue with Fee-on-Transfer and Blacklisted Tokens in `deposit` Function
c4-bot-3 opened this issue · 0 comments
Lines of code
Vulnerability details
Description
The deposit function is responsible for accepting a deposit in Ether for a specific credId, updating the contract's internal balance for that credId, and emitting a Deposit event. The function checks whether the msg.value (the Ether sent with the transaction) matches the amount specified in the function call. If these values do not match, the transaction is reverted.
It might be vulnerable to issues related to fee-on-transfer tokens and blacklisted tokens. Specifically, the function assumes that the amount of tokens sent in a transaction will always match the msg.value specified by the sender. However, if the deposited tokens have transfer fees or are subject to blacklisting (e.g., USDC tokens with blacklist functionality), this assumption may not hold true, leading to discrepancies in the recorded balance and potential loss of funds.
Some tokens (commonly referred to as fee-on-transfer tokens) deduct a small fee whenever a transfer occurs. For example, a token might charge a 2% fee on each transaction. If a user sends 100 tokens to the contract, only 98 tokens might actually be received due to this fee. However, the contract would expect to receive the full 100 tokens based on the amount parameter provided by the user. This discrepancy would cause the msg.value to not match the amount, leading to a potential revert or incorrect balance tracking within the contract.
Certain tokens, such as USDC, have blacklist functionalities that can block specific addresses from receiving tokens. If the contract is blacklisted, the transfer might fail, or only a portion of the tokens might be transferred. The deposit function does not account for this, leading to potential issues in handling such scenarios.
Impact
The function might revert unexpectedly if there’s a mismatch between msg.value and amount, causing inconvenience and potential loss of gas fees. If the contract does not correctly receive the full amount due to fees or blacklisting, the internal balanceOf mapping might be incorrectly updated, leading to discrepancies in the recorded balance versus the actual tokens held by the contract.
Tools Used
Manual Review
Recommendation
The contract should account for potential discrepancies caused by fee-on-transfer tokens. One approach is to adjust the expected amount based on the actual received tokens, rather than strictly relying on msg.value. Implement a mechanism to handle or reject deposits if the contract is blacklisted by certain tokens, or integrate a fallback mechanism to revert gracefully.
Assessed type
Token-Transfer