ZEUS DEX | SUPPORT
  • Welcome
    • About
      • Introduction
      • Overview
      • Interoperability Challenges
      • Why Choose Zeus DEX?
      • Mission & Vision
      • What Makes Zeus DEX Different?
        • Native and Decentralized
        • The POWER of X-Talk
        • Why ZEUS DEX is Better?
      • Business Model
      • Market Opportunity
      • Security
      • Products & Technology
      • Growth Strategy
      • Tutorials
    • Roadmap
    • Quickstart Guide
    • Token Address List
    • Tokenomics
    • Liquidity Phase
      • ZDX
        • Token Details
        • Introduction
        • Tokenomics
        • Initial Liquidity Phase
          • $ZDX Pools
          • Stable Pools
          • Blue Chip Pools
          • Single Stake Pools
      • SZDX Token
      • Tokens on Zeus
  • Audits
    • Audit Stake Contract
      • Audit - Slither
      • Audit - Mythril
    • Audit Zapper Contract
      • Audit - Slither
      • Audit - Mythril
    • Audit Balancer Contract
      • Audit Report
Powered by GitBook
On this page
  • Security Audit Report for StakeV2Contract using Slither 0.10.3
  • Summary of Findings
  • Low Severity Issues
  • Informational Issues
  • Conclusion
  • Recommendations
  1. Audits
  2. Audit Stake Contract

Audit - Slither

Security Audit Report for StakeV2Contract using Slither 0.10.3

Summary of Findings

The security audit of the StakeV2Contract using Slither 0.10.3 revealed several low-severity and informational issues. These findings primarily relate to code clarity, best practices, and potential edge cases. While no high-severity vulnerabilities were identified, addressing these findings will enhance the overall quality, security, and maintainability of the contract.

Low Severity Issues

1. Shadowing Local Variables (ID-55)

Impact: Low Confidence: High

  • Description: Local variables in the contract shadow state variables with the same name. This can lead to confusion and unintended behavior.

  • Affected Code:

    • TestERC20.constructor(string,string).symbol

    • TestERC20.constructor(string,string).name

  • Recommendation: Rename the local variables to avoid shadowing and improve code clarity.

2. Events-Maths (ID-61)

Impact: Low Confidence: Medium

  • Description: The contract performs state changes that should trigger events but currently do not. Adding events will improve transparency and traceability.

  • Affected Code:

    • setWithdrawalPenaltyPercent(uint256)

    • setMinimumWithdrawalDays(uint256)

  • Recommendation: Emit events after these state changes to ensure that the contract's actions are traceable.

3. Missing Zero-Check (ID-63)

Impact: Low Confidence: Medium

  • Description: Certain functions lack zero-address checks for critical parameters, which could lead to vulnerabilities if a zero address is passed.

  • Affected Code:

    • StakeV2Contract.constructor(string,string,uint256,address,uint256,uint256,uint256)._treasuryContract

    • setTreasuryAddress(address)

  • Recommendation: Add zero-address checks to these functions to prevent assigning critical addresses to the zero address.

Informational Issues

4. Boolean Comparison with Constant (ID-70)

Impact: Informational Confidence: High

  • Description: Several functions perform unnecessary boolean comparisons with constants like true or false, which is redundant.

  • Recommendation: Simplify the boolean checks by removing comparisons with constants. For example, replace require(condition == true) with require(condition).

5. Naming Convention (ID-78)

Impact: Informational Confidence: High

  • Description: Multiple variables and parameters do not follow Solidity's recommended mixedCase naming convention, reducing code readability.

  • Recommendation: Rename the affected variables and parameters to follow the mixedCase naming convention.

Conclusion

The StakeV2Contract audit did not uncover any critical vulnerabilities; however, few low-severity and informational issues were identified that could impact code readability and maintainability. Most of these findings relate to best practices rather than security flaws, with some issues identified as false positives due to protective coding measures already in place.

Recommendations

  • Address the low-severity issues to prevent potential future issues.

  • Adhere to Solidity coding standards to improve code clarity and maintainability.


Disclaimer: This audit is based on the contract code and tools used at the time of the audit. Future updates or changes to the contract could introduce new risks. The audit does not guarantee the absence of vulnerabilities.

PreviousAudit Stake ContractNextAudit - Mythril

Last updated 9 months ago