When adding a new ERC721 to the whitelist on L2, the process always requires traversing to the last active element before adding it. As operational time increases and the whitelist grows, this can lead to significant gas waste. Eventually, it may become difficult or impossible to add new elements due to reaching gas limits.
In the _white_list_collection
function on L2, adding a new ERC721 to the whitelist requires traversing to the last active element. This process is repeated for each new addition, resulting in substantial gas waste. As the whitelist expands, there's an increasing risk of hitting gas limits, potentially causing function execution failures.
Excessive Gas Consumption: Each addition operation becomes increasingly expensive as the list grows.
Scalability Issues: The system's ability to add new ERC721 contracts becomes limited over time.
Potential Denial of Service (DoS): As gas costs escalate, it may become economically infeasible or technically impossible to add new elements, effectively creating a DoS condition for whitelist management.
User Experience Degradation: Higher costs and potential failures in whitelist additions can negatively impact user and admin experiences.
Economic Inefficiency: The increasing cost of operations may affect the economic model of the protocol, potentially leading to higher fees for users or reduced profitability for the protocol.
Manual Review
Implement a 'tail' variable: Maintain a variable that always points to the last active element in the whitelist. This allows for O(1) time complexity when adding new elements.
Likelyhood: High, once the whitelist option is disabled, collections will grow. Impact: High, withdraw won’t be possible because of Out-Of-Gas.
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.