Summary

Current implementation causes funds to be stuck in escrow if any of the three parties get blocklisted

Vulnerability Details

Note that in the public discord channel for this contest, different discussions have been had on what type of tokens the protocol supports, with sponsor Patrick Collins specifically noting

Tokens vetted by the team that decides to use them, like USDC, DAI, WETH, etc

Now also note that https://github.com/d-xo/weird-erc20#tokens-with-blocklists shows that:

Some tokens (e.g. USDC, USDT) have a contract level admin controlled address blocklist. If an address is blocked, then transfers to and from that address are forbidden.

Back to the Escrow.sol contract, we can see that the transfer of tokens is been processed in a "send" method and not a withdrawal method, i.e none of the three parties can withdraw by specifying their addresses but rather contract sends them to the hardcoded addresses that was used to deploy the contract.
Whereas the chances are low this means that in a case where gets added to a blocklist by the tokenContract used, say USDC in our case, this means that even if the buyer calls the confirmReceipt()
function, this line would cause the transaction to revert since an attempt to withdraw the tokens would fail due to it being in the blocklist.

Additionally if either one or more of buyer, seller & arbitor get added into the blocklist, this could even be worse in a case where the initiateDispute() function is called, since if there exist an arbitor fee (which would most likely be the case always) then this line would cause the transaction to revert, alternatively if the arbitor decides to set the buyerAward > 0 then this line could easily cause the transaction to revert in the case where buyer is in the blocklist, now note that even if the buyer is of good intention and wants to change their mind to confirm receipt instead, the function call wont workdue to the changed state at this line.

Impact

Funds get stucked in the contract

Tools Used

Manual Audit

Recommend Mitigation

Consider using a pull over push pattern, i.e in the case of a withdrawal to seller, a new modifier onlySeller should be created and the confirmReceipt() should only change the state of the to confirmed then introduce a new function that allows seller to claim the funds only when the state is confirmed and this function should allow sender to specify the address they would like their funds to be sent to.
A similar methodology should be applied while resolving disputes too in the case any other of the three parties get blocklisted.