DatingDapp

Summary

The fee calculation mechanism in matchRewards incorrectly uses an uninitialized storage variable userBalances, leading to improper fee distribution. As a result, fees are never collected, breaking the protocol’s expected revenue model.

Vulnerability Details

The function matchRewards attempts to compute fees using the userBalances mapping, but this mapping is never updated elsewhere in the contract. Consequently, when the function executes:

1. matchUserOne = userBalances[from] and matchUserTwo = userBalances[to] always evaluate to 0.

2. totalRewards = matchUserOne + matchUserTwo = 0 + 0 = 0.

3. The calculated matchingFees = (totalRewards * FIXEDFEE) / 100 = (0 * 10) / 100 = 0.

4. No actual fees are collected despite the protocol’s requirement to charge a 10% fee.

5. The multisig wallet meant to receive the remaining rewards is deployed but receives 0 ETH, making the contract non-functional.

Impact

Severity: High

• The protocol fails to collect its intended 10% fee, leading to revenue loss.

• totalFees becomes an inaccurate reflection of collected fees, breaking treasury tracking.

• Matches generate no actual rewards, potentially discouraging user engagement.

• The core fee distribution mechanism is completely ineffective, affecting protocol sustainability.

Recommended Fix

Solution: Introduce Explicit Fee and Distribution Constants

Since each "like" incurs a 1 ETH fee, and a match consists of two likes, the correct calculation should be:

• Total match amount: 2 ETH

• Protocol fee (10%): 0.2 ETH

• Remaining amount for matched users' multisig: 1.8 ETH

Introduce explicit constants for these values:

Solution: Fix matchRewards Function

The new version ensures that fees are correctly accounted for and funds are sent properly:

Tools Used

• Manual Code Review

• Foundry Testing