Summary

The known issues states that it is in the buyers best interest to deploy the contract details agreed upon by them and the seller correctly, however this is not necessarily true.

A buyer and a seller could reach an agreed upon escrow, however the buyer can substitute his own address, a seperate address under his control, or an address his best friend from 1st grade controls, (or an address the buyer controls and the buyers best friend from first grade says its his), in an attempt to scam the seller into working for free. Even if the seller does adequate due diligence, they are at risk of being scammed.

Vulnerability Details

Buyer sets it up so he and arbiter can conspire against seller. seller is fooled because the arbiter is untruthful about his neutrality. seller does his work and sends it to buyer. buyer then disputes, and arbiter rules in favor of buyer, pocketing a small fee for his part, buyer gets a large % of money back (or all of it if the 'arbiter' is an address he controls'), essentially receiving an audit at a heavily discounted price, while the seller is SOL.

Impact

Sellers are never 100% positive about the neutrality of the arbiter and thus are disincentivized to use this system.

Tools Used

manual review

Recommendations

add check in the Escrow constructor preventing arbiter address and buyer address from being the same. This will prevent scammy buyers from attempting to scam sellers and being able to easily retrieve their own funds.

An additional registry for arbiters, in which potential arbiters register and are randomly assigned to escrow contracts if their availability and fees line up with buyer/seller parameters. Would need some notification system for arbiters to know theyve been selected, potentially through as simple event monitoring service that pings their given discord/email/whatever when it detects that their address was selected, a modifier on disputes/resolutions where nothing can happen until arbiter/buyer/seller all confirm their willingness to participate, and a timelock refund mechanism where the buyer is automically refunded the funds he deposited if the arbiter/seller have not both confirmed on chain they are ready to begin work. once this confirmation is received, the timelock refund is deactivated, and the only way for a buyer to retrieve his funds is through successful dispute resolution. Look, this contract is written super well, I really couldnt find anything wrong with it. Looking forward to seeing if others could, but as someone who potentially might be the seller on the end of this service, this was a major concern I had that i did not see addressed a known issue. I also realize my recommendations mean greatly increasing the complexity of the contract, but given that in my mind this system is simply not trustless (seller has to trust arbiter and buyer will not conspire, where as the buyer and arbiters most beneficial outcome is too conspire against the seller, guarenteeing the arbiter a fee and the buyer a greatly discounted audit), i think additional complexity is warranted. But given that these are more personal concerns over system design rather than actual vulnerabilities, I dont really expect this issue to be considered valid, just wanted to give you guys my thoughts.