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

Users' ETH permanently locked — likeUser() accepts payment but never writes to userBalances

cybervikink

Root + Impact

Normal behavior

When a user calls likeUser(), they send 1 ETH as a "stake" representing genuine interest. If the like is mutual, matchRewards() is called, which reads both users' balances from userBalances, zeroes them out, takes a 10% fee, and forwards the remaining ETH to a newly deployed MultiSigWallet that both matched users control.

Description

The issue

likeUser() accepts msg.value and stores the like flag, but never writes msg.value into userBalances[msg.sender]. As a result, every call to matchRewards() reads userBalances[from] == 0 and userBalances[to] == 0. The total rewards computed is 0 wei. The MultiSig is deployed and funded with nothing. Both users' ETH remains trapped in LikeRegistry forever, with no user-facing withdrawal function to recover it.

// LikeRegistry.sol — likeUser()
​
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);
​
// @> msg.value is received here — but userBalances[msg.sender] is NEVER updated.
// @> The ETH sits in the contract balance with no accounting entry for this user.
​
if (likes[liked][msg.sender]) {
matches[msg.sender].push(liked);
matches[liked].push(msg.sender);
emit Matched(msg.sender, liked);
matchRewards(liked, msg.sender); // @> reads userBalances — both are 0
}
}
​
function matchRewards(address from, address to) internal {
uint256 matchUserOne = userBalances[from]; // @> == 0
uint256 matchUserTwo = userBalances[to]; // @> == 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;
​
MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);
(bool success,) = payable(address(multiSigWallet)).call{value: rewards}(""); // @> sends 0 wei
require(success, "Transfer failed");
}

Risk

Likelihood:

  • Every single likeUser() call is affected — this is the core user flow, not an edge case. Any user who sends ETH and gets matched will lose their funds.

  • No special conditions are required. The bug triggers on every mutual match, 100% of the time.

Impact:

  • All ETH sent via likeUser() accumulates in the LikeRegistry contract balance with zero accounting, making it unrecoverable by users.

  • Matched couples receive a 0-wei MultiSig wallet instead of their pooled date fund.

  • The withdrawFees() function only withdraws totalFees, which is also 0 — so even the owner cannot rescue the locked ETH.

  • Protocol is economically non-functional from block 1 of deployment.

Proof of Concept

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
​
import "forge-std/Test.sol";
import "../src/LikeRegistry.sol";
import "../src/SoulboundProfileNFT.sol";
​
contract MissingBalanceCreditTest is Test {
LikeRegistry registry;
SoulboundProfileNFT nft;
​
address alice = makeAddr("alice");
address bob = makeAddr("bob");
​
function setUp() public {
nft = new SoulboundProfileNFT();
registry = new LikeRegistry(address(nft));
​
vm.prank(alice);
nft.mintProfile("Alice", 25, "ipfs://alice");
​
vm.prank(bob);
nft.mintProfile("Bob", 27, "ipfs://bob");
​
deal(alice, 2 ether);
deal(bob, 2 ether);
}
​
function test_ethLockedOnMatch() public {
// Alice likes Bob
vm.prank(alice);
registry.likeUser{value: 1 ether}(bob);
​
// Bob likes Alice back — triggers matchRewards()
vm.prank(bob);
registry.likeUser{value: 1 ether}(bob); // mutual match
​
// 2 ETH is now sitting in LikeRegistry with no way out
assertEq(address(registry).balance, 2 ether, "ETH trapped in registry");
​
// userBalances were never written, so matchRewards sent 0 to MultiSig
assertEq(registry.userBalances(alice), 0);
assertEq(registry.userBalances(bob), 0);
}
}

Recommended Mitigation

Add userBalances[msg.sender] += msg.value; immediately after the validation checks in likeUser(), before the mutual-like check:

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; // @> ADD THIS LINE
​
emit Liked(msg.sender, liked);
​
if (likes[liked][msg.sender]) {
matches[msg.sender].push(liked);
matches[liked].push(msg.sender);
emit Matched(msg.sender, liked);
matchRewards(liked, msg.sender);
}
}
Updates

Lead Judging Commences

ai-first-flight-judge Lead Judge about 1 hour 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!