Summary

The lack of an arbiter (i.e., zero-address) at the time of the Escrow contract deployment prevents the buyer from getting the funds back in case of a dispute or a consensual agreement not to do business anymore.

Vulnerability Details

In case the seller and buyer agree not to do business anymore (or have a dispute), and no arbiter (i.e., zero-address) was defined at the time of the Escrow contract deployment, there is no way to return the funds (price - the current balance of i_tokenContract) to the buyer. The only possibility to return the funds to the buyer is by first having the buyer call the confirmReceipt, which sends the escrowed funds to the seller, and then trust the seller to return the funds to the buyer. This puts the buyer at risk of losing the funds if the seller does not return the funds to the buyer.

Escrow.confirmReceipt

The confirmReceipt function is only callable by the buyer and transfers the escrowed funds to the seller (i_seller).

Impact

Escrowed funds remain locked in the Escrow contract and can not be returned to the buyer without trusting the seller to return the funds to the buyer.

Tools Used

Manual Review

Recommendations

Consider enforcing an arbiter address when deploying the Escrow contract, potentially providing a default arbiter address, or, alternatively, adding functionality to propose a new arbiter (by having the consensus of both involved parties) to change/add an arbiter.

Additionally, consider the possibility of time-limit the escrow and having the seller be able to settle the escrow and get the funds after a certain time has passed, especially if there's no arbiter configured and the buyer is unresponsive (and vice-versa).