In-House Audit

Blacksail Audit Report

3 Contracts Evaluated;

  • Blacksail_StrategyV3.sol,

  • Blacksail_Vault.sol,

  • 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

PreviousSolidProof.ioNextBlacksail Contracts

Last updated