# In-House Audit

## Blacksail Audit Report

**3 Contracts Evaluated;**

* **Blacksail\_StrategyV3.sol,**&#x20;
* **Blacksail\_Vault.sol,**&#x20;
* **Blacksail\_Interface.sol**

### 1. Overview

**Type:** Yield Strategy Contract\
**Frameworks/Libraries Used:**

* **OpenZeppelin** (AccessControl, Pausable, ReentrancyGuard, SafeERC20)\
  **External Interfaces:**
* **IEqualizerPool** (reward pool interactions)
* **IIchiDepositHelper** (deposit interactions)
* **IUniswapRouterV3** (Uniswap V3 for swaps)
* **ISolidlyRouter** (token routing)

**Blacksail Contracts GitHub Repository:** <https://github.com/Blacksail-finance/audits/tree/main/contracts>

***

### 2. Key Features

* **Token Staking and Harvesting:** Stake tokens in a reward pool and reinvest rewards.
* **Liquidity Management:** Automated token swaps for reinvestment.
* **Fee Structure:** Call fees, platform fees, and withdrawal fees.
* **Emergency Control:** Contract can be paused and migrated using the `retireStrat` function.
* **Flexibility:** Adjustable slippage tolerance and fee parameters.

***

## 3. Findings

### 3.1 Security Analysis

**Reentrancy Vulnerability:**

* **Risk Level:** Low
* **Mitigation:** Applied `nonReentrant` modifier to withdraw and other sensitive functions. This effectively mitigates reentrancy attacks.

**Access Control:**

* **Observation:** Functions such as `setVault`, `setSlippageTolerance`, and `pause` are restricted to the owner via `onlyOwner`.
* **Mitigation:** Secure storage of the owner's private keys is essential to prevent unauthorized access.

**Allowance Risks:**

* **Observation:** Functions `_giveAllowances` and `_removeAllowances` use maximum approvals (unlimited). This poses a risk if external dependencies are compromised.
* **Recommendation:** Implement incremental allowances to reduce exposure.

**Unchecked External Calls:**

* **Observation:** Functions like `addLiquidity` and `forwardDepositToICHIVault` rely on external contracts, posing a cascading failure risk.
* **Mitigation:** `try-catch` blocks wrap external calls (already implemented in `addLiquidity`).

***

### 3.2 Logical and Functional Analysis

**Fee Handling:**

* **Observation:** `WITHDRAW_FEE` and `PLATFORM_FEE` are hardcoded. Parameterizing via governance could enhance flexibility.

**Error Handling in Swaps:**

* **Observation:** Uniswap V3 interactions include robust error handling (`try-catch` with reason logging). This ensures smoother debugging.

**Harvest on Deposit:**

* **Observation:** `harvestOnDeposit` auto-harvests but disables withdrawal fees. Ensure this trade-off aligns with economic incentives.

**Rewards Conversion:**

* **Observation:** The `rewardToNative` route is predefined. Ensure external audits validate routing efficiency and stability.

***

### 3.3 Gas Optimization

**Loops in Constructor:**

* **Observation:** `rewardToNative` initialization in a loop may lead to high deployment gas costs.
* **Recommendation:** Segment initialization or hardcode routes to reduce gas usage.

**Repeated State Reads:**

* **Observation:** Functions like `withdraw` and `addLiquidity` repeatedly access state variables.
* **Recommendation:** Cache values in memory to minimize redundant reads.

**Complexity in chargeFees:**

* **Observation:** Fee calculations (`platformFee`, `callFeeAmount`, `treasuryFee`) occur sequentially.
* **Recommendation:** Simplify calculations to improve clarity and reduce gas costs.

***

### 4. Recommendations

* **Add Time-Locks to Critical Functions:** Sensitive parameter changes (e.g., `WITHDRAW_FEE`, `slippageTolerance`) should have time-locks to prevent governance attacks.
* **Event Logging:** Additional event logs for key activities like `addLiquidity` success enhance monitoring and tracking.
* **Slippage Tolerance Cap:** Cap `setSlippageTolerance` at 5-10% to minimize user exposure to high slippage scenarios.
* **Documentation and Comments:** Add more inline comments, especially in complex functions like `_harvest`.

***

### 5. Tests and Simulations

**Test Coverage:**\
Ensure unit tests cover edge cases:

* Harvesting with no rewards.
* High-slippage swaps.
* Emergency scenarios (paused contracts).

**Simulated Attack Scenarios:**

* **Reentrancy:** Mocked contracts tested reentrancy vulnerabilities.
* **Owner Privilege Misuse:** Simulated fee manipulation to assess impact.

***

### 6. Overall Assessment

**Strengths:**

* Modular design with strong error handling.
* OpenZeppelin libraries ensure reliability.
* Flexible fee and slippage mechanisms.

**Weaknesses:**

* External contract dependencies introduce inherent risks.
* Certain operations could benefit from gas optimizations.

**Final Rating:**

* **Security:** 9/10
* **Efficiency:** 8/10
* **Flexibility:** 9/10

***

#### Files

* **Blacksail Contracts Github Repository:** <https://github.com/Blacksail-finance/audits/tree/main/contracts>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.blacksail.finance/about-blacksail-finance/audits/in-house-audit.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
