Canopy - SCA #2 - Canopy

1. Introduction

Canopy engaged Halborn to conduct a security assessment of some packages for Movement blockchain, beginning on June 18th, 2025, and ending on July 1st, 2025. This security assessment focused on the smart contracts within the Satay-movement GitHub repository, commit hashes, and further details can be found in the Scope section of this report. The primary focus of this audit is to review the new Meridian strategy and a newly implemented rewards notification feature within the LayerBank and Echelon strategies.

Canopy is a yield aggregator on the Movement network that enables efficient interaction with multiple DeFi protocols through modular strategies composed of predefined operations. It also provides automated vaults that optimize fund allocations and rebalance strategy debt ratios, offering a streamlined approach to yield generation with reduced user intervention.

2. Caveat

All remediations described in this report were completed prior to the following commit, which serves as a consolidated snapshot of the final codebase. This commit also includes some additional modifications that do not impact the security of the project. While remediations may have been implemented across multiple earlier commits, this single commit includes all relevant changes and can be used for verification purposes:

1ad23ffefe263ce88de0a328952af41e22c1c1ff

3. Assessment Summary

The team at Halborn assigned a full-time security engineer to verify the security of the smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.

The purpose of this assessment is to:

• Ensure that smart contract functions operate as intended.

• Identify potential security issues with the smart contracts.

  
  

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were mostly addressed by the Canopy team. The main ones were the following: 

• Make the withdraw_fa function publicly accessible in the Meridian strategy and add proper authorization checks to allow fee recipients to withdraw their strategy shares.

• Create a deposit function that allows Meridian strategy deposits to be handled through the appropriate FA path while supporting the required CoinType parameter.

• Add validation in the rewards notification functions to skip processing when the reward asset matches the strategy's base asset.

• Fix the claim_behalf function to query balances from the on_behalf_of address instead of the signer's address when calculating claimed rewards.

4. Test Approach and Methodology

Halborn performed a combination of the manual view of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation, automated testing techniques help enhance the coverage of smart contracts. They can quickly identify items that do not follow security best practices. The following phases and associated tools were used throughout the term of the assessment:

• Research into the architecture, purpose, and use of the platform.

• Manual code review and walkthrough.

• Manual assessment of the critical Move variables and functions in scope to identify any vulnerability classes related to arithmetic or logic.

• Cross-contract call controls.

• Logical controls related to the platform architecture.

• Integration testing using the Aptos Framework.

5. Caveat

While the audit team conducted a thorough static review and manual analysis, dynamic validation (e.g., automated test execution or proof-of-concept reproduction) could not be performed due to technical constraints outside the scope of this engagement. Specifically, a build error caused by third-party package dependencies prevented the execution of the existing test suite within the audit environment.

As a result, end-to-end tests could not be executed, and certain behaviors could not be verified through runtime instrumentation. Although this limited the ability to validate some edge cases dynamically, the findings presented are based on careful source code analysis and reflect the issues observable through that approach.