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 theZapper._l1xReceive
andZapper.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
orfalse
. 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)
withrequire(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.
Last updated