Core Contracts

Summary

The RAACReleaseOrchestrator::emergencyRevoke function does not correctly handle the transfer of RAAC tokens upon revocation. Instead of ensuring that the revoked tokens are properly managed, it mistakenly transfers them to the contract itself, creating an ineffective and illogical transfer mechanism. Under an emergency state, the tokens should be transferred to an intended destination rather than being locked in the contract itself.

Vulnerability Details

When revoking a vesting schedule, the contract deletes the active vestingSchedules entry for the beneficiary and transfers the unreleased tokens to the contract itself. However, the RAAC tokens are already held within the contract as part of the vesting mechanism. This raises the question of what the intended destination for these tokens should be.

We assume that the contract intends to transfer the tokens to another designated address (e.g., a treasury or recovery wallet) rather than keeping them locked in the contract. Since the current implementation does not achieve this, the transfer logic is incorrect and fails to properly manage emergency revocations.

RAACReleaseOrchestrator::emergencyRevoke

Impact

• Locked Funds: The revoked funds remain stuck in the contract, with no clear way to retrieve them.

• Unclear Emergency Handling: The function fails to properly manage emergency revocation, making the system unreliable.

Tools Used

Manual Review

Recommendations

Modify the emergencyRevoke function to transfer revoked tokens to an intended fallback account rather than locking them in the contract. Possible solutions include:

1. Transferring tokens to a designated treasury or admin-controlled wallet.

2. Implementing a recovery function that allows an authorized role to retrieve revoked tokens.

3. Remove the token transfer since the token is already locked in the contract