n
0xWeb3boy opened this issue · comments
Wise Lending Analysis
Wise Lending stands as a decentralized ecosystem enabling users to provide cryptocurrency assets and initiate earning a flexible APY from borrowers. Its lending APY outshines competitors due to its integration with diverse yield channels, establishing it as a premier avenue for passive yield accumulation on crypto holdings. Wise Lending was meticulously crafted from inception, boasting numerous enhancements over its predecessors. Wise Lending platform achieves top-tier APYs organically, devoid of the need for speculative token incentives.
Users engaging with Wise Lending encounter a dynamic borrowing landscape, where debt token borrow rates, manifested as borrow APYs, vary based on pool utilization. These rates are governed by a suite of adaptive bonding curves managed by the Lending Automated Scaling Algorithm (LASA). For detailed insights into LASA, refer to the Wise Lending Protocol LASA AI documentation.
In addition to standard deposit, withdraw, borrow, and payback functionalities, users access a range of interactive modes:
Exclusive deposit and withdraw options ensure user privacy, allowing withdrawals even when pools are devoid of borrowings. Aave pools optimize capital efficiency by accruing aave supply APY for unutilized funds.
Special curve pools within beefy farms serve as collateral, broadening usage horizons for these asset types.
Borrow repayments are facilitated with lending shares of the same asset type, streamlining position management.
User collaterals and borrows are encapsulated within position NFTs, facilitating holistic position trades and integration into secondary contracts, such as spot trading with PTP NFT trading platforms.
The key contracts of Wise Lending protocol are:
WiseLending.sol: This smart contract incorporates a variety of mechanisms designed to facilitate seamless operation. Among these mechanisms is the synchronization of the pool, a process undertaken both prior to and following the execution of the contract's code. Furthermore, the contract is equipped with functions tailored to accommodate user actions, including depositing funds, withdrawing assets, repaying debts, and liquidating outstanding loans.
-
WiseCore.sol: Within this smart contract, a range of intricately designed mechanisms ensures operational integrity and security. The Core liquidation function conducts rigorous security checks and intricate liquidation calculations, fortifying the system. Mathematical functions govern liquidation logic, safeguarding liquidators' interests by assessing pool reserves. Additionally, a precision-engineered function determines optimal collateral withdrawal for liquidation. Borrow logic, fortified with comprehensive security checks, ensures system reliability. Stringent checks verify position locks for powerFarms, upholding established protocols. Meticulous pool preparations streamline borrowing and collateralization processes, ensuring operational efficiency. -
PoolManager.sol: This contract serves a dual purpose: firstly, it establishes a liquidity pool, and secondly, it verifies whether the pool qualifies as an isolation pool through the utilization of the setVerifiedIsolationPool function. The creation of the pool itself is facilitated by the createPool function. This comprehensive contract not only sets up a mechanism for liquidity provision but also implements a robust verification process to discern isolation pool eligibility, enhancing the contract's functionality and reliability. -
PositionNFT.sol: This smart contract includes a critical feature whereby it generates non-fungible tokens (NFTs) exclusively for the sender. These NFTs are indispensable for users seeking to engage with the WiseLending protocol, as they serve as essential prerequisites for protocol utilization. The issuance of NFTs occurs through the execution of the mintNFT() function. This pivotal aspect of the contract underscores its significance in facilitating user access to the WiseLending protocol, ensuring a seamless and secure experience for participants. -
FeeManager.sol: This contract serves to streamline fee distribution within theWiseLendingecosystem. Operating as a central hub, the feeManager acquires fee tokens from each pool in the form of shares and can subsequently claim them via theclaimWiseFees()function. It features two distinct incentive structures to bolster the WISE ecosystem, catering to beneficial and incentiveOwner roles. Additionally, the contract tracks bad debt per position and offers a simple mechanism for debt settlement using incentives funded by gathered fees. -
PendlePowerFarm.sol: This smart contract encompasses a range of intricate mechanisms designed to facilitate various functionalities within its ecosystem. Among these mechanisms include the approximation of the new resulting net APY for a position setup, which aids users in understanding the potential returns of their positions. Additionally, the contract includes functionality for approximating the new borrow amount for the pool, providing clarity on borrowing capabilities. Furthermore, it features a Liquidation function tailored specifically for open power farm positions with a debt ratio exceeding 100%, ensuring the stability and integrity of the system. Moreover, users benefit from manual payback and withdraw functions, offering them greater control and flexibility over their assets and positions within the ecosystem. These comprehensive functionalities underscore the contract's versatility and utility in facilitating efficient and secure user interactions within the WiseLending platform. -
PowerFarmNFT.sol: This smart contract incorporates essential functionalities related to farming Non-Fungible Tokens (NFTs) within its ecosystem. One of its key features is the minting of farming NFTs, which are subsequently allocated to users to symbolize their respective farming positions. Additionally, the contract includes a mechanism for burning farming NFTs, enabling the removal of farming positions from the system when necessary. Furthermore, it offers a function designed to retrieve and return the positions held by a specific owner, providing users with visibility and oversight over their farming activities within the platform. These functionalities collectively contribute to the seamless management and organization of farming activities within the contract's ecosystem, fostering transparency and user engagement.
a) The approach I followed when reviewing the code
First, by examining the scope of the code, I determined my code review and analysis strategy.
https://code4rena.com/audits/2024-02-wise-lending#top
Accordingly, I analyzed and audited the subject in the following steps;
| Number | Stage | Details | Information |
|---|---|---|---|
| 1 | Compile and Run Test | Installation | Test and installation structure is simple, cleanly designed |
| 2 | Architecture Review | Wise Lending | Provides a basic architectural teaching for General Architecture |
| 3 | Graphical Analysis | Graphical Analysis with Solidity-metrics | A visual view has been made to dominate the general structure of the codes of the project. |
| 4 | Slither Analysis | Slither Report | The project does not currently have a slither result, a slither control was created from initial |
| 5 | Test Suits | Tests | In this section, the scope and content of the tests of the project are analyzed. |
| 6 | Manuel Code Review | Scope |
b) Analysis of the code base
The most important summary in analyzing the code base is the stacking of codes to be analyzed.
In this way, many predictions can be made, including the difficulty levels of the contracts, which one is more important for the auditor, the features they contain that are important for security (payable functions, uses assembly, etc.), the audit cost of the project, and the time to be allocated to the audit;
Uses Consensys Solidity Metrics
- Lines: total lines of the source unit
- nLines: normalized lines of the source unit (e.g. normalizes functions spanning multiple lines)
- nSLOC: normalized source lines of code (only source-code lines; no comments, no blank lines)
- Comment Lines: lines containing single or block comments
- Complexity Score: a custom complexity score derived from code statements that are known to introduce code complexity (branches, loops, calls, external interfaces, ...)
Entry Point of Project - Deposit Architecture;
Withdraw Architecture;
Borrow Architecture;
Payback Architecture
C) Testing suite Analysis
High levels of coverage across all metrics, indicating thorough testing.
(Note: these testing coverage is with foundry only, most of the tests are written in hardhat framework using javascript)
Wise Lending
| File | % Lines | % Statements | % Branches | % Funcs |
|---|---|---|---|---|
| Babylonian.sol | 0.00% (0/32) | 0.00% (0/34) | 0.00% (0/16) | 0.00% (0/1) |
| CurveUsdEthOracle.sol | 0.00% (0/10) | 0.00% (0/15) | 100.00% (0/0) | 0.00% (0/4) |
| CustomOracleSetup.sol | 0.00% (0/5) | 0.00% (0/5) | 100.00% (0/0) | 0.00% (0/5) |
| DaiEthOracle.sol | 0.00% (0/10) | 0.00% (0/15) | 100.00% (0/0) | 0.00% (0/4) |
| PendleChildLpOracle.sol | 0.00% (0/9) | 0.00% (0/14) | 100.00% (0/0) | 0.00% (0/4) |
| PendleLpOracle.sol | 0.00% (0/14) | 0.00% (0/18) | 0.00% (0/4) | 0.00% (0/4) |
| PendleTokenCustomOracle.sol | 0.00% (0/13) | 0.00% (0/16) | 100.00% (0/0) | 0.00% (0/5) |
| PtOracleDerivative.sol | 0.00% (0/15) | 0.00% (0/23) | 0.00% (0/4) | 0.00% (0/3) |
| PtOraclePure.sol | 0.00% (0/12) | 0.00% (0/18) | 0.00% (0/4) | 0.00% (0/3) |
| UsdcEthOracle.sol | 0.00% (0/10) | 0.00% (0/15) | 100.00% (0/0) | 0.00% (0/4) |
| UsdtEthOracle.sol | 0.00% (0/10) | 0.00% (0/15) | 100.00% (0/0) | 0.00% (0/4) |
| WBTC.oracle.sol | 0.00% (0/8) | 0.00% (0/11) | 100.00% (0/0) | 0.00% (0/3) |
| WethCustomOracle.sol | 0.00% (0/8) | 0.00% (0/8) | 100.00% (0/0) | 0.00% (0/5) |
| WstETHOracle.sol | 0.00% (0/11) | 0.00% (0/15) | 100.00% (0/0) | 0.00% (0/4) |
| DeclarationsFeeManager.sol | 22.22% (2/9) | 27.27% (3/11) | 16.67% (1/6) | 33.33% (1/3) |
| FeeManager.sol | 4.73% (8/169) | 4.49% (8/178) | 0.00% (0/50) | 7.14% (2/28) |
| FeeManagerHelper.sol | 3.28% (2/61) | 2.63% (2/76) | 0.00% (0/12) | 6.25% (1/16) |
| InvariantHandler.sol | 0.00% (0/112) | 0.00% (0/140) | 0.00% (0/32) | 0.00% (0/23) |
| InvariantManager.sol | 4.00% (1/25) | 4.00% (1/25) | 100.00% (0/0) | 4.00% (1/25) |
| InvariantUser.sol | 0.99% (2/202) | 0.79% (2/252) | 0.00% (0/52) | 3.03% (1/33) |
| MainHelper.sol | 0.58% (1/173) | 0.88% (2/226) | 0.00% (0/44) | 2.08% (1/48) |
| MockAave.sol | 0.00% (0/6) | 0.00% (0/6) | 100.00% (0/0) | 0.00% (0/2) |
| MockAaveToken.sol | 41.67% (15/36) | 41.67% (15/36) | 22.73% (5/22) | 41.67% (5/12) |
| MockAggregator.sol | 100.00% (2/2) | 100.00% (2/2) | 100.00% (0/0) | 100.00% (2/2) |
| cMockChainlink.sol | 33.33% (1/3) | 33.33% (1/3) | 100.00% (0/0) | 33.33% (1/3) |
| MockWeth.sol | 60.00% (12/20) | 58.33% (14/24) | 12.50% (1/8) | 50.00% (3/6) |
| OwnableMaster.sol | 14.29% (2/14) | 14.29% (2/14) | 16.67% (1/6) | 20.00% (1/5) |
| PoolManager.sol | 46.94% (23/49) | 51.61% (32/62) | 20.00% (2/10) | 55.56% (5/9) |
| PositionNFTs.sol | 9.46% (7/74) | 11.11% (10/90) | 3.57% (1/28) | 11.11% (2/18) |
| PendlePowerFarm.sol | 0.00% (0/30) | 0.00% (0/44) | 0.00% (0/10) | 0.00% (0/9) |
| PendlePowerFarmDeclarations.sol | 0.00% (0/17) | 0.00% (0/17) | 0.00% (0/6) | 0.00% (0/3) |
| PendlePowerFarmLeverageLogic.sol | 0.00% (0/88) | 0.00% (0/117) | 0.00% (0/30) | 0.00% (0/13) |
| PendlePowerFarmMathLogic.sol | 0.00% (0/64) | 0.00% (0/104) | 0.00% (0/24) | 0.00% (0/17) |
| PendlePowerFarmTester.sol | 0.00% (0/1) | 0.00% (0/1) | 100.00% (0/0) | 0.00% (0/1) |
| PendlePowerManager.sol | 0.00% (0/39) | 0.00% (0/45) | 0.00% (0/6) | 0.00% (0/8) |
| PendlePowerFarmController.sol | 0.00% (0/128) | 0.00% (0/144) | 0.00% (0/32) | 0.00% (0/18) |
| PendlePowerFarmControllerBase.sol | 0.00% (0/13) | 0.00% (0/13) | 0.00% (0/6) | 0.00% (0/4) |
| PendlePowerFarmControllerHelper.sol | 0.00% (0/32) | 0.00% (0/47) | 0.00% (0/6) | 0.00% (0/20) |
| PendlePowerFarmControllerTester.sol | 0.00% (0/3) | 0.00% (0/3) | 100.00% (0/0) | 0.00% (0/1) |
| PendlePowerFarmToken.sol | 0.00% (0/159) | 0.00% (0/207) | 0.00% (0/56) | 0.00% (0/34) |
| PendlePowerFarmTokenFactory.sol | 0.00% (0/7) | 0.00% (0/10) | 0.00% (0/2) | 0.00% (0/2) |
| SimpleERC20Clone.sol | 30.19% (16/53) | 32.79% (20/61) | 16.67% (3/18) | 41.18% (7/17) |
| MinterReserver.sol | 0.00% (0/24) | 0.00% (0/30) | 0.00% (0/10) | 0.00% (0/8) |
| PowerFarmNFTs.sol | 0.00% (0/40) | 0.00% (0/48) | 0.00% (0/12) | 0.00% (0/9) |
| esterChainlink.sol | 31.25% (5/16) | 31.25% (5/16) | 0.00% (0/4) | 22.22% (2/9) |
| TesterLending.t.sol | 0.00% (0/5) | 0.00% (0/5) | 100.00% (0/0) | 0.00% (0/5) |
| contracts/Token.sol | 0.00% (0/26) | 0.00% (0/29) | 0.00% (0/8) | 0.00% (0/8) |
| ApprovalHelper.sol | 100.00% (1/1) | 100.00% (1/1) | 100.00% (0/0) | 100.00% (1/1) |
| CallOptionalReturn.sol | 83.33% (5/6) | 88.89% (8/9) | 50.00% (1/2) | 100.00% (1/1) |
| SendValueHelper.sol | 0.00% (0/8) | 0.00% (0/8) | 0.00% (0/4) | 0.00% (0/1) |
| cTransferHelper.sol | 0.00% (0/2) | 0.00% (0/2) | 100.00% (0/0) | 0.00% (0/2) |
| WrapperHelper.sol | 0.00% (0/2) | 0.00% (0/2) | 100.00% (0/0) | 0.00% (0/2) |
| WiseCore.sol | 0.00% (0/97) | 0.00% (0/119) | 0.00% (0/28) | 0.00% (0/16) |
| WiseLending.sol | 0.00% (0/183) | 0.00% (0/214) | 0.00% (0/10) | 0.00% (0/47) |
| WiseLendingBaseDeployment.t.sol | 0.00% (0/275) | 0.00% (0/308) | 0.00% (0/14) | 0.00% (0/13) |
| WiseLendingDeclaration.sol | 57.14% (4/7) | 62.50% (5/8) | 25.00% (1/4) | 50.00% (1/2) |
| WiseLendingPrecisionLoss.t.sol | 0.00% (0/50) | 0.00% (0/62) | 0.00% (0/8) | 0.00% (0/5) |
| WiseLowLevelHelper.sol | 1.82% (1/55) | 1.72% (1/58) | 7.14% (1/14) | 2.27% (1/44) |
| FullMath.sol | 0.00% (0/31) | 0.00% (0/34) | 0.00% (0/10) | 0.00% (0/2) |
| OracleLibrary.sol | 0.00% (0/8) | 0.00% (0/12) | 0.00% (0/2) | 0.00% (0/1) |
| TickMath.sol | 0.00% (0/91) | 0.00% (0/142) | 0.00% (0/46) | 0.00% (0/2) |
| OracleHelper.sol | 31.78% (41/129) | 30.81% (53/172) | 24.07% (13/54) | 27.59% (8/29) |
| TesterWiseOracleHub.sol | 85.71% (6/7) | 85.71% (6/7) | 100.00% (0/0) | 33.33% (1/3) |
| WiseOracleHub.sol | 20.31% (13/64) | 21.79% (17/78) | 25.00% (3/12) | 17.65% (3/17) |
| WiseSecurity.sol | 0.00% (0/235) | 0.00% (0/298) | 0.00% (0/88) | 0.00% (0/32) |
| WiseSecurityDeclarations.sol | 0.00% (0/24) | 0.00% (0/28) | 0.00% (0/16) | 0.00% (0/1) |
| cWiseSecurityHelper.sol | 0.00% (0/157) | 0.00% (0/240) | 0.00% (0/32) | 0.00% (0/41) |
| AaveHelper.sol | 0.00% (0/56) | 0.00% (0/75) | 0.00% (0/18) | 0.00% (0/13) |
| AaveHub.sol | 7.95% (7/88) | 8.11% (9/111) | 25.00% (1/4) | 11.11% (2/18) |
| Declarations.sol | 40.00% (2/5) | 50.00% (3/6) | 50.00% (1/2) | 33.33% (1/3) |
| ------------------------- | ---------- | ---------- | ---------- | ---------- |
| Total | 5.19% (179/3449) | 5.16% (222/4303) | 3.91% (35/896) | 7.01% (54/770) |
| ------------------------- | ---------- | ---------- | ---------- | ---------- |
General Recommendations for Testing
Consistent Test Standards: Ensure uniformity in test coverage standards across all contracts to maintain code quality and reliability.Branch and Edge Case Testing: Prioritize testing for branches and edge cases, especially in contracts with lower branch coverage.Continuous Integration of Tests: Implement continuous integration processes to automatically run tests and report coverage, aiding in identifying coverage gaps promptly.
D) Security Approach of the Project
What the project should add in the understanding of Security;
1- By distributing the project to testnets, ensuring that the audits are carried out in onchain audit. (This will increase coverage)
2- After the project is published on the mainnet, there should be emergency action plans (not found in the documents)
3- Add On-Chain Monitoring System; If On-Chain Monitoring systems such as Forta are added to the project, its security will increase.
For example ; This bot tracks any DEFI transactions in which wrapping, unwrapping, swapping, depositing, or withdrawals occur over a threshold amount. If transactions occur with unusually high token amounts, the bot sends out an alert. https://app.forta.network/bot/0x7f9afc392329ed5a473bcf304565adf9c2588ba4bc060f7d215519005b8303e3
4- After the Code4rena audit is completed and the project is live, I recommend the audit process to continue, projects like immunefi do this.
https://immunefi.com/
5- Pause Mechanism
This is a chaotic situation, which can be thought of as a choice between decentralization and security. Having a pause mechanism makes sense in order not to damage user funds in case of a possible problem in the project.
6- Upgradability
There are use cases of the Upgradable pattern in defi projects using mathematical models, but it is a design and security option.
7- Emergency Action Plan
In a high-level security approach, there should be a crisis handbook like the one below and the strategic members of the project should be trained on this subject and drills should be carried out. Naturally, this information and road plan will not be available to the public.
https://docs.google.com/document/u/0/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/mobilebasic#h.27dmpkyp2k1z
8- ChainAnalysis oracle
With the ChainAnalysis oracle, OFAC interaction can be blocked so that legal issues do not arise
9- We also recommend that you have an "Economic Audit" for projects based on such complex mathematics and economic models. An example Economic Audit is provided in the link below;
Economic Audit with Three Sigma
10 - As the project team, you can consider applying the multi-stage audit model.
Read more about the MPA model;
https://mpa.solodit.xyz/
11 - I recommend having a masterplan applied to project team members (This information is not included in the documents).
All authorizations, including NPM passwords and authorizations, should be reserved only for current employees. I also recommend that a definitive security constitution project be found for employees to protect these passwords with rules such as 2FA. The LEDGER hack, which has made a big impact recently, is the best example in this regard;
https://twitter.com/Ledger/status/1735326240658100414?t=UAuzoir9uliXplerqP-Ing&s=19
E) Other Audit Reports and Automated Findings
Automated Findings:
https://app.wiselending.com/omni-audit-v1.pdf, https://app.hats.finance/audit-competitions/wise-lending-0xa2ca45d6e249641e595d50d1d9c69c9e3cd22573/submissions
F) Software Engineering Considerations
Security Best Practices
- Follow established security best practices, such as checks-effects-interactions pattern, to prevent reentrancy attacks, and use guard checks against overflows/underflows.
- Regular security audits and incorporating static analysis tools in the development pipeline are essential.
Testing and Quality Assurance
- Comprehensive testing, including unit tests, integration tests, and stress tests, should be conducted. This ensures that the contracts behave as expected under various scenarios.
- Consideration should be given to test-driven development (TDD) practices to ensure robustness from the outset.
Modularity and Reusability
The contracts demonstrate modularity (e.g., inheriting from OpenZeppelin contracts). This approach should be maintained or enhanced to ensure code reusability and easier updates.
Scalability Considerations:
Design contracts with scalability in mind. This includes considering layer 2 solutions or sidechains for more efficient processing, especially for cross-chain functionalities.
Community Feedback and Governance:
Incorporate mechanisms for community feedback and governance decisions into the software development lifecycle, reflecting the decentralized ethos of the protocol.
Security First Approach:
Given the critical role of registries in managing on-chain representations of components and agents, a security-first approach is paramount. This includes following best practices like check-effects-interactions pattern, secure handling of external calls, and gas optimizations.
Disaster Recovery and Emergency Protocols:
Implement mechanisms for data recovery and emergency handling in case of critical failures. This could include pausing functionality in the event of a detected anomaly or breach.
Time spent:
48 hours