DatingDapp
AI First Flight #6
Beginner FriendlyFoundrySolidityNFT
EXP
View results
Previous Next
Submission Details
Severity: high
Valid

[H-02] Fee Accounting Broken — Owner Can Never Withdraw Fees

kivanov

[H-02] Fee Accounting Broken — Owner Can Never Withdraw Fees

Scope

  • LikeRegistry.sol

Description

As a direct consequence of H-01, the matchRewards() function computes totalRewards = userBalances[from] + userBalances[to] which is always 0. The fee calculation (0 * 10) / 100 = 0 means totalFees is never incremented. The withdrawFees() function has a guard require(totalFees > 0, "No fees to withdraw") that always reverts.

function matchRewards(address from, address to) internal {
@> uint256 matchUserOne = userBalances[from]; // Always 0
@> uint256 matchUserTwo = userBalances[to]; // Always 0
uint256 totalRewards = matchUserOne + matchUserTwo; // 0
uint256 matchingFees = (totalRewards * FIXEDFEE) / 100; // 0
totalFees += matchingFees; // 0 += 0

Risk

Likelihood: High

  • Every match triggers this code path. The fee mechanism is called on every mutual like.

Impact: High

  • Protocol owner earns zero revenue. The 10% fee mechanism is entirely non-functional. Combined with H-01, the protocol has no working economic model.

Severity: High

  • SWC: SWC-105

  • CWE: CWE-682 (Incorrect Calculation)

  • Evidence Grade: A

Proof of Concept

After creating a match between two users who each deposit 1 ETH, the owner attempts to withdraw fees. The transaction reverts because totalFees is still 0.

function test_P0_H2_fee_accounting_broken() public {
vm.prank(alice);
registry.likeUser{value: 1 ether}(bob);
vm.prank(bob);
registry.likeUser{value: 1 ether}(alice);
​
vm.prank(owner);
vm.expectRevert("No fees to withdraw");
registry.withdrawFees();
}

forge test --match-test test_P0_H2_fee_accounting_broken -vvvv → PASS

Recommended Mitigation

The root cause is shared with H-01: userBalances is never set. Once H-01 is fixed, matchRewards() will read real balances, compute a non-zero totalRewards, and totalFees will increment correctly. However, withdrawFees() itself also has a subtle issue — it should validate that the contract actually holds enough ETH before attempting transfer. The minimal fix is H-01's one-liner, but a defensive improvement to withdrawFees() is also recommended:

function likeUser(address liked) external payable {
require(msg.value >= 1 ether, "Must send at least 1 ETH");
+ userBalances[msg.sender] += msg.value;
require(!likes[msg.sender][liked], "Already liked");
function withdrawFees() external onlyOwner {
require(totalFees > 0, "No fees to withdraw");
+ require(address(this).balance >= totalFees, "Insufficient balance");
uint256 totalFeesToWithdraw = totalFees;
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 2 hours ago
Submission Judgement Published
Validated
Assigned finding tags:

[H-01] After the user calls the `likeUser` function, the userBalance does not increase by the corresponding value.

## Description User A calls `likeUser` and sends `value > 1` ETH. According to the design of DatingDapp, the amount for user A should be accumulated by `userBalances`. Otherwise, in the subsequent calculations, the balance for each user will be 0. ## Vulnerability Details When User A calls `likeUser`, the accumulation of `userBalances` is not performed. ```solidity function likeUser( address liked ) external payable { require(msg.value >= 1 ether, "Must send at least 1 ETH"); 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); } } ``` This will result in `totalRewards` always being 0, affecting all subsequent calculations: ```solidity uint256 totalRewards = matchUserOne + matchUserTwo; uint256 matchingFees = (totalRewards * FIXEDFEE ) / 100; uint256 rewards = totalRewards - matchingFees; totalFees += matchingFees; ``` ## POC ```solidity function testUserBalanceshouldIncreaseAfterLike() public { vm.prank(user1); likeRegistry.likeUser{value: 20 ether}(user2); assertEq(likeRegistry.userBalances(user1), 20 ether, "User1 balance should be 20 ether"); } ``` Then we will get an error: ```shell [FAIL: User1 balance should be 20 ether: 0 != 20000000000000000000] ``` ## Impact - Users will be unable to receive rewards. - The contract owner will also be unable to withdraw ETH from the contract. ## Recommendations Add processing for `userBalances` in the `likeUser` function: ```diff function likeUser( address liked ) external payable { require(msg.value >= 1 ether, "Must send at least 1 ETH"); 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; + userBalances[msg.sender] += msg.value; emit Liked(msg.sender, liked); [...] } ```

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!