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 Zapper Contract using Slither 0.10.3
  • Summary of Findings
  • Low Severity Issues
  • Informational Issues
  • Conclusion
  • Recommendations
  1. Audits
  2. Audit Zapper Contract

Audit - Slither

Security Audit Report for Zapper Contract using Slither 0.10.3

Summary of Findings

The security audit of the Zapper contract revealed a range of issues, all of which are classified as low severity or informational. These issues include potential vulnerabilities related to shadowing variables, missing zero-address checks, and code clarity concerns like boolean comparisons with constants and naming conventions. The following report details these findings and provides recommendations for remediation.

Low Severity Issues

1. Shadowing Local Variables (ID-55)

Impact: Low Confidence: High

  • Description: The local variable _status in the Zapper._l1xReceive and Zapper.updateAdmin functions shadows a state variable of the same name. Shadowing can lead to unexpected behavior and makes the code harder to understand.

  • Affected Code:

    • Zapper._l1xReceive(bytes32,bytes)._status

    • Zapper.updateAdmin(address,bool)._status

  • Recommendation: Rename the local variables to avoid shadowing and potential confusion. This will improve code clarity and prevent unintended interactions with state variables.

2. Missing Zero-Check (ID-63)

Impact: Low Confidence: Medium

  • Description: Several functions in the Zapper contract lack zero-address checks for critical parameters. Assigning a zero address to variables such as _receiverAddress or _treasuryAddress can lead to potential vulnerabilities or unexpected contract behavior.

  • Affected Code:

    • Zapper._l1xReceive: Lacks a zero-check on _receiverAddress.

    • Zapper.setTreasuryAddress: Lacks a zero-check on _treasuryAddress.

    • Zapper.constructor: Lacks a zero-check on _treasuryAddress.

  • Recommendation: Add zero-checks (require(_address != address(0), "Invalid address");) to these functions to ensure that critical addresses are not set to the zero address. This will prevent the contract from interacting with non-existent addresses.

Informational Issues

3. Boolean Comparison with Constant (ID-70)

Impact: Informational Confidence: High

  • Description: Several functions in the Zapper contract perform unnecessary boolean comparisons with constants such as true or false. This is redundant and could be simplified.

  • Affected Code:

    • require(_status == true || (_status == false && zapInitiated[_internalId].sourceAmount != 0), "Invalid X-Talk execution");

    • require(admins[msg.sender] == true, "Not Authorized Admin");

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

4. Naming Convention (ID-78)

Impact: Informational Confidence: High

  • Description: Multiple parameters, variables, and functions in the Zapper contract do not adhere to Solidity's recommended mixedCase naming convention. This can reduce code readability and increase the likelihood of errors.

  • Recommendation: Rename the affected variables, parameters, and functions to follow the mixedCase naming convention. This will enhance code readability and maintain consistency across the codebase.

Conclusion

The Zapper contract does not contain high-severity issues but does have few low-severity and informational issues related to code clarity, naming conventions, and best practices. Addressing these issues will improve the overall quality, security, and maintainability of the contract.

Recommendations

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

  • Follow best practices for 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 Zapper ContractNextAudit - Mythril

Last updated 9 months ago