Introduction
We express our gratitude to the SquidGrow team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
SquidGrow's Ecosystem has multiple products including a DEX, NFT Marketplace, & Liquidity Locker. Ecosystem supports Ethereum, & Binance Smart Chain.
Document
- Name
- Smart Contract Code Review and Security Analysis Report for SquidGrow
- Audited By
- Kornel Światłowski
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://www.squidgrow.com/→
- Changelog
- 30/08/2024 - Preliminary Report; 03/09/2024 - Final Report
- Platform
- Ethereum, BSC
- Language
- Solidity
- Tags
- LiqudityLocker
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope
- Commit
- 0f0f9f748515b896a1a1bbea04e7ff69e0a570a0
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are present, but only in a limited capacity.
Technical description is not provided.
Code quality
Insufficient Gas modeling.
The development environment is configured.
Test coverage
Code coverage of the project is 48.68% (branch coverage).
Negative cases coverage is missing.
Some functions are not covered with test.
System Overview
The KnoxLocker V2 contract is a liquidity management and token locking mechanism designed to securely hold and manage liquidity pool (LP) tokens on behalf of an admin. It allows the admin to lock LP tokens for a specified period, with options to incrementally add more tokens or extend the lock duration. The contract also facilitates the addition or removal of ETH and tokens from the liquidity pool, ensuring seamless liquidity adjustments. Additionally, it includes emergency withdrawal functions for both ETH and other tokens, providing a safeguard in critical situations. The contract is governed by an access control system, restricting critical operations to the DEFAULT_ADMIN_ROLE.
Privileged roles
The KnoxLocker V2 contract has several functions controlled by a privileged role, the DEFAULT_ADMIN_ROLE. This role is granted to the deployer of the contract upon deployment and can be extended to other addresses if necessary. Here's an overview of the privileged roles and their corresponding actions:
Lock a specified amount of liquidity tokens (LP tokens) until a defined unlock time.
Increase the amount of locked tokens or extend the unlock time if the lock is still active.
Withdraw the locked tokens once the unlock time has passed.
Relock the tokens with a new unlock time after the previous lock has expired.
Add ETH to the liquidity pool by adjusting the existing liquidity.
Remove ETH from the liquidity pool by adjusting the existing liquidity.
Add more tokens to the liquidity pool.
Remove tokens from the liquidity pool by adjusting the existing liquidity.
Withdraw any other ERC-20 tokens from the contract, excluding the LP tokens.
Withdraw ETH from the contract in case of emergencies.
Risks
Interactions with External DeFi Protocols: Dependence on external DeFi protocols inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols are exploited, indirectly affecting the audited project.
Coarse-grained Authorization Model Risks: The broad authorization model increases the risk of protocol control loss if any authorized address is compromised, potentially leading to unauthorized actions and significant financial loss.
Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
F-2024-5623 | The removeEth() Allows Withdrawal of Locked LP Tokens Before Unlock Time | Fixed | Medium | |
F-2024-5621 | The lock.amount Value Is Not Updated In removeEth() and removeTokens() | Fixed | Medium | |
F-2024-5625 | Absence of Withdrawal Validation in lockLpTokens() Function May Lead to Locked LP Tokens | Fixed | Low | |
F-2024-5624 | The relockTokens() Allows Relocking Before Lock Expiration | Fixed | Observation | |
F-2024-5618 | Unchecked Return Value of approve Function | Accepted | Observation | |
F-2024-5617 | Use of transfer() Instead of call() to Send Native Tokens | Accepted | Observation | |
F-2024-5616 | Assignment of Default Value to Variables Increases Gas Consumption | Accepted | Observation | |
F-2024-5615 | Missing Checks for Zero Address | Accepted | Observation | |
F-2024-5614 | Gas Inefficiency Due to Missing Usage of Solidity Custom Errors | Accepted | Observation | |
F-2024-5613 | Floating Pragma | Accepted | Observation |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details
- Commit
- 0f0f9f748515b896a1a1bbea04e7ff69e0a570a0
- Whitepaper
- -
- Requirements
- -
- Technical Requirements
- -
Contracts in Scope
contracts/SamLocker.sol