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:

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:

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:

   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.