> For the complete documentation index, see [llms.txt](https://lendefidao.gitbook.io/lendefi-dao-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://lendefidao.gitbook.io/lendefi-dao-docs/audit/investmentmanager.md).

# InvestmentManager

## Scope

* Contract: InvestmentManager.sol
* Version: v1
* Framework: OpenZeppelin Contracts Upgradeable v5

## Executive Summary

The Investment Manager contract has been audited following the implementation of standardized security patterns across the Lendefi DAO ecosystem. The contract demonstrates robust security controls with a well-implemented role-based access control system, timelocked upgrades, and comprehensive investment round management. **A significant improvement in the recent update is the alignment of all role assignments with the broader ecosystem pattern, with all critical roles now assigned to the timelock controller.**

## Key Findings

| Severity      | Number of Findings |
| ------------- | ------------------ |
| Critical      | 0                  |
| High          | 0                  |
| Medium        | 0                  |
| Low           | 2                  |
| Informational | 3                  |

## Risk Assessment

### Role-Based Access Control ✅

The contract implements a comprehensive role-based access control system with role assignments now fully aligned with the ecosystem pattern:

* `DEFAULT_ADMIN_ROLE` → timelock controller
* `MANAGER_ROLE` → timelock controller
* `PAUSER_ROLE` → timelock controller
* `UPGRADER_ROLE` → timelock controller
* `DAO_ROLE` → timelock controller

This implementation ensures that all critical contract functions are governed through the DAO's timelock controller, providing consistent decentralized governance across the ecosystem. This represents a significant security improvement compared to the previous implementation where certain roles were assigned to a gnosis safe multisig.

### Upgrade Security ✅

The contract implements the standardized timelocked upgrade pattern with a 3-day delay:

```solidity
struct UpgradeRequest {
    address implementation;
    uint64 scheduledTime;
    bool exists;
}
```

The upgrade process follows a secure three-step workflow:

1. Schedule upgrade (with implementation address)
2. Wait for timelock period (3 days)
3. Execute upgrade with verification

With the `UPGRADER_ROLE` now assigned to the timelock controller, upgrades require on-chain governance approval, enhancing security and decentralization.

### Emergency Functions ✅

Emergency withdrawal functions follow secure patterns:

```solidity
function emergencyWithdrawToken(address token) 
    external 
    nonReentrant 
    onlyRole(MANAGER_ROLE) 
    nonZeroAddress(token)
{
    uint256 balance = IERC20(token).balanceOf(address(this));
    if (balance == 0) revert ZeroBalance();

    IERC20(token).safeTransfer(timelock, balance);
    emit EmergencyWithdrawal(token, balance);
}
```

Security characteristics:

* Only MANAGER\_ROLE (timelock) can execute
* Uses nonReentrant guard
* Transfers to timelock
* Validates token address
* Checks for non-zero balance

### Investment Round Management ✅

The contract implements a robust state machine for investment rounds:

* Clearly defined states (PENDING, ACTIVE, COMPLETED, FINALIZED, CANCELLED)
* Enforced forward-only state transitions
* Controlled investor allocations and limits
* Per-round token and ETH accounting
* Gas-optimized investor tracking

## Detailed Findings

### Low Severity

1. **ETH Receive Fallback Function**

   The contract has a `receive()` function that automatically invests any received ETH into the current active round:

   ```solidity
   receive() external payable {
       uint32 round = getCurrentRound();
       if (round == type(uint32).max) revert NoActiveRound();
       investEther(round);
   }
   ```

   This could potentially lead to unexpected behavior if ETH is sent directly to the contract address without proper context.

   **Recommendation:** Consider removing the automatic investment functionality or implementing additional validation.
2. **Round Status Transition Restrictions**

   The contract enforces forward-only round status transitions, which is generally good for security but means that rounds cannot be reactivated if accidentally moved to the wrong status.

   **Recommendation:** Consider implementing an exception mechanism for governance to correct status errors.

### Informational

1. **Lack of Round Time Extensions**

   There is no mechanism to extend a round's end time once it has been created, which could be problematic if market conditions change.
2. **Time-based Operations**

   The contract uses `block.timestamp` for round timing and vesting schedules. While acceptable for the timeframes used, it's worth noting that this can be slightly manipulated by miners.
3. **Maximum Investors Limit**

   The contract limits each round to 50 investors (`MAX_INVESTORS_PER_ROUND`). While this is a sensible gas optimization, it could restrict participation in popular investment rounds.

## Conclusion

The Investment Manager contract demonstrates strong security practices with comprehensive role-based access control, timelocked upgrades, and secure investment processing. The updated role assignments, which now align all critical roles with the timelock controller, represent a significant security improvement that ensures consistent governance across the Lendefi DAO ecosystem.

This improvement removes the previous centralization concern where certain roles were assigned to a gnosis safe multisig rather than the timelock controller. All critical operations now require on-chain governance approval through the timelock, enhancing security and decentralization.

The contract successfully implements all required security patterns:

1. ✅ Role management with proper separation of concerns and alignment with ecosystem patterns
2. ✅ Timelocked upgrades with appropriate checks
3. ✅ Emergency functions with proper access control
4. ✅ Reentrancy protection
5. ✅ Comprehensive input validation

No critical or high severity vulnerabilities were identified. The remaining low severity and informational issues do not compromise the security of the contract and can be addressed in future updates if desired.