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

`userBalances` never credited in `likeUser` — all match rewards are zero and all ETH is permanently locked

web3mio

Root + Impact

Description

`likeUser` is a `payable` function that requires at least 1 ETH per call. The intent is for each user's payment to be tracked in `userBalances` so that `matchRewards` can later distribute the combined pot to the matched pair's MultiSig wallet. However, `likeUser` never writes to `userBalances`:
```
```solidity
function likeUser(address liked) external payable {
require(msg.value >= 1 ether, "Must send at least 1 ETH");
// userBalances[msg.sender] += msg.value <-- missing
require(!likes[msg.sender][liked], "Already liked");
// ...
likes[msg.sender][liked] = true;
​
if (likes[liked][msg.sender]) {
matchRewards(liked, msg.sender); // reads balances that were never written
}
}
```
​
`matchRewards` then reads both balances and finds zero:
​
```solidity
function matchRewards(address from, address to) internal {
uint256 matchUserOne = userBalances[from]; // 0
uint256 matchUserTwo = userBalances[to]; // 0
​
uint256 totalRewards = matchUserOne + matchUserTwo; // 0
uint256 matchingFees = (totalRewards * FIXEDFEE) / 100; // 0
uint256 rewards = totalRewards - matchingFees; // 0
totalFees += matchingFees; // += 0, totalFees stays 0
​
MultiSigWallet multiSigWallet = new MultiSigWallet(from, to);
(bool success,) = payable(address(multiSigWallet)).call{value: rewards}(""); // call{value: 0}
require(success, "Transfer failed");
}
```
Three consequences compound to make this irrecoverable:
​
1. **Matched users receive nothing.** `rewards = 0` — the deployed MultiSig receives 0 ETH regardless of how much both users paid.
​
2. **All ETH is permanently stuck in `LikeRegistry`.** Both payments (≥ 2 ETH per match) remain in the contract balance. There is no `emergencyWithdraw`, no refund function, and no other path for user funds to exit.
​
3. **`withdrawFees` is also permanently bricked.** `totalFees` is only incremented by `matchingFees`, which is always 0. `withdrawFees` guards on `require(totalFees > 0)` — this check never passes, so even the owner cannot recover the stuck ETH via the intended admin path.
​
> **Note on the `0/100` panic claim:** An earlier audit comment suggested `0/100` causes a Solidity panic and makes `likeUser` revert. This is incorrect. Solidity panics on division *by* zero (denominator = 0). The denominator here is `100`, a constant that is never zero. `0 / 100 = 0` evaluates without error and `likeUser` completes normally — making the silent fund lock even more dangerous, as neither user receives an error indicating their ETH is gone.

Risk

Likelihood:

  • All ETH is permanently stuck in `LikeRegistry

Impact:

Every mutual like in the protocol results in total loss of both users' ETH. Funds accumulate in `LikeRegistry` indefinitely with no on-chain recovery mechanism. The entire economic incentive of the matching system — rewarding successful matches — is non-functional from the first deployment block.

Proof of Concept

**PoC 1 — ETH permanently stuck:** `testPoC_UserBalancesNeverUpdated_ETHPermanentlyStuck` in `test/testLikeRegistry.t.sol`
​
```
[PASS] testPoC_UserBalancesNeverUpdated_ETHPermanentlyStuck() (gas: 1,105,342)
​
Flow:
alice likeUser(bob) {value: 1 ETH} -> userBalances[alice] = 0 (never written)
bob likeUser(alice){value: 1 ETH} -> userBalances[bob] = 0 (never written)
matchRewards fires
rewards = 0, MultiSig receives 0 ETH
LikeRegistry.balance = 2 ETH (stuck)
withdrawFees() -> revert "No fees to withdraw" (totalFees == 0)
```
​
**PoC 2 — No panic, silent failure:** `testPoC_MutualLikeDoesNotRevert` in `test/testLikeRegistry.t.sol`
​
```solidity
// PoC: userBalances is never updated in likeUser.
// When a mutual like triggers matchRewards, both balances read as 0.
// rewards = 0 — the MultiSig receives nothing.
// All ETH sent by both users is permanently stuck in LikeRegistry
// with no recovery path (withdrawFees also reverts because totalFees == 0).
function testPoC_UserBalancesNeverUpdated_ETHPermanentlyStuck() public {
// Step 1: Alice likes Bob, sends 1 ETH
vm.prank(alice);
likeRegistry.likeUser{value: 1 ether}(bob);
​
// Step 2: Bob likes Alice, sends 1 ETH — mutual like fires matchRewards
vm.prank(bob);
likeRegistry.likeUser{value: 1 ether}(alice);
​
// LikeRegistry holds both ETH payments
uint256 registryBalance = address(likeRegistry).balance;
assertEq(registryBalance, 2 ether, "LikeRegistry holds 2 ETH from both likers");
​
// matchRewards reads userBalances[alice] and userBalances[bob] — both are 0
// because likeUser never wrote to userBalances
assertEq(likeRegistry.userBalances(alice), 0, "alice balance never written");
assertEq(likeRegistry.userBalances(bob), 0, "bob balance never written");
​
// The MultiSig for the matched pair was deployed — find it by replaying the deploy
// (we check its balance indirectly: registry kept all the ETH)
// rewards = 0, so the MultiSig received 0 ETH
// Verify: total ETH in system = registry (2 ETH) + multiSig (0 ETH)
// If rewards were correct, registry should hold only fees (~0.2 ETH) and multiSig ~1.8 ETH
​
// Step 3: withdrawFees reverts — totalFees == 0 because matchingFees was 0/100 = 0
vm.prank(address(this)); // owner is the test contract
vm.expectRevert("No fees to withdraw");
likeRegistry.withdrawFees();
​
// Conclusion: 2 ETH is permanently locked in LikeRegistry.
// There is no other function that can move it out.
assertEq(address(likeRegistry).balance, 2 ether, "2 ETH permanently stuck - confirmed");
}
```
​
```
[PASS] testPoC_MutualLikeDoesNotRevert() (gas: 1,100,237)
​
Flow:
Mutual like completes without revert — 0/100 = 0, no panic.
Match is recorded, ETH is silently lost.
```
​
Run with: `forge test --match-contract LikeRegistryTest -vvv`

Recommended Mitigation

Credit each sender's payment to `userBalances` immediately on receipt, before any other logic:
​
```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");
​
userBalances[msg.sender] += msg.value; // add this line
​
likes[msg.sender][liked] = true;
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);
}
}
```
​
With this fix, `matchRewards` reads the correct balances, `rewards` reflects both payments minus the 10% fee, and `totalFees` accumulates correctly for `withdrawFees`.
Updates

Lead Judging Commences

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