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

likeUser takes 1 ETH but never credits userBalances, so matchRewards always pools 0 and every like payment is permanently locked in LikeRegistry

hopeh

Description

DatingDapp's whole premise (from the project description) is: "they pay 1 ETH to 'like' their profile. If the like is mutual, all their previous like payments (minus a 10% fee) are pooled into a shared multisig wallet." Those per-user like payments are supposed to be tracked in userBalances.

likeUser is payable and forces the caller to send at least 1 ETH — but it never records that ETH anywhere:

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);
​
if (likes[liked][msg.sender]) { // mutual like
matches[msg.sender].push(liked);
matches[liked].push(msg.sender);
emit Matched(msg.sender, liked);
matchRewards(liked, msg.sender);
}
}

There is no userBalances[msg.sender] += msg.value anywhere in the contract, so userBalances stays 0 for everyone. matchRewards then pools from those zero balances:

function matchRewards(address from, address to) internal {
uint256 matchUserOne = userBalances[from]; // always 0
uint256 matchUserTwo = userBalances[to]; // always 0
userBalances[from] = 0;
userBalances[to] = 0;
uint256 totalRewards = matchUserOne + matchUserTwo; // 0
uint256 matchingFees = (totalRewards * FIXEDFEE) / 100; // 0
uint256 rewards = totalRewards - matchingFees; // 0
totalFees += matchingFees; // 0
MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);
(bool success,) = payable(address(multiSigWallet)).call{value: rewards}(""); // sends 0
}

So on a mutual match the shared MultiSig receives 0 ETH — the central feature transfers nothing. Meanwhile every 1-ETH likeUser payment just accumulates in LikeRegistry with no way out: the only withdrawal, withdrawFees, pays totalFees, which is also always 0. Every ETH any user ever pays to like is permanently locked in the contract.

Risk

Impact: High. Permanent, unrecoverable loss of all user funds. Each like costs ≥1 ETH; that ETH is never credited, never poolable, and never withdrawable — it is stranded in LikeRegistry forever, and the matched-pool feature always sends 0.

Likelihood: High. It happens on every single like, on the only user-facing payable path, with no attacker and no special conditions.

Proof of Concept

function test_likePaymentsAreStuck() public {
// Alice and Bob both have profiles and like each other (mutual match).
vm.deal(alice, 1 ether);
vm.deal(bob, 1 ether);
vm.prank(alice); likeRegistry.likeUser{value: 1 ether}(bob);
vm.prank(bob); likeRegistry.likeUser{value: 1 ether}(alice); // triggers matchRewards
​
// Both 1-ETH payments are sitting in LikeRegistry...
assertEq(address(likeRegistry).balance, 2 ether);
​
// ...but userBalances were never credited, so the match pooled 0 into the MultiSig,
// and the owner cannot recover the funds either (totalFees == 0):
vm.prank(owner);
vm.expectRevert("No fees to withdraw");
likeRegistry.withdrawFees();
​
// 2 ETH is permanently locked with no code path able to release it.
assertEq(address(likeRegistry).balance, 2 ether);
}

Expected: on the match, Alice and Bob's pooled likes (2 ETH − 10% = 1.8 ETH) arrive in their shared MultiSig for the date. Actual: the MultiSig gets 0 and the 2 ETH is stuck in LikeRegistry forever.

Recommended Mitigation

Credit each like payment to the payer's balance so it can actually be pooled on a match:

function likeUser(address liked) external payable {
require(msg.value >= 1 ether, "Must send at least 1 ETH");
...
userBalances[msg.sender] += msg.value; // record the payment so it can be pooled/refunded
likes[msg.sender][liked] = true;
...
}

Two follow-on accounting fixes belong with this: matchRewards zeroes a user's entire userBalances, so a user who matches with more than one person loses their balance for later matches — settle per counterparty (or track a per-pair pool) instead of zeroing the whole balance. And decide explicitly what happens to msg.value above the 1-ETH minimum (credit it, or refund the excess) rather than silently absorbing it.

Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge 36 minutes 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!