40,000 USDC
View results
Submission Details
Severity: medium
Valid

Incompatibility with Fee-on-Transfer Tokens

Summary

If a fee-on-transfer token is used in the newEscrow function, the balance check in the Escrow contract's constructor causes the operation to revert consistently, preventing proper escrow creation.

Vulnerability Details

The newEscrow function calls the safeTransferFrom to transfer the specified price in tokens from the buyer to the newly created escrow contract. However, if a fee-on-transfer token is used, a portion of the transferred tokens would be deducted as a fee, resulting in a lower amount arriving at the destination. The Escrow contract's constructor, in turn, checks whether the contract's balance is less than the price. In the case of fee-on-transfer tokens, due to the fee deduction, this condition will always be true, causing the constructor to revert.

Severity

The severity of this vulnerability is medium due to the combination of high impact and low likelihood. The impact is high since it prevents the successful creation of escrow contracts when fee-on-transfer tokens are used. Some buyers may be projects whose primary funding token is such a token, and these projects will not be able to use their token to compensate sellers. The likelihood is low since the prevalence of projects that are mainly able to pay in fee-on-transfer tokens is low.

Tools Used

Manual analysis.

Recommendations

To resolve this issue, it's advisable to decouple the escrow creation and the initial funding of the contract. Instead of transferring funds during the newEscrow call, a separate method could be introduced for the buyer to transfer funds to the contract after its successful deployment. This change would ensure compatibility with fee-on-transfer tokens and improve the robustness of the contract system.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.