The AaveDIVAWrapper contract implements batch operations for multiple actions (createContingentPool, addLiquidity, etc.) without imposing limits on array sizes. This could lead to a denial of service where transactions consistently fail due to gas limits, especially if the batch size is too large.
Similar patterns exist in:
batchAddLiquidity()
batchRemoveLiquidity()
batchRedeemPositionToken()
batchRedeemWToken()
batchClaimYield()
batchApproveCollateralTokenForAave()
Each iteration in these loops:
Makes external calls to other contracts
Updates state variables
Performs complex operations
Can have significant gas costs
Users could create transactions that will consistently fail by submitting arrays that are too large.
The entire batch operation fails if even a single operation reverts, potentially blocking legitimate operations.
High gas costs could make batch operations impractical for large arrays.
Could lead to degraded user experience if transactions consistently fail due to gas limits.
Manual review
Slither static analyzer
Aderyn static analyzer
1 Implement a maximum array size limit for batch operations:
2 Consider implementing partial success functionality where failed operations don't cause the entire batch to revert.
3 Add events for batch operations to track successes and failures:
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.