Summary

Contracts are vulnerable to fee-on-transfer accounting-related issues

Vulnerability Details

The below-listed functions use safeTransferFrom() to move funds from the sender to the recipient but fail to verify if the received token amount matches the transferred amount. This could pose an issue with fee-on-transfer tokens, where the post-transfer balance might be less than anticipated, leading to balance inconsistencies. There might be subsequent checks for a second transfer, but an attacker might exploit leftover funds (such as those accidentally sent by another user) to gain unjustified credit.

Impact

In this particular instance if a token being es-crowed has fees the 'price' variable which is passed into the 'new Escrow' struct may differ from how much tokens were actually transferred (safeTransferFrom) to the computed address. This can have serious consequences as the end receiver of the escrowed tokens may receive less tokens than anticipated. This is especially concerning if the escrowed token has a modifiable fees value as some do. As in such instances the individual creating a new escrow can temporarily increase the fees when creating a new escrow to reduce the amount of tokens they need to send (if they are the fees beneficiary) only to change it back after. The getPrice() view function will no show the true price if there is a fees which can further mislead individuals.

Tools Used

• Manual Analysis

Recommendations

A practical solution is to gauge the balance prior and post-transfer, and consider the differential as the transferred amount, instead of the predefined amount. This can allow tokens with fees to be reverted if there is a difference. On the other hand another solution is to recalculate price by using the difference in token balance before and after as the price rather than the initial amount. The function balanceOf() can be used to achieve either of these solutions.