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.
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.
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.
Manual analysis.
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.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.