In the redeemMemorabilia() function, the MemorabiliaCollection struct is loaded into storage:
solidity
The function then reads several fields (priceInBeat, isActive, maxSupply, currentItemId) and performs one write (currentItemId++).
While using storage is correct and necessary for the increment operation, the multiple reads from storage are expensive. Each SLOAD operation costs significant gas.
A common gas optimization pattern is to copy the struct to memory, perform all reads from memory, and only write back the modified field (currentItemId) at the end.
This reduces the number of SLOADs from multiple to just one or two, saving gas on every redemption.
Low severity / Gas optimization: No security risk, no functional bug.
Gas savings: Approximately 2–4 extra SLOADs are avoided per call (each ~2,100 gas in post-London EIP-2929 pricing).
User impact: Higher gas fees for redeeming memorabilia NFTs — noticeable in high-volume collections.
Scalability: As the protocol grows and memorabilia redemptions become frequent, cumulative gas waste adds up.
Classified as Low / Gas / QA per CodeHawks guidelines.
Current vulnerable pattern:
solidity
Optimized pattern:
solidity
Estimated savings per call: ~4,000–6,000 gas (depending on access list warm/cold status).
Refactor to use memory for reads and minimize storage access:
solidity
Note: Since currentItemId starts at 1, itemId is correct as the edition number.
Alternative (even cleaner):
solidity
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.