DatingDapp
First Flight #33
Beginner FriendlyFoundrySolidityNFT
100 EXP
View results
Previous Next
Submission Details
Severity: low
Invalid

Incorrect ETH Handling in `LikeRegistry::likeUser`, could mislead participant and cause loss of funds

summer

Description:

The LikeRegistry::likeUser function uses require(msg.value >= 1 ether), allowing users to overpay. Excess ETH is neither refunded nor tracked.

According to the documentation, the protocol expects exactly 1 ETH per like, but overpayments create accounting discrepancies.

Impact:

Users can lose ETH by sending more than 1 ether. Protocol revenue calculations and reward distributions are inaccurate.

Proof of Concept: modify the test imports and setup and include this test below, run with -vvv, Verifies that overpayments are locked in the contract.

  • Simulates user sending 1.5 ETH (instead of 1 ETH) to like user2.

  • Checks the balance of the LikeRegistry contract.
    The contract holds 1.5 ETH, proving that overpayments are not refunded.

Test
// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;
​
import "../src/LikeRegistry.sol";
import "../src/MultiSig.sol";
contract SoulboundProfileNFTTest is Test {
LikeRegistry likeRegistry; // Declare LikeRegistry variable
uint256 constant LIKE_FEE = 1 ether; // constant to track likeFee
​
function setUp() public {
soulboundNFT = new SoulboundProfileNFT();
likeRegistry = new LikeRegistry(address(soulboundNFT)); // initialize likeRegistry
// Setup profiles for like tests
vm.prank(user);
soulboundNFT.mintProfile("Alice", 25, "ipfs://alice");
vm.prank(user2);
soulboundNFT.mintProfile("Bob", 28, "ipfs://bob");
}
​
// Incorrect ETH Handling
function testOverpaymentLocksETH() public {
vm.prank(user);
likeRegistry.likeUser{value: 1.5 ether}(user2);
// Check contract balance
assertEq(address(likeRegistry).balance, 1.5 ether, "Overpaid ETH is locked");
}
}

Recommended Mitigation:

Add a refund mechanism or cap payment at exactly 1 ETH

Reccomendation
require(msg.value == 1 ether, "Exactly 1 ETH required");
Updates

Appeal created

n0kto Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Users mistake, only impacting themselves.

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Support

FAQs

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