The vulnerability stems from the calculation in the buyout function where the final amount is computed as:
Due to Solidity’s use of integer division, any remainder is truncated. This can result in slight underpayment (or overcharging in a different context) when the NFT’s value isn’t perfectly divisible by the number of beneficiaries. Although not catastrophic on its own, this issue may cause economic discrepancies in asset distribution if exploited or if beneficiary counts are misconfigured.
Calculation: The expression (value / divisor) * multiplier
uses integer division. For example, with a value of 101 and 3 beneficiaries, the computation yields:
101 / 3 = 33
(remainder 2 discarded)
33 * 2 = 66
The “ideal” precise calculation would be approximately 67.33, but since only integers are considered, the result is truncated to 66.
Affected Function: buyOutEstateNFT
uses this calculation, which may lead to beneficiaries receiving slightly less than intended or, in another design context, could result in overcharging.
Context: While rounding errors are expected in integer arithmetic, if the parameters (NFT value, beneficiary count) are under the control of a malicious party, the vulnerability could be manipulated to cause systematic discrepancies in fund transfers.
The root cause is the inherent behavior of Solidity’s integer arithmetic: division truncates any fractional component. This is compounded by the use of the formula without any adjustments or rounding compensation. Additionally, if beneficiary counts are not validated or updated correctly, it further amplifies the risk of miscalculation.
Economic Impact: Slight underpayment or overcharging may accumulate over multiple transactions or high-value NFTs, leading to significant loss or disputes between parties.
User Trust: Incorrect fund distribution can reduce trust in the protocol’s fairness, potentially affecting adoption.
Static Analysis: Manual code review to inspect arithmetic operations and beneficiary count management.
Rounding Compensation: Modify the calculation to account for rounding errors. One approach could be to use a higher precision arithmetic library or adjust the calculation by adding a correction factor based on the remainder.
Validation Checks: Validate that the beneficiary count is correct and consider including additional checks to ensure that any remainder is distributed fairly or logged for manual reconciliation.
Documentation & User Alerts: Clearly document this behavior so that users understand the limitations of integer arithmetic in the protocol. Optionally, notify users if a significant rounding discrepancy is detected.
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.