Summary

Arbiter lack of explicit confirmation can lead to potential locked up token when dispute happen

Vulnerability Details

Initially, when the buyer and seller agree not to use an arbiter, the contract creation initializes the arbiter as address(0). However, if they decide to involve an arbiter, the arbiter's address must be provided as input.

Unfortunately, the arbiter address is not properly validated. This means that not only is the correctness of the address not verified, but it is also not checked whether the arbiter has explicit agreement to act as the arbitrage party for both the buyer and seller. Additionally, when deploying this escrow contract on any EVM, there is a potential risk of mistakenly assigning the wrong address, especially when dealing with a multisign wallet as an arbiter.

The potential consequences of these issues are the lock-up of tokens within the contract in the event of a dispute. These issues arise due to the following reasons:

1. Invalid arbiter address: When the arbiter's address is not valid (e.g, multisign address on different chain), the contract cannot execute the resolveDispute function, leading to an unresolved dispute.

2. Rejected task by the arbiter: If the arbiter rejects the task due to a lack of prior agreement, the dispute remains unresolved, and the tokens remain locked within the contract.

3. Unawareness of the arbiter's assignment: In cases where the arbiter is unaware of being assigned as the arbitrator, they may fail to perform their role, leaving the dispute unresolved and the tokens locked up.

Even though the Arbiter is described as a trusted party, their involvement remains optional, leaving room for unforeseen possibilities. Forcing the input of an arbiter by the buyer with an arbiter fee of 0 or any minimum fee can lead to disagreements when the arbiter is unwilling to act as the arbitrage party. Moreover, assigning the arbiter without their consent may result in instances where they are retired or unaware of their role as an Arbiter. To address these concerns, implementing an explicit acceptAsArbiter() function is essential, as it helps minimize such issues by ensuring that the arbiter willingly accepts the task, reducing the chances of conflicts.

Impact

Locked-up token on contract when dispute happen, due to arbiter failed to mitigate

Tools Used

Manual analysis

Recommendations

Consider to implement such function like acceptAsArbiter(). This function allows the arbiter to confirm their role in the dispute resolution process. By requiring the arbiter's explicit acceptance, we ensure their willingness to fulfill their role as the arbitrator, establishing a more robust and secure escrow contract. If the arbiter confirms their acceptance, the contract state changes to Created, and the escrow process proceeds. However, if the arbiter does not confirm their role, the Buyer's funds can be refunded, allowing the selection of another arbiter. This mechanism enhances the contract's reliability and ensures that only committed arbiters are involved in the resolution process, leading to a smoother and more secure escrow experience for all parties involved.