Summary

The LikeRegistry::matchRewards function incorrectly deducts the entire balance of users when a mutual match occurs, instead of deducting 1 ETH per match. This causes a user’s ETH to be fully drained on their first match, leaving no funds for subsequent matches.

Vulnerability Details

Root Cause:

• When a mutual like occurs (e.g., User A likes User B, and User B likes User A), the matchRewards function calculates rewards using the total balance of both users (userBalances[from] and userBalances[to]), then resets their balances to zero.

• This design flaw causes all of a user’s ETH to be sent to the first multisig wallet created for their earliest match, even if they have multiple matches.

Example Scenario:

1. User A sends 3 ETH to like three different users (B, C, D).

2. B, C, and D later like A back, creating three mutual matches.

3. On the first match (A ↔ B), the matchRewards function:

   • Takes A’s entire balance (3 ETH) and B’s balance (1 ETH).

   • Sends 3.6 ETH (4 ETH total - 10% fee) to the A-B multisig wallet.

   • Resets both A and B’s balances to zero.

4. Subsequent matches (A ↔ C, A ↔ D) receive zero ETH because A’s balance is already drained.

Impact

1. Loss of User Funds: Users lose ETH intended for multiple matches (e.g., 3 ETH sent for 3 matches is consumed by the first match).

2. Broken Matching Logic: Only the first match receives ETH, rendering the protocol unusable for users with multiple matches.

3. Protocol Reputation Risk: Users will lose trust in the platform due to fund mismanagement.

Tools Used

• Manual code review.

Recommendations

Modify the matchRewards function to deduct 1 ETH per match instead of the entire balance: