The matchRewards
function in the LikeRegistry
contract introduces a rounding issue when calculating fees and rewards. Solidity’s integer division truncates decimal values, which can result in minor discrepancies that accumulate over multiple transactions. This issue could lead to unintended fund misallocations, where either:
The contract collects slightly less in fees than expected, leading to inconsistencies.
The rewards calculation leads to imbalanced fund distribution.
Loss of Precision: Due to integer division, small amounts of ETH could be misallocated.
Accumulated Discrepancy: Over multiple transactions, these rounding errors could result in an unintended shift of funds.
Potential Inconsistencies: The contract might collect slightly less in fees or allocate incorrect rewards to users.
Set FIXEDFEE = 10
(10% fee).
Assume userBalances[from] = 123
and userBalances[to] = 0
.
The expected fee should be 123 * 10 / 100 = 12.3
, but Solidity rounds this down to 12
, losing 0.3
ETH.
The rewards calculation results in 123 - 12 = 111
instead of 110.7
, leading to an imbalance.
Use a scaling factor (e.g., 1e18
) before performing division to minimize rounding errors:
LOW: While the issue does not completely lock funds, it results in incorrect fund allocation over time.
The rounding issue in matchRewards
leads to minor misallocations of ETH, which can accumulate over multiple transactions. Implementing a scaling factor or proper rounding correction will prevent these inconsistencies and ensure precise calculations.
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.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.