Normally, _getWinnerShares() should efficiently determine the winner’s reward based on stored participant data without risking execution failure.
However, the current implementation loops over all participants in the array, which grows indefinitely as more users join. This creates an unbounded gas cost, making the function potentially unusable once the participant list becomes large.
Likelihood:
Very likely to occur as soon as the number of participants grows beyond the gas limit per transaction.
The issue compounds with time as the list accumulates entries from repeated deposits or events.
Impact:
Any function calling _getWinnerShares() may become unexecutable, halting key operations like reward distribution or event closure.
The contract may effectively “brick” if _getWinnerShares() is required for payouts or accounting.
Observed Effect:
When joinMany(10000) is called, the calculate() function fails due to out-of-gas errors during execution.
**Explanation: **Instead of recalculating the total each time, maintain a running counter (totalDepositedShares) updated during deposits and withdrawals. This approach makes _getWinnerShares() an O(1) operation, eliminating the risk of gas exhaustion.
The _getWinnerShares() function is intended to iterate through all users and sum their shares for the winning country, returning the total.
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.