While these issues do not directly affect protocol security, inconsistent naming makes the codebase harder to audit, reason about, and maintain. This increases the likelihood of future developer mistakes and overlooked bugs.
Likelihood:
Reason 1
This occurs during normal development and auditing workflows whenever developers or auditors run forge lint or review the codebase, as the variable naming conventions are consistently violated across multiple contracts.
Reason 2
The issue is present in deployed source code and test files, meaning it will repeatedly surface during maintenance, refactoring, onboarding of new contributors, or CI checks.
Impact:
Impact 1
Reduced readability and consistency across the codebase makes auditing more difficult and increases the chance of human error during future development or security reviews.
Impact 2
Failure to follow established Solidity and Foundry conventions can lead to overlooked logic issues, weaker code quality standards, and difficulty enforcing automated linting or CI rules.
The issue can be consistently reproduced by running Foundry’s linting tool against the repository. Foundry flags multiple variable naming violations and unsafe cheatcode usage, demonstrating that the codebase does not conform to recommended Solidity conventions.
To resolve these issues and improve overall code quality, variable names should be updated to follow Solidity and Foundry naming conventions. Mutable state variables should use mixedCase, while immutable variables should use SCREAMING_SNAKE_CASE.
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.