Root + Impact

Description

• In the Dating DApp (Web3 Audit) protocol, the owner is permanently locked out of withdrawing accumulated protocol fees. The withdrawFees() function correctly restricts access using the onlyOwner modifier and requires that totalFees > 0. However, because of the previously identified broken accounting in the likeUser() function, userBalances always evaluate to zero. When matchRewards() executes, it calculates the matchingFees as a percentage of 0. Consequently, totalFees always increases by 0, leaving the state variable permanently empty.

  function likeUser(address liked) external payable {

  require(msg.value >= 1 ether, "Must send at least 1 ETH"); //Checks but doesn't update the state

  require(!likes[msg.sender][liked], "Already liked");

  require(msg.sender != liked, "Cannot like yourself");

  require(

  profileNFT.profileToToken(msg.sender) != 0,

  "Must have a profile NFT"

  );

  require(

  profileNFT.profileToToken(liked) != 0,

  "Liked user must have a profile NFT"

  );

  ​

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

  emit Liked(msg.sender, liked);

  ​

  // Check if mutual like

  if (likes[liked][msg.sender]) {

  matches[msg.sender].push(liked);

  matches[liked].push(msg.sender);

  emit Matched(msg.sender, liked);

  matchRewards(liked, msg.sender);

  }

  }
  function matchRewards(address from, address to) internal {

  uint256 matchUserOne = userBalances[from];

  uint256 matchUserTwo = userBalances[to];

  userBalances[from] = 0;

  userBalances[to] = 0;

  ​

  uint256 totalRewards = matchUserOne + matchUserTwo;

  uint256 matchingFees = (totalRewards * FIXEDFEE) / 100;

  uint256 rewards = totalRewards - matchingFees;

  totalFees += matchingFees; //Doesnt update the state which cause the revert

  ​

  // Deploy a MultiSig contract for the matched users

  MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);

  ​

  // Send ETH to the deployed multisig wallet

  (bool success, ) = payable(address(multiSigWallet)).call{

  value: rewards

  }("");

  require(success, "Transfer failed");

  }

Risk

Likelihood:

• Because the root cause lies in a guaranteed mathematical failure during the matching process, totalFees will never increment under any circumstances. Therefore, every single attempt by the owner to call withdrawFees() will fail.

  
  

Impact:

• The protocol suffers a 100% loss of its intended revenue. The Ether that should have been collected as fees remains permanently trapped inside the LikeRegistry contract, alongside the users' stuck funds, with no alternative administrative function available to sweep or recover it.

Proof of Concept

The accompanying Foundry test demonstrates the downstream failure of the fee accounting system. The test simulates a successful match where Alice and Spider each deposit 1 Ether (totaling 2 Ether held by the contract). When the protocol owner attempts to call withdrawFees(), the transaction reverts with the specific error "No fees to withdraw". The final assertions definitively prove that the contract balance remains exactly at 2 Ether and the owner successfully retrieves nothing.

Recommended Mitigation

• Because this is a cascading failure, resolving this issue requires fixing the root cause upstream rather than changing the withdrawFees() function itself.