Summary

In the Escrow contract, there is a possibility of a race condition between the confirmReceipt() and initiateDispute() functions, albeit very unlikely due to the nature of the interaction.

Vulnerability Details

In the Escrow contract, there is a possibility of a race condition between the confirmReceipt() and initiateDispute() functions, albeit very unlikely due to the nature of the interaction. In the unlikely scenario where the buyer clicks on the confirmReceipt() function at the exact same time as the seller clicks on the initiateDispute() function, there might be a race to execute these transactions.

If the initiateDispute() function is mined first and successfully changes the state to State.Disputed, the subsequent call to confirmReceipt() will fail due to the require statement inState(State.Created). Consequently, the ERC20 token transfer within the confirmReceipt() function will not take place, and the transaction will revert.

Impact

So in the rare event that initiateDispute() is mined first and the confirmReceipt() transaction reverts, the buyer will still incur transaction fees.

Tools Used

VSC, manual.

Recommendations

Sequential User Interactions: Design the user interface in such a way that the buyer and seller can only trigger functions in a well-sequenced manner, reducing the chances of triggering simultaneous conflicting transactions that could trigger reverts as a result.