> 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/treasury.md).

# Treasury

## Scope

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

## Executive Summary

The Lendefi DAO Treasury contract has been audited following the implementation of standardized security patterns across the ecosystem. The contract demonstrates strong security practices, with a well-implemented role-based access control system, timelocked upgrades, comprehensive vesting mechanisms, and secure emergency functions. No critical vulnerabilities were identified. **The most significant improvement in the recent update is the role reassignment that shifts more control to the timelock controller, enhancing decentralization.**

## Key Findings

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

## Risk Assessment

### Role-Based Access Control ✅

The contract implements a comprehensive role-based access control system with revised role assignments:

* `DEFAULT_ADMIN_ROLE` → timelock controller
* `MANAGER_ROLE` → timelock controller
* `PAUSER_ROLE` → timelock controller (previously assigned to guardian)
* `UPGRADER_ROLE` → both timelock controller and multisig (expanded from multisig only)

This updated role assignment pattern significantly improves decentralization by moving the PAUSER\_ROLE from the guardian to the timelock controller, ensuring emergency functions require governance approval. Additionally, the UPGRADER\_ROLE is now shared between the timelock and multisig, adding an additional layer of security while maintaining the multisig's ability to process upgrades.

### Upgrade Security ✅

The contract implements the standardized timelocked upgrade pattern:

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

The upgrade process follows a secure three-step workflow:

1. Schedule upgrade (requires UPGRADER\_ROLE)
2. Wait for timelock period (3 days)
3. Execute upgrade with verification (requires UPGRADER\_ROLE)

The contract now includes an upgrade cancellation mechanism:

```solidity
function cancelUpgrade() external onlyRole(UPGRADER_ROLE) {
    if (!pendingUpgrade.exists) {
        revert UpgradeNotScheduled();
    }
    address implementation = pendingUpgrade.implementation;
    delete pendingUpgrade;
    emit UpgradeCancelled(msg.sender, implementation);
}
```

This addresses a previously identified low-severity issue, allowing authorized roles to cancel potentially problematic upgrades.

### Vesting Implementation ✅

The contract implements a secure linear vesting mechanism with:

* Minimum vesting duration enforcement (730 days)
* Separate tracking for ETH and each ERC20 token
* Proportional vesting calculation
* Prevention of releasing more than what is vested
* Ability to update vesting schedule (with appropriate access control)

### Emergency Functions ✅

The emergency withdrawal functions follow the standardized pattern:

```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(_timelockAddress, balance);
    emit EmergencyWithdrawal(token, _timelockAddress, balance);
}
```

With the MANAGER\_ROLE now assigned exclusively to the timelock controller, emergency operations require decentralized governance approval, which significantly enhances security and prevents unilateral actions.

### Input Validation ✅

The contract employs robust input validation:

* Custom modifiers (`nonZeroAddress`, `nonZeroAmount`)
* Validation of vesting parameters
* Checks for sufficient vested amounts before releases
* Balance validations for emergency functions

## Detailed Findings

### Low Severity

1. ~~**No Upgrade Cancellation Mechanism**~~ ✅ **Resolved**

   The contract now includes a `cancelUpgrade()` function that allows addresses with UPGRADER\_ROLE to cancel scheduled upgrades, addressing this previous finding.

### Informational

1. **Vesting Schedule Updates**

   The contract allows the DEFAULT\_ADMIN\_ROLE to update the vesting schedule. While this flexibility can be beneficial, it also means the timelock controller can potentially accelerate vesting by reducing the duration or adjusting the start time.

   **Consideration:** This is by design, but should be noted as it places significant trust in the timelock governance process.
2. **ETH Representation in Emergency Events**

   For emergency ETH withdrawals, the contract uses a special address (0xEeeeeE...) to represent ETH in events. While this is a common pattern, it might be more explicit to have separate events for ETH and token withdrawals.
3. **Storage Gap Size**

   The contract reserves 23 storage slots for future upgrades. While this is likely sufficient, complex upgrades might require more slots depending on future requirements.

## Conclusion

The Treasury contract demonstrates excellent adherence to the standardized security patterns established for the Lendefi DAO ecosystem. The implementation of role-based access control, timelocked upgrades, secure vesting mechanics, and comprehensive input validation provides a strong security foundation.

The updated role assignments represent a significant improvement in the contract's security model by:

1. Moving PAUSER\_ROLE from a single guardian to the timelock controller
2. Adding timelock controller to UPGRADER\_ROLE alongside the multisig

These changes align with the ecosystem-wide shift toward greater decentralization and consistent governance through the timelock controller. Emergency operations now require governance approval rather than individual action, and upgrades benefit from both the security of the multisig and the decentralized oversight of the DAO.

The contract successfully implements all required security patterns:

1. ✅ Enhanced role management with improved decentralization
2. ✅ Timelocked upgrades with appropriate checks
3. ✅ Upgrade cancellation capability
4. ✅ Secure fund management
5. ✅ Comprehensive input validation
6. ✅ Reentrancy protection
7. ✅ Version tracking for upgrades
8. ✅ Pausable functionality for emergency situations

No critical or high severity issues were identified. With the previous low severity issue now resolved, the remaining informational items do not compromise the security of the contract.