Canto Liquidity Mining Protocol - invitedtea's results

Canto audit analysis

• by InvitedTea | @invitedTea | Vicky@Keybox.ai

Project Description

Canto's New Liquidity Mining Feature

Canto is introducing a new liquidity mining feature tailored for Ambient Finance. This feature will be realized via a sidecar contract that interacts with Ambient through their proxy contract design.

Key Components:

1. New Contracts:

• LiquidityMiningPath.sol: Allows users to interface with the contract.
• LiquidityMining.sol: Contains all necessary logic.

2. Purpose of LiquidityMining Sidecar:

The sidecar is fashioned to implement a liquidity mining protocol for Ambient. Canto's objective is to utilize this sidecar to boost liquidity for Ambient pools hosted on Canto.

3. Incentive Mechanism:

The LiquidityMining sidecar emphasizes a specific liquidity range determined by the current tick. To be eligible for incentives, users need to offer liquidity over a span of at least 21 ticks, encompassing the current tick and an extra 10 on both sides.

4. Liquidity Mining Rewards:

• The sidecar diligently tracks time-weighted liquidity on a global and per-user scale for both ambient & concentrated positions.
• This system enables the protocol to ascertain a user's contribution and duly reward them.
• As an illustration, if only a single provider furnishes liquidity for an entire week, they are entitled to the full reward of that week.

5. Implementation:

The central codebase pivotal for claiming and accruing rewards is housed in LiquidityMining.sol. Setting the weekly reward rate for the sidecar is imperative, and the authority to determine the reward rate duration lies with governance.

In its entirety, this innovative feature assures that liquidity providers are duly compensated in alignment with their contributions.

The key contracts of the protocol for this Audit are:

• LiquidityMiningPath:

The LiquidityMiningPath.sol contract appears to be a proxy sidecar contract associated with CANTO liquidity mining. It's designed to move code outside the main contract to avoid Ethereum's contract code size limit. The contract should never be called directly or externally and is intended to be invoked with DELEGATECALL to operate on the state within the primary contract. It includes components related to CANTO liquidity mining and references several imported libraries.

• LiquidityMining.sol:

The LiquidityMining.sol contract centers on the functionalities of liquidity mining, particularly related to the claiming aspect. Operating as a mixin, it encompasses functions that delineate the intricacies of liquidity mining, such as initializing tick tracking and monitoring tick transitions. This contract incorporates various imported libraries and is an extension of the PositionRegistrar contract.

Approach

During the analysis, we focused on thoroughly understanding the codebase and providing recommendations to improve its functionality.

Smart Contract Auditing Plan

1. Introduction

Before deploying a smart contract, it is imperative to conduct a thorough audit to ensure security and functionality. This plan outlines the steps and methodologies employed during the auditing process.

2. Preliminary Review

• 2.1. Documentation Review: Examine any provided documentation, understanding the intended behavior of the contract.
• 2.2. Codebase Familiarization: Browse through the contract's codebase to get a general understanding of its structure and components.

3. Static Analysis

• 3.1. Manual Code Review: Manually inspect the code to identify potential vulnerabilities, logic flaws, or inefficiencies.
• 3.2. Automated Tools: Utilize tools like Mythril, Slither, or Oyente to automatically detect common vulnerabilities.

4. Dynamic Analysis

• 4.1. Unit Testing: Ensure all unit tests provided with the contract pass. Identify any missing critical test cases.
• 4.2. Test Coverage: Use tools like Solidity Coverage to ascertain the percentage of code covered by tests.
• 4.3. Simulation: Simulate contract interaction in a controlled environment to observe its behavior.

5. Gas Usage Analysis

Evaluate the contract's operations for excessive gas consumption. Optimizations should be suggested for any gas inefficiencies detected.

6. Logical Checks

• 6.1. Access Control: Confirm that only authorized entities can access specific functions.
• 6.2. Arithmetic Operations: Ensure no possibilities of overflow, underflow, or division by zero.
• 6.3. Business Logic Validity: Check that the contract's logic aligns with its intended purpose and specifications.

7. Security Checks

• 7.1. Reentrancy Attacks: Verify that the contract is not vulnerable to reentrancy attacks.
• 7.2. Timestamp Dependency: Check for reliance on block timestamps and potential manipulation.
• 7.3. Contract Upgradability: If the contract is upgradeable, ensure secure methods are employed.
• 7.4. External Calls: Confirm that external calls are handled securely, preventing malicious contract interactions.

8. Concurrency

Examine the contract for potential race conditions, particularly in areas where multiple transactions can interact.

9. Final Review

• 9.1. Code Quality: Ensure the code is well-commented, organized, and adheres to best practices.
• 9.2. Redundancy: Check for any redundant code or logic that can be optimized.

General Audit Practices:

• Gas Optimization: Ensure that the contracts are optimized for gas usage.
• Reentrancy Checks: Verify that functions are safe from reentrancy attacks.
• Overflow & Underflow: Check for potential integer overflow or underflow vulnerabilities.
• Access Control: Ensure only authorized entities can access specific functions.
• Code Clarity: Ensure the code is well-commented, structured, and easy to understand.
• Test Coverage: Confirm that all functions have associated tests and that edge cases are considered.

Architecture Description and Diagram

Here's a simple architecture diagram showcasing the relationship and functionality of the LiquidityMining and LiquidityMiningPath contracts:

LiquidityMining: Represents the core functionality related to liquidity mining. It contains methods like initTickTracking(), crossTicks(), and accrueConcentratedGlobalTimeWeightedLiquidity().

LiquidityMiningPath: Acts as a sidecar to the main contract. It inherits from the LiquidityMining contract. Its main methods are protocolCmd() and userCmd().

The arrow indicates the inheritance relationship, with LiquidityMiningPath inheriting functionalities from LiquidityMining.

Codebase Quality

Overall, we consider the quality of the provided codebase to be commendable. The code demonstrates a sophisticated design, especially in the realms of liquidity management and tick tracking operations. We've observed the careful implementation of liquidity tracking in contracts such as LiquidityMining.sol, alongside the proxy sidecar functionalities evident in LiquidityMiningPath.sol.

The ecosystem places a strong emphasis on time-weighted liquidity and tick crossing management, as seen in the various functions like initTickTracking(), crossTicks(), and accrueConcentratedGlobalTimeWeightedLiquidity(). Moreover, the use of the proxy pattern in LiquidityMiningPath.sol highlights a strategic approach to bypass Ethereum's contract code size limits. Drawing parallels to other established projects, the architecture embodies best practices seen in prominent DeFi projects. Details of each component are elaborated upon in the sections above.

Systemic & Centralization Risks

The analysis of the provided smart contracts reveals multiple systemic and centralization risks in the protocol. These risks include liquidity management in LiquidityMining.sol, proxy sidecar functionalities in LiquidityMiningPath.sol, and potential centralization concerns arising from inherited contracts or ownership mechanisms. It's essential to further examine the documentation to determine the intent behind certain designs. Moreover, the potential absence of rigorous testing could introduce vulnerabilities.

1. Liquidity Management in LiquidityMining.sol:

   • The LiquidityMining.sol contract, with its emphasis on tick tracking and liquidity accrual, could present risks if not managed correctly. Mismanagement or significant losses in this contract could detrimentally impact the ecosystem. Distributing responsibilities across different contracts or mechanisms can help in risk mitigation.

2. Proxy Sidecar Functionality Risks in LiquidityMiningPath.sol:

   • The LiquidityMiningPath.sol acts as a proxy sidecar to the main contract. Any inefficiencies or vulnerabilities in this proxy logic could disrupt the protocol's operations or pose challenges for users, affecting trust in the protocol.

3. Dependency on Inherited Contracts:

   • The LiquidityMiningPath.sol contract inherits functionalities from LiquidityMining.sol, indicating interdependencies. Any issues in the inherited contracts could cascade and disrupt the operations of the inheriting contract.

4. Centralization Risks:

   • It's vital to note if the contracts exhibit any ownership patterns or mechanisms, especially if they stress the role of an "owner" or similar privileged entity. In a truly decentralized ecosystem, governance should be distributed, involving the community in key decisions rather than centralizing them in a singular role.

5. Cross-contract Token Risks:

   • When dealing with liquidity management and tick tracking, there's a risk associated with unfamiliar or malicious tokens. These tokens can:
     • Cause Fund Loss: If not handled correctly, they might exploit vulnerabilities, leading to stolen funds or protocol disruptions.
     • Manipulate Prices: These tokens can disrupt liquidity operations, affecting asset prices or system stability.

6. The potential absence of extensive testing methods, such as fuzzing or invariant testing, might expose the protocol to unforeseen vulnerabilities and threats.

Properly managing these risks and implementing best practices in security and decentralization will contribute to the sustainability and long-term success of this project.

Recommendations

1. Enhance Liquidity Management:

   • Dive deeper into the liquidity management mechanisms within LiquidityMining.sol. Consider diversifying strategies to enhance the system's resilience, especially in tick tracking and time-weighted liquidity calculations.

2. Refined Documentation:

   • Augment the documentation, especially for pivotal contracts such as LiquidityMining.sol and LiquidityMiningPath.sol. Ensure comments and explanations within the codebase are both clear and comprehensive. This will facilitate developers in understanding, maintaining, and evolving the codebase seamlessly.

3. Decentralized Governance:

   • Assess the governance structure, especially if any ownership patterns or privileged roles are present in the contracts. Transitioning towards a more decentralized governance system can empower users and enhance the protocol's security and adaptability.

4. Proxy Pattern Clarity:

   • Dive deeper into the proxy sidecar pattern implemented in LiquidityMiningPath.sol. Ensure that the pattern is both efficient and secure, and consider enhancing documentation around its intricacies to guide developers and users.

5. Function Redundancy:

   • Evaluate if there are recurring function names or similar structures within the contracts. Streamlining such functions can improve clarity and reduce potential confusion during development and auditing.

6. Simplify Inheritance and Nested Calls:

   • Assess the inheritance patterns, especially in LiquidityMiningPath.sol which inherits from LiquidityMining.sol. Simplifying these structures can enhance readability, making it easier for developers to understand the codebase and for auditors to identify potential issues.

7. Introduce Safety Mechanisms:

   • Given the critical operations related to liquidity management, consider incorporating safety measures within the contracts. Mechanisms like a circuit breaker or pausing functionality can act as a safety net during unforeseen vulnerabilities, allowing for timely interventions.

Gas Optimization

The provided codebase, focusing on LiquidityMining.sol and LiquidityMiningPath.sol, demonstrates a structured approach to gas usage. The contracts utilize various techniques to streamline gas costs, especially in methods related to liquidity management and proxy pattern implementations. While there may be some opportunities for minor gas optimizations, the overarching emphasis on code clarity and design integrity stands out. As such, in-depth optimizations might need to balance gas efficiency against maintainability and clarity.

Conclusion

The smart contracts LiquidityMining.sol and LiquidityMiningPath.sol showcase a meticulously crafted design that underscores the importance of liquidity management in the DeFi space. The developers have evidently prioritized creating a robust and efficient codebase. While there are certain areas, particularly around the proxy pattern and tick tracking, that warrant attention, the overall foundation is solid. For a more collaborative and transparent development environment, enhancing in-code comments and providing detailed documentation is crucial. Additionally, to fortify the protocol's security stance, the development team is urged to undertake regular security reviews, conduct periodic audits, and set up a bug bounty initiative. Adopting these measures would significantly bolster the protocol's credibility and resilience.

Time Spent

The audit was conducted over a span of 2 days, distributed as follows:

• 1st Day (8 hours): Initial exploration of the contracts, focusing on understanding the core design principles and functionalities of LiquidityMining.sol.
• 2nd Day (8 hours): Comprehensive review of LiquidityMiningPath.sol and its interplay with LiquidityMining.sol, emphasizing proxy pattern intricacies and interactions. Finalized the analysis, compiled findings, and drafted the report.

Total Time spent:<br> 16 hours

Time spent:

16 hours