MyCut

Severity: L · Impact: L · Likelihood: H

Description

• claimCut rejects callers with no allocation using if (reward <= 0).

• reward is a uint256, which can never be negative, so <= 0 is equivalent to == 0. The comparison is misleading (implies a signed value / a "negative reward" case that cannot exist) and wastes a comparison.

Risk

Likelihood

• High: the line executes on every claimCut call.

Impact

• Low / informational: no fund or availability impact — purely code correctness and clarity (a reader may wrongly assume signed semantics).

Proof of Concept

Static: playersToRewards is mapping(address => uint256), so reward is always >= 0; the <= 0 branch is reachable only when reward == 0. There is no input for which <= 0 differs from == 0.

Recommended Mitigation

Use the exact, intent-revealing comparison for an unsigned value.

Why: == 0 states the actual condition for a uint256 and removes the false implication of a signed/negative case.