The tokenURI
function in the SoulboundProfileNFT
smart contract contains a data type mismatch where a uint8
variable (age
) is being assigned to a uint256
variable (profileAge
). This implicit type conversion results in unnecessary gas consumption due to the increased computational cost of handling a larger data type. While this issue does not impact the contract's core functionality, it introduces inefficiencies that can be optimized for better gas efficiency.
The issue is found in the tokenURI(uint256 tokenId)
function, specifically in the following line:
The age
field in the _profiles
struct is originally declared as uint8
. However, it is being assigned to a uint256
variable, causing an implicit type conversion.
Since uint256
operations consume more gas than uint8
, this conversion leads to unnecessary computational overhead.
Given that age
is stored as uint8
, maintaining consistency in its usage would optimize gas costs.
Increased Gas Costs: Implicit type conversions result in higher gas consumption, making contract interactions more expensive for users.
Inefficient Resource Utilization: Using a larger-than-required data type consumes additional computational resources unnecessarily.
Not a Functional Bug: This issue does not affect the correctness of the contract but leads to avoidable inefficiencies.
Manual Audit – The issue was identified through a manual review of the smart contract code.
Modify the variable profileAge
to use uint8
instead of uint256
to eliminate unnecessary type conversion and optimize gas efficiency:
Maintain data type consistency throughout the contract to prevent implicit conversions.
Use Solidity static analysis tools (e.g., Slither, Mythril) to identify similar inefficiencies and improve contract optimization.
By implementing these optimizations, the SoulboundProfileNFT
contract can achieve better gas efficiency without altering its core functionality.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.