Summary

The escrow contract system is designed to handle transactions between a buyer and a seller, with an optional arbiter for dispute resolution. However, there is a potential risk if the buyer or seller is a contract that can be destructed or self-destructed. This could lead to funds being locked in the escrow contract, causing loss of funds and disrupting the intended workflow of the system.

Vulnerability Details

The buyer and seller are integral actors in the escrow contract system. If either the buyer or seller is a contract that can be destructed or self-destructed, it could lead to potential issues. Specifically, if the buyer or seller contract is destructed after the escrow contract is created but before the confirmReceipt or initiateDispute function is called, it could lead to funds being locked in the escrow contract. This is because the confirmReceipt and initiateDispute functions are designed to be called by the buyer or seller, and if these addresses no longer exist, these functions cannot be called.

Code Snippet

Impact

If the buyer or seller contract is destructed, it could lead to funds being locked in the escrow contract. This could result in loss of funds for the buyer or seller, and disrupt the intended workflow of the escrow system.

Tools Used

Manual code review

Recommendations

To mitigate this risk, the escrow contract system could implement checks to ensure that the buyer and seller are not contracts that can be destructed. This could be done by adding a function that checks if the code at the buyer or seller address is non-zero, which would indicate that it is a contract. Additionally, the system could implement a mechanism to handle the scenario where the buyer or seller contract is destructed, such as allowing the arbiter to resolve the transaction in this case.