Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: medium
Valid

Unnecessary/Incorrect Token Transfer in `emergencyRevoke` Function

Summary

In the RAACReleaseOrchestrator contract, the emergencyRevoke function performs a token transfer to the contract’s own address (address(this)) after deleting a beneficiary's vesting schedule. This behavior is problematic because it either wastes gas if the intent was solely to revoke the schedule or, worse, misdirects unreleased tokens—potentially locking them in the contract—if the intended action was to reassign them to a different address.

Vulnerability Details

  • Redundant Transfer: If the sole purpose of emergencyRevoke is to cancel a vesting schedule, then transferring tokens to address(this) is unnecessary, leading to extra gas consumption without any benefit.

  • Misrouted Funds: If the design intent was to recover or reassign the unreleased tokens to a designated address (e.g., a treasury or recovery account), sending the tokens to the contract’s own address is erroneous. This misdirection may cause the tokens to become locked within the contract, hindering liquidity and future token management.

  • Ambiguous Intent: The presence of the token transfer raises uncertainty about the intended behavior of the function. There is a lack of clarity on whether the tokens should be reclaimed or simply ignored upon emergency revocation.

Codes:

contracts\core\minters\RAACReleaseOrchestrator\RAACReleaseOrchestrator.sol

function emergencyRevoke(address beneficiary) external onlyRole(EMERGENCY_ROLE) {
VestingSchedule storage schedule = vestingSchedules[beneficiary];
if (!schedule.initialized) revert NoVestingSchedule();
uint256 unreleasedAmount = schedule.totalAmount - schedule.releasedAmount;
delete vestingSchedules[beneficiary];
if (unreleasedAmount > 0) {
@ raacToken.transfer(address(this), unreleasedAmount);
emit EmergencyWithdraw(beneficiary, unreleasedAmount);
}
emit VestingScheduleRevoked(beneficiary);
}

Impact

  • Gas Inefficiency: Users executing the emergency revocation incur unnecessary gas costs due to the redundant token transfer if no funds are meant to be moved.

  • Potential Token Lock-Up: In scenarios where unreleased tokens should be redirected to a designated recipient, sending them to address(this) might render the tokens inaccessible, leading to liquidity issues or permanent loss of funds.

  • Operational Risk: The ambiguity and incorrect handling of tokens can cause unintended side effects in token management, impacting both the project’s treasury operations and beneficiary expectations.

Tools Used

  • Manual

Recommendations

  • Remove Redundant Transfer: If revocation is the only intent, remove the token transfer entirely to save gas and simplify the function logic.

  • Correct Recipient Address: If unreleased tokens are intended to be reclaimed or transferred to another entity (such as a treasury), update the recipient address accordingly rather than using address(this).

Updates

Lead Judging Commences

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RAACReleaseOrchestrator::emergencyRevoke sends revoked tokens to contract address with no withdrawal mechanism, permanently locking funds

inallhonesty Lead Judge 7 months ago
Submission Judgement Published
Validated
Assigned finding tags:

RAACReleaseOrchestrator::emergencyRevoke sends revoked tokens to contract address with no withdrawal mechanism, permanently locking funds

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!