Core Contracts

Summary

The RAACReleaseOrchestrator contract, which is responsible for managing vesting schedules and releasing RAAC tokens, does not include any logic to receive or hold RAAC tokens. This design flaw forces the administrator to manually send tokens to the contract, creating potential for mismanagement and operational errors.

Vulnerability Details

• Absence of Deposit Functionality:
  The contract does not implement any function that enables it to receive RAAC tokens. There is no constructor logic, payable fallback, or dedicated deposit function to ensure that the tokens intended for vesting and subsequent release are securely held by the contract.

• Dependence on Manual Token Transfers:
  In the current implementation, functions like release() rely on the contract’s balance of RAAC tokens when transferring tokens to beneficiaries. Without a built-in mechanism for token deposits, the contract may have an insufficient token balance, leading to transfer failures.

• Operational Assumptions:
  The contract assumes that the RAAC tokens required for vesting will be manually supplied by the administrator. This assumption is problematic because it increases administrative overhead and the risk of human error, potentially disrupting the vesting process.

Impact

• If the contract does not hold the required RAAC tokens, calls to release() will fail, preventing beneficiaries from receiving their vested tokens.

• Reliance on manual token transfers by the admin introduces opportunities for mistakes in token allocation and timing, undermining the trustworthiness and reliability of the vesting mechanism.

Tools Used

Manual Review

Recommendations

Implement a deposit mechanism (or fallback/receive functions) to allow the contract to automatically accept and securely hold RAAC tokens, ensuring that vesting releases are backed by sufficient token reserves.