Cian protocol’s yield layer allows users to deposit assets into a Vault contract to earn yield via multiple strategies. The protocol is interoperable cross-chain, offering pools on various chains that can hold a representation of the Vault token. This can be exchanged for deposit tokens on the given chain.
METHODOLOGY
- Verification of technical specification
The audit scope is confirmed with the client, and auditors are onboarded to the project. Provided documentation is reviewed and compared to the audited system. - Tool-based analysis
A deep check with Solidity static analysis tool Wake in companion with Solidity (Wake) extension is performed, flagging potential vulnerabilities for further analysis early in the process. - Manual code review
Auditors manually check the code line by line, identifying vulnerabilities and code quality issues. The main focus is on recognizing potential edge cases and project-specific risks. - Local deployment and hacking
Contracts are deployed in a local Wake environment, where targeted attempts to exploit vulnerabilities are made. The contracts’ resilience against various attack vectors is evaluated. - Unit and fuzz testing
Unit tests are run to verify expected system behavior. Additional unit or fuzz tests may be written using Wake framework if any coverage gaps are identified. The goal is to verify the system’s stability under real-world conditions and ensure robustness against both expected and unexpected inputs
We began our review using static analysis tools, including Wake. We then took a deep dive into the logic of the contracts. For testing and fuzzing, we used the Wake testing framework. For more information on fuzzing, see the respective section in the full audit report.
During the review, we paid special attention to:
- Ensuring the arithmetic operations and accounting of the system were correct;
- Detecting possible reentrancies and unprotected calls in the code;
- Ensuring access controls are not too relaxed or too strict;
- Identifying common issues such as data validation.
SCOPE
The audit was performed on commit 54e953 and the scope included all contracts, excluding strategies. Revision 1.1 was performed on commit 06f333, with the scope of the fixes of findings from the first review.
FINDINGS
Here are the findings from our audit.
Critical severity
No critical severity issues were found.
High severity
No high severity issues were found.
Medium severity
M1: Invalid calculations due to intermediary division
M2: Pool state variables have insufficient data validation
M3: Users have almost no control over their deposited funds
Low severity
L1: Double entrypoint-initialize functions
L2: Using transfer instead of call
L3: Missing initializers on constructors
L4: Strategy position limit calculation inaccuracy
Warning severity
W1: Strict equality check for balances
W2: Potential depeg of ETH-based assets
W3: Vault is not ERC4626-compliant
W4: Protocol owner can set arbitrary exchange price to pools
W5: Pitfalls of the Ownable contract
W6: Protocol owner can artificially mint Vault shares
W7: Underflow can cause DoS in confirmWithdrawal
W8: Users are not able to request more than one withdrawal
W9: Potential issues with retrieving borrow and supply caps
Informational severity
I1: A function can be declared as a view function
I2: Missing documentation
I3: Typos and incorrect NatSpec comments
I4: Missing underscore in internal function name
I5: Modifier consistency on access controls
I6: Unused variable
I7: Unused using-for directives
I8: Unused imports
I9: Unused events
I10: Unchecked return value for OFT receipt
TRUST MODEL
Users have to trust protocol owners to act honestly. This is because once they deposit funds into the Vault, they cannot withdraw them without external confirmation, and the withdrawn amount is also decided by the entity that confirms the withdrawal requests. Several findings were raised related to the trust model (see M3, W6, W4).
CONCLUSION
Our review resulted in 26 findings, ranging from Informational to Medium severity. All issues were addressed and were either fixed, partially fixed, or acknowledged with comments explaining the reasons.
The protocol demonstrated centralization, making its correct functioning highly dependent on the protocol owners (see M3). Additionally, we identified arithmetic and data validation issues that could lead to incorrect protocol accounting (see M1).
Ackee Blockchain Security recommends Cian to:
- Write a documentation;
- Create a comprehensive test suite;
- Focus on intermediary divisions and precision during calculations;
- Address all other reported issues.
Ackee Blockchain Security’s full Cian audit report, which includes a more detailed description of all findings and recommendations, can be found here.
We were delighted to audit Cian and look forward to working with them again.
