Summary

The documentation doesn't describe how "vetting" of tokens will work, but the mechanism is not deployed on chain, which means that technically users are able to use any ERC20 token. The only documentation restriction is that ERC777 are not supported. fee-on-transfer tokens are not mentioned, yet they will not work, because first in EscrowFactory price amount of tokens is transferred from user to Escrow, then in the constructor balanceOf(address(this)) is checked to be at least price. In case fee-on-transfer tokens it will not be possible, as the balanceOf will diminish after transfer to Escrow. There is a workaround for it - directly sending tokens to Escrow address to be deployed. This way, seller will get amount - fees - less than expected.

Vulnerability Details

A malicious seller can top up the newly created Escrow ahead of time to bypass the restriction of Escrow.constructor of token amount:

This will make the constructor logic work, however later when either confirming the receipt or resolving a dispute, will make seller receive less tokens than expected.

Impact

a) not possible to use fee-on-transfer tokens
b) making user receive less tokens than expected when fee-on-transfer tokens are used

Tools Used

Manual analysis

Recommendations

Check account token balances before transfering them and after, and calculate proper amount based on it.