Cyan Protocol is an NFT lending platform with three main components: Cyan Wallet, Payment Plans, and Vaults. Payment Plans allow users to acquire NFTs either through loans or obtain loans by using their NFTs as collateral supported by Cyan Vaults. The Cyan Vaults are designed to provide liquidity for the protocol's payment plans, while the Ape Coin Vault supplies Ape Coin for Ape Staking plans. Additionally, the protocol facilitates peer lending, enabling users to borrow from other users against their NFTs. The Cyan Wallet serves as an escrow mechanism, securely holding NFTs for the duration of any payment plan and ensuring their release only upon the fulfillment of the plan's terms. We began the audit with the commit `82fac868b167984272816c37d516bf280bca8507`. During the audit, we identified a high severity issue (CYAN-1) resulting from insufficient validation on CryptoPunk ownership when CryptoPunks were purchased through Cyan Private Sales. As a result, it is possible for users to sell CryptoPunks that they do not own. In addition, we identified an issue where an NFT could remain locked following the completion of a plan through the revival of a Peer Plan (Cyan-2). We uncovered low-severity issues concerning compatibility with tokens and the Cyan wallet's locking mechanism, where locked assets could be transferred from the Cyan wallet due to prior approval (CYAN-4) or listing on the CryptoPunk marketplace (CYAN-5). Although discussions with the client indicated an intention to whitelist only the `safeTransferFrom()` selector for tokens, we observed token modules validating selectors discussed in the exploit scenarios. In CYAN-6, we identified a potential front-running vulnerability in the `CyanVaultV2.sol` where users might exploit the fluctuating total currency calculations for guaranteed profit when updating `DEFAULTED_NFT_ASSET_AMOUNT`. Additionally, we noted incompatibilities between ERC1155 and CryptoPunks with the unwind feature in CYAN-10. During the audit, a new commit `4d8bf244180522bf5aee47e222a5760a657e0cd4` was provided, which included functionality for locking newly minted Vault tokens in Cyan wallets. The updated implementation contract is incompatible with existing vault contracts due to its usage of `initialize()` (CYAN-3). Furthermore, this new feature caused the existing test suite to break due to changes in the vault implementation contract. We recommend that the client fix the test suite and add additional tests to verify the functionality of the new feature. **Fix Review Update** The client has fixed the majority of the issues. All acknowledged issues were done so with sufficient reasoning, mainly describing the teams plan to not enable problematic functions. At the latest commit reviewed `959860e5fce4c0441080bb44d8bb669929572b17`, we are unable to run the tests. There are more details in the [Test Suite Results](https://al.quantstamp.com/report/0777002c-a3a1-4794-b0fc-114b3732a0f7#test-suite-results). As a part of the new implementation, as tokens are deposited into `CyanVaultV2` they are locked for `withdrawLocked` duration. Users should be aware that any deposit will reset the `withdrawLocked` duration, and all tokens will be relocked, even if the original lock duration has totally elapsed. **Fix Review Update 2** Following the delivery of the initial report, we reviewed modifications to the `YugaModule` at commit `0cbbbb9a27920052da3d33962f0f831f4e414781`in their private repo, which was merged to the [public repo](https://github.com/usecyan/cyan-protocol-v2-public) at commit `614ddbee7fc36a2c5753015df72c14d6c1d06333`. The team made changes to the module that allows for Operators in the Cyan protocol to stake and lock ApeCoin under a new lock, separate from the preexisting ones. This new locking mechanism is intended to be used in partnership with MachiBigBrother’s DAM project, where users can stake Ape in the ApeCoinPool for a certain amount of time, after which they will be allowed to withdraw the staked funds. ApeCoin staked in this way can either be done under the DAM Lock, or one of the previously supported BAYC, MAYC, BAKC, or ApeCoin locks, but not both. The operating contract was not reviewed, only the changes to the module. **Fix Review Update 3** The client shared an issue reported through Immunefi involving a reentrancy vulnerability in Seaport contracts when interacting with the `CyanPaymentPlanV2`. The vulnerability allowed a malicious actor to craft an OpenSea offer for an NFT payment plan using a malicious ERC20 token (CYAN-19). The client fixed the root cause by clearing previous approvals when locking ERC721 tokens. The issue was further mitigated by adding a signature requirement to the `earlyUnwindOpensea()` function; the client will validate the offer off-chain before signing to prevent the usage of malicious ERC20 tokens during OpenSea fulfillment. Please note that this fix also introduces an auto-liquidation feature for new vaults.
Low | Medium | High | Critical | Total | |
---|---|---|---|---|---|
Not fixed | 7 | - | - | - | 7 |
Fixed | 8 | 2 | 1 | - | 11 |
Total | 15 | 2 | 1 | 0 | 18 |
# | File Name |
---|---|
1 | contracts/thirdparty/opensea/ISeaport.sol |
2 | contracts/modules/ERC721Module.sol |
3 | contracts/thirdparty/benddao/ILendPoolLoan.sol |
4 | contracts/interfaces/core/IModule.sol |
5 | contracts/core/Core.sol |
6 | contracts/interfaces/core/IWallet.sol |
7 | contracts/conduit/TokenTransferrer.sol |
8 | contracts/thirdparty/benddao/DataTypes.sol |
9 | contracts/core/CoreStorage.sol |
10 | contracts/main/CyanVaultV2.sol |