Inconsistent Storage Naming Convention (Unclear State Variables + Maintainability Impact)
Description:
The contract does not follow a clear naming convention to distinguish storage variables from local or memory variables.
Using generic names such as owner may reduce clarity in larger contracts, especially when local variables or parameters share similar names.
Impact:
Makes it harder to visually distinguish storage variables from function parameters.
Increases risk of shadowing or accidental misuse.
Reduces consistency and professional code standards.
Slightly increases review and audit complexity.
While not a direct security issue, consistent naming significantly improves maintainability and reduces human error risk.
Recommended Mitigation:
Adopt a clear naming convention for storage variables, such as prefixing with s_:
Or use uppercase for immutable/constants where appropriate:
Additionally, update references across the contract:
This enhances readability and aligns with best practices in Solidity development.
Description:
StrataxOracle::setPriceFeeds validates array length equality, but does not reject empty arrays. This allows no-op calls that waste gas and may create misleading “successful” transactions.
Impact:
Allows meaningless transactions (no updates performed).
Wastes gas and can confuse integrators/ops tooling.
Inconsistent input validation (length match is checked, but emptiness is not).
Proof of Concept:
Calling:
passes the current require, but does not update anything.
Recommended Mitigation:
Add an explicit empty check before the length equality check (and prefer custom errors if already adopted):
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.