DatingDapp

Summary

The Multisig contract does not provide a way for users to cancel a match once it has been initiated. If one party continuously refuses to approve the transaction, the other party is left in a position where they cannot withdraw their Ether. Additionally, there is no mechanism for users to retrieve their deposited funds if they change their minds before the transaction is fully executed. Without a way to cancel the match and recover at least a portion of their funds, users may experience indefinite fund locking.

Vulnerability Details

In the current implementation, once a match is initiated, both parties must approve the transaction for it to be executed. However, if one participant intentionally refuses to approve, the transaction remains in a pending state indefinitely, preventing the other user from accessing their funds. There is no expiration or timeout mechanism, meaning that the funds can become permanently stuck if the counterparty does not cooperate.

Additionally, users may want to cancel the match for various reasons, such as changing their minds or unforeseen circumstances. However, the contract does not provide any function to allow users to cancel a match and retrieve their deposited Ether. This leads to a situation where users are forced to keep their funds locked without any recourse.

Furthermore, if a transaction has already been executed and some of the funds have been used, the contract should ensure that cancellations do not create inconsistencies. If funds have already been partially withdrawn, the remaining balance should be adjusted proportionally, or cancellations should be restricted once transactions have been processed.

Impact

The absence of a cancellation mechanism creates a scenario where users may permanently lose access to their deposited funds due to an uncooperative counterparty. This can lead to financial losses and reduce user trust in the contract. Additionally, without the ability to retrieve funds, users may be discouraged from using the contract, ultimately impacting the platform's usability and adoption.

Tools Used

Manual Audit

Recommendations

To resolve this issue, the contract should implement a cancellation function that allows users to withdraw their deposited Ether if the match is not completed within a certain timeframe or if the counterparty refuses to approve the transaction. This function should ensure that users can recover their funds while preventing abuse.

A possible implementation is to introduce a match cancellation mechanism that allows a user to cancel their match before execution, returning their deposited Ether minus a small fee. This function should include checks to ensure that:

1. The transaction has not already been executed.

2. The cancellation is requested before a predefined expiration period.

3. The refund amount is calculated based on the user’s initial deposit minus any applicable fees.

Additionally, to prevent abuse, the contract should restrict cancellations after transactions have been executed. If funds have already been partially withdrawn, the remaining balance should be adjusted proportionally to prevent inconsistencies.

By introducing this functionality, the contract will prevent funds from being locked indefinitely, improve user experience, and ensure that participants have a way to exit transactions fairly.