Analysis

[c4-bot-5]

See the markdown file with the details of this report here.

[c4-pre-sort]

GalloDaSballo marked the issue as insufficient quality report

[trust1995]

Too much listing of information / GPT-based report.

[c4-judge]

trust1995 marked the issue as grade-c

[albahaca0000]

Hey, sorry @trust1995, could you please reread this analysis again?

This is also a good report with based on code4rena judging critteria

Areas of interest include:

Full representation of the project’s risk model:

Admin abuse risks

Systemic risks

Technical risks

Integration risks

In this report it mention excellent security analysis, systemic risk integration, technical risk assessment, and centralization risk analysis. Based on the data analysis, there are no other analyses of grade A or grade B that can identify risks as effectively as this report does. It thoroughly analyzes every contract and suggests numerous risks.

2. WiseSecurity.sol

   • Systemic Risks:

     1. The securityShutdown function allows a designated securityWorker address to shut down all active pools, which could potentially disrupt the entire system if misused or compromised.
     2. The setBlacklistToken function allows the master address to blacklist tokens, preventing them from being borrowed or used as collateral. This could potentially cause disruptions if important tokens are blacklisted.

   • Centralization Risks:

     1. The contract heavily relies on the master address, which has the authority to set critical parameters such as liquidation settings, blacklist tokens, and revoke security shutdowns. This centralization of power poses a risk if the master address is compromised or abused.
     2. The WISE_LENDING contract has significant control over various aspects of the system, such as verifying isolation pools, locking positions, and managing lending and borrowing data. Centralization of these functions in a single contract could introduce risks.

   • Technical Risks:

     1. The use of external contracts, such as WiseSecurityHelper, ApprovalHelper, and various other interfaces (ICurve, WISE_ORACLE, FEE_MANAGER), introduces dependencies and potential vulnerabilities if these contracts are not properly audited or maintained.
     2. The presence of several functions that perform critical operations, such as checksLiquidation, checksWithdraw, checksBorrow, and checksCollateralizeDeposit, increases the attack surface and the risk of potential vulnerabilities.
     3. The use of inline assembly (e.g., success in the curveSecurityCheck function) could introduce potential vulnerabilities if not implemented correctly.

   • Integration Risks:

     1. The contract heavily relies on external data sources, such as the WISE_ORACLE for token price data and the FEE_MANAGER for fee management. If these external sources are compromised or provide incorrect data, it could lead to issues within the system.
     2. The integration with various lending and borrowing pools, as well as the CurveSwap protocol, increases the complexity of the system and the potential for integration issues or vulnerabilities. It analysis every contract and suggests potential risks.

It analysis every contract and suggests potential risks.

2. WiseSecurity.sol

   • Systemic Risks:

     1. The securityShutdown function allows a designated securityWorker address to shut down all active pools, which could potentially disrupt the entire system if misused or compromised.
     2. The setBlacklistToken function allows the master address to blacklist tokens, preventing them from being borrowed or used as collateral. This could potentially cause disruptions if important tokens are blacklisted.

   • Centralization Risks:

     1. The contract heavily relies on the master address, which has the authority to set critical parameters such as liquidation settings, blacklist tokens, and revoke security shutdowns. This centralization of power poses a risk if the master address is compromised or abused.
     2. The WISE_LENDING contract has significant control over various aspects of the system, such as verifying isolation pools, locking positions, and managing lending and borrowing data. Centralization of these functions in a single contract could introduce risks.

   • Technical Risks:

     1. The use of external contracts, such as WiseSecurityHelper, ApprovalHelper, and various other interfaces (ICurve, WISE_ORACLE, FEE_MANAGER), introduces dependencies and potential vulnerabilities if these contracts are not properly audited or maintained.
     2. The presence of several functions that perform critical operations, such as checksLiquidation, checksWithdraw, checksBorrow, and checksCollateralizeDeposit, increases the attack surface and the risk of potential vulnerabilities.
     3. The use of inline assembly (e.g., success in the curveSecurityCheck function) could introduce potential vulnerabilities if not implemented correctly.

   • Integration Risks:

     1. The contract heavily relies on external data sources, such as the WISE_ORACLE for token price data and the FEE_MANAGER for fee management. If these external sources are compromised or provide incorrect data, it could lead to issues within the system.
     2. The integration with various lending and borrowing pools, as well as the CurveSwap protocol, increases the complexity of the system and the potential for integration issues or vulnerabilities. It analysis every contract and suggests potential risks.