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

L-01. Fee Calculation Rounding Risk in LikeRegistry Contract

suu

Summary

In LikeRegistry, it contains a potential vulnerability in its matchRewards function where fee calculations could be rounded down to zero due to Solidity's integer division behavior. This occurs when processing small reward amounts, potentially leading to loss of protocol fees.

Vulnerability Details

The vulnerability exists in the following code segment:

uint256 matchingFees = (totalRewards * FIXEDFEE) / 100;

The issue arises because:

  1. FIXEDFEE is set to 10 (representing 10%)

  2. When totalRewards * FIXEDFEE < 100, the division will result in 0

  3. For example, if totalRewards = 9 wei:

    • 9 * 10 = 90

    • 90 / 100 = 0 (rounds down in Solidity)

  4. This means no fees are collected for small transactions

The vulnerability is particularly concerning because:

  • It breaks the expected fee collection mechanism

  • It could be exploited by users intentionally making small transactions

  • There is no minimum threshold check in place

  • The issue affects all matches with total rewards less than 10 wei

Impact

The impact of this vulnerability includes:

  1. Loss of Protocol Revenue

    • Protocol fees are not collected for small transactions

    • Cumulative loss could be significant with many small transactions

  2. Economic Model Disruption

    • Creates an unfair advantage for small transactions

    • Undermines the protocol's fee structure

    • Could incentivize gaming of the system

  3. Trust and Reputation

    • Inconsistent fee collection could affect protocol credibility

    • May require contract upgrade to fix

Tools Used

Manual review

Recommendations

Several solutions are recommended to address this vulnerability:

1. Implement Minimum Threshold

function matchRewards(address from, address to) internal {
uint256 totalRewards = matchUserOne + matchUserTwo;
require(totalRewards >= 100, "Total rewards too small");
// ... rest of the function
}

2. Use Basis Points for Higher Precision

contract LikeRegistry is Ownable {
uint256 immutable FIXEDFEE_BPS = 1000; // 10% in basis points
function matchRewards(address from, address to) internal {
uint256 matchingFees = (totalRewards * FIXEDFEE_BPS) / 10000;
// ... rest of the function
}
}

3. Add Fee Validation

function matchRewards(address from, address to) internal {
uint256 matchingFees = (totalRewards * FIXEDFEE) / 100;
require(matchingFees > 0, "Fee calculation resulted in 0");
// ... rest of the function
}

4. Alternative Fee Structure

Consider implementing a hybrid fee structure:

  • Fixed minimum fee for small transactions

  • Percentage-based fee for larger transactions

Example implementation:

function calculateFees(uint256 amount) internal pure returns (uint256) {
uint256 minimumFee = 1 wei;
uint256 percentageFee = (amount * FIXEDFEE) / 100;
return percentageFee > minimumFee ? percentageFee : minimumFee;
}

These recommendations should be implemented based on the specific requirements of the protocol and its economic model.

Updates

Appeal created

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

Informational or Gas

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood 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.