getUserMemorabiliaDetailed iterates a nested double loop over every collection (cId from 1 to nextCollectionId) and every item (iId from 1 to currentItemId) twice, once to count and once to populate (FestivalPass.sol:269-275 and 284-294). The total work grows with collections multiplied by items per collection, with no pagination or bound.
Likelihood:
High over the lifetime of a successful festival. Each createMemorabiliaCollection raises nextCollectionId and each redemption raises a collection's currentItemId, so the iteration space only ever grows and the cost is unbounded by design.
Impact:
Low. This is a view function, so it cannot corrupt state or lose funds. The harm is availability and cost: once collections and editions accumulate, the doubled balanceOf calls exceed the eth_call gas cap, and the function reverts when called on-chain (for example from another contract) and becomes slow and expensive to query off-chain, degrading any UI that depends on it.
After many collections and editions, calling the view exceeds the node gas limit and reverts.
Track per-user token ownership in a mapping, or paginate the query with start/limit parameters.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.