The NFT Dealers protocol includes a metadataFrozen boolean variable that appears designed to lock token metadata after a certain point, preventing changes to NFT URIs. This is a common pattern in NFT collections to ensure metadata immutability.
However, no function in the contract reads or writes this variable. It is declared but never used, making it dead code. This suggests the metadata freezing feature was planned but never implemented, or was left in by mistake during development.
Likelihood:
This affects EVERY deployment - dead code is always present in bytecode
Variable is publicly visible, confusing users about contract functionality
Impact:
Wasted gas on deployment for unused storage slot (~22100 gas for first SSTORE)
Confuses developers and auditors about intended functionality
The following PoC demonstrates that metadataFrozen exists as a public variable but is never modified from its default value of false. No function in the contract reads or writes this variable.
The comprehensive test suite below validates the vulnerability across three scenarios: (1) Variable exists but is never modified from default, (2) Potential intended functionality that was never implemented, (3) Contract size and gas impact of dead code. All tests pass and confirm the vulnerability.
The fix removes the unused metadataFrozen variable entirely since no functionality depends on it. If metadata freezing is desired, it should be properly implemented with freeze function and checks.
Mitigation Explanation: The fix addresses the root cause by: (1) Removing the unused metadataFrozen variable declaration, reducing contract size and deployment costs, (2) Removing any associated getter function bytecode, further reducing contract size, (3) Eliminating confusion for auditors and maintainers about intended functionality, (4) If metadata freezing is actually desired, it should be implemented as a complete feature with freeze function, proper checks in URI-setting functions, and appropriate error handling, (5) Removing dead code is a security best practice that reduces attack surface and improves code maintainability.
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.
The contest is complete and the rewards are being distributed.