[L-01] Protocol lacks spamming protection

Severity

Impact: Low

Likelihood: Low

Description

Both the Lottery and Auction contracts maintain the participants in the participants[] list. This list can easily be overwhelmed by spam. An attacker could deposit 1 wei using the deposit() function to significantly increase the size of the participants[] list.

function deposit(uint256 amount) public payable lotteryStarted {
    require(usdcContractAddr != address(0), "USDC contract address not set");
    require(amount > 0, "No funds sent");
    require(
        IERC20(usdcContractAddr).allowance(_msgSender(), address(this)) >= amount,
        "Insufficient allowance"
    );

    IERC20(usdcContractAddr).transferFrom(_msgSender(), address(this), amount);

    // @audit Deposit 1 wei is accepted
    if (deposits[_msgSender()] == 0) {
        participants.push(_msgSender());
    }
    deposits[_msgSender()] += amount;
}

Several logic functions in the contract loop through the entire participants[] list. If an attacker spams the list to make it excessively large, the gas consumption for looping through the list could exceed the gas limit and revert the transaction. Consequently, this could result in a Denial of Service (DOS) on the functionality.

For instance, the checkEligibleParticipants() function could constantly revert, preventing the seller from proceeding with the sale. Function transferNonWinnerDeposits() in LotteryV2Base also loops through participants[] list and has the same issue. Similar with function isParticipant().

Recommendations

Consider implementing a check to ensure users deposit at least a minimumDepositAmount. This could help mitigate the risk of spamming.

CDSecurity / Blessed-minhquanym