DatingDapp

Summary

• The system shouldn't work in a way that after a mutual like, another mutual like can still happen, but if that's the intended design, then it's prone to the following vulnerability

Vulnerability Details

• Scenario: Imagine User A has already liked 5 users, including User B and User C. Upon User B liking User A back, creating a mutual match, all of User A's previous like payments are pooled into a MultiSig account with User B's payment for their first date. Even after a user has a mutual like, he or she can still like other users, leading to:

  • Inequitable Distribution of Funds: User A's like payments have already been allocated to the match with User B, leaving User C without the benefit of User A's previous contributions when User C matches with User A.

  • Front-Running Exposure: This setup incentivizes users or malicious actors to front-run the blockchain to match with someone just after they've matched, hoping to catch the remaining, larger pool of funds before it's depleted. This can lead to:

    • Disadvantage for Late Matchers: Users who match later with someone who has already matched receive less or no financial benefit, leading to unfair treatment.

    • Front-Running Vulnerability: The system becomes susceptible to front runnig where users rush to match with someone they know has recently matched to gain access to more funds.

Impact

• Financial Inequity: Users who match later are financially disadvantaged, which could lead to dissatisfaction and a perception of the system as unfair.

• Manipulation of Matches: Encourages a race to match, potentially skewing the platform's purpose from genuine dating to financial exploitation.

Tools Used

Manual Review and foundry

Recommendations

• Reconsider the Design of Mutual Match Mechanics:

  • Single Mutual Match per User: If the intent is to prevent this scenario, redesign so that once a user has a mutual match, they cannot create another until the first match is resolved or expires.

  • Or, Equitable Reward Distribution:

    • If multiple matches are intended, ensure each match pools only the mutual like payments, not all previous likes:

    solidity

    // In LikeRegistry.sol

    mapping(address => mapping(address => uint256)) public likePayments; // Track each like's payment

    ​

    function likeUser(address liked) external payable {

    // ... existing checks

    likes[msg.sender][liked] = true;

    likePayments[msg.sender][liked] = msg.value; // Store payment for this specific like

    // ... rest of the function

    }

    ​

    function matchRewards(address from, address to) internal {

    uint256 rewardsFrom = likePayments[from][to];

    uint256 rewardsTo = likePayments[to][from];

    delete likePayments[from][to];

    delete likePayments[to][from];

    ​

    uint256 totalRewards = rewardsFrom + rewardsTo;

    uint256 matchingFees = (totalRewards * FIXEDFEE) / 100;

    uint256 rewards = totalRewards - matchingFees;

    ​

    // Deploy and fund the MultiSigWallet with the calculated rewards

    MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);

    (bool success,) = payable(address(multiSigWallet)).call{value: rewards}("");

    require(success, "Transfer to MultiSig failed");

    }

Additional Considerations:

• Front-Running Prevention: By ensuring each match only involves the mutual like payments, the incentive for front-running is neutralized.

• User Expectations: Clearly communicate the system's mechanics to users to set the right expectations about matching and rewards.

• System Fairness: This redesign aims to maintain fairness across all users, potentially increasing user trust and reducing manipulative behaviors.

This approach would address the vulnerability by either limiting the number of mutual matches per user or by ensuring each match is treated equitably in terms of pooled funds.