Summary

The buyer and seller who engage with this Escrow contract are two parties with different interests. Considering the case in which there is a dispute, the only way in which the seller will receive funds (considering buyer has full control over calling confirmReceipt) is through the arbitration process described in resolveDispute. Let's consider why this is the case. The buyer has already effectively purchased the service in the tokenContract.safeTransferFrom(msg.sender, computedAddress, price); call performed in the EscrowFactory contract. Therefore, they have no incentive to send the funds to the seller if they are even somewhat dissatisfied with the service performed.

Now let's consider cases in which the current arbitration process will not succeed:

1. There is no arbiter set, as the parties did not anticipate an issue, and since this is not required. In this case, the seller will receive no funds, even if the buyer would be okay with a certain percentage payout.

2. Arbiter was active at escrow creation but no longer provides services. In this case, similar as before, the seller will receive no funds, even if the buyer would be okay with a certain percentage payout.

3. Arbiter is no longer satisfied with the stated i_arbiterFee and refuses to provide services. This is similar to the above case.

To solve these above cases, it is necessary that there be functionality, based on consent between the buyer and seller, to update the i_arbiter address (and potentially also the i_arbiterFee), rather than having it be fixed. Otherwise, the current system is heavily weighted against the seller of the service. Although it is true that a malicious buyer could DOS this added functionality, we assume non-malicious actors - which in this case means that the buyer is willing to pay a fee proportional to what they believe the seller deserves. If the arbiter is allowed to be changed, then the highlighted issue will be resolved.

Vulnerability Details

Let's consider the following chain of events resulting in the seller not getting paid:

1. buyer and seller agree upon an escrow contract in which they don't set an arbiter, since they don't expect there to be any issues - at creation, the buyer sends funds to the escrow

2. seller performs a service in which the buyer is not completely satisfied - they believe the seller should only receive 50% of the payout

3. seller agrees with the 50% cut - however, since there is no arbiter set to perform this action, the buyer simply chooses to not call confirmReceipt, and the seller receives no payout

Impact

The current escrow implementation is weighted against the seller, which in the case of any issue with the arbiter (assuming non-malicious buyer), means that the seller will receive no funds (since the cost to the buyer is the same whether or not the seller gets paid).

Tools Used

Manual review

Recommendations

There should be added functionality which, based on consent between the buyer and seller, will update the arbiter address (and potentially also the fee).