Summary

Fee-on-transfer tokens cannot be used in escrow contracts due to a flawed validation check, causing a denial of service for some buyers.

Vulnerability Details

To start an audit, a buy needs to deploy an escrow contract and fund it with any (vetted) ERC20 tokens (WETH, USDC, LINK, DAI, etc), Buyers call EscrowFactory.newEscrow(price,,,,,), where the specified price is transferred to the newly created escrow contract. The problem lies within the constructor of the Escrow Contract, where a validation check is performed to ensure that the contract's balance is not less than the specified price as follows:

This validation is appropriate for most tokens; however, it fails for fee-on-transfer tokens like PAXG, USDT, and USDC. The reason is that fee deductions result in a discrepancy between the price and the actual contract balance, causing this validation to always revert. Consequently, users holding fee-on-transfer tokens are unable to deploy escrow contracts and, consequently, initiate an audit process.

Impact

• The identified vulnerability leads to a denial of service for certain buyers who possess fee-on-transfer tokens, obstructing their ability to participate in the escrow-based auditing process.

Tools Used

Shaheen's Vision

Recommendations

It is recommended to modify the validation check to ensure the contract is sufficiently funded while accommodating fee-on-transfer tokens. A revised implementation of the check could be as follows:

By adjusting the validation condition to allow a balance greater than zero, users holding fee-on-transfer tokens can now successfully deploy escrow contracts and participate in the auditing procedure. As the contract address will be newly created so a balance greater than zero will be an indication of a successful escrow deposit balance.

Note: This mitigation might lead to some other vulnerability. We would recommend the team, discuss a more solid solution for this. Thanks!