Internal view functions should follow a consistent return mechanism—either using Solidity’s implicit return variables or using a unified assembly pattern that writes to the free memory pointer and returns from there. Consistency improves readability, maintainability, and reduces subtle ABI/memory handling mistakes.
In this codebase, different internal view functions use different return strategies:
totalSupply_() writes into scratch space (0x00) and returns from it.
_balanceOf(address) allocates ptr := mload(0x40), writes the value there, then returns (ptr, 0x20), but also performs an unnecessary extra mstore(add(ptr, 0x20), 0).
_allowance(address,address) relies on Solidity’s implicit return variable (remaining) rather than a manual return(ptr, 0x20) block.
Likelihood: Low
This module is assembly-heavy and likely to be modified in the future. Mixed patterns make refactors and audits harder, and new contributors can inadvertently break memory hygiene or ABI assumptions.
Integrations frequently call these functions; any subtle change in return behavior can surface as silent incompatibilities or hard-to-debug issues.
Impact: Low
Maintainability & correctness risk: Inconsistent patterns can lead to mistakes when adding features (e.g., event additions, extra checks), potentially causing silent bugs (wrong offsets, clobbered scratch space).
Audit complexity / time: Auditors and maintainers must reason about three patterns instead of one, increasing the chance of missing edge cases.
Unify all internal view functions to one consistent return style - prefer using the free memory pointer and an explicit return(ptr, 0x20) (option 1).
Or use Solidity implicit returns everywhere (option 2).
Also avoid scratch-space writes and remove unnecessary memory operations.
Option 1:
Option 2:
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.