Core Contracts

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

Delegation Lock Issue in `BoostController` Contract

Summary

The delegateBoost function in the BoostController contract contains a flaw where users are unable to re-delegate their boost after the delegation period expires. If the recipient does not manually remove the expired delegation, the original delegator is permanently blocked from delegating again. This results in a usability issue, where users may find themselves unable to delegate boosts unless the recipient takes action.

Vulnerability Details

Affected Function

function delegateBoost(
address to,
uint256 amount,
uint256 duration
) external override nonReentrant {
if (paused()) revert EmergencyPaused();
if (to == address(0)) revert InvalidPool();
if (amount == 0) revert InvalidBoostAmount();
if (duration < MIN_DELEGATION_DURATION || duration > MAX_DELEGATION_DURATION)
revert InvalidDelegationDuration();
uint256 userBalance = IERC20(address(veToken)).balanceOf(msg.sender);
if (userBalance < amount) revert InsufficientVeBalance();
UserBoost storage delegation = userBoosts[msg.sender][to];
if (delegation.amount > 0) revert BoostAlreadyDelegated(); // Prevents re-delegation if not manually removed
delegation.amount = amount;
delegation.expiry = block.timestamp + duration;
delegation.delegatedTo = to;
delegation.lastUpdateTime = block.timestamp;
emit BoostDelegated(msg.sender, to, amount, duration);
}

Root Cause

The issue arises from the following line in the code:

if (delegation.amount > 0) revert BoostAlreadyDelegated();

This condition prevents any new delegation if there is already a delegation, even if the prior delegation has expired. For the original delegator to regain the ability to delegate, the recipient must manually call removeBoostDelegation after the delegation expires. If the recipient does not take this action, the original delegator is locked out from delegating again.

Problems Caused

  1. Permanent Delegation Lock: If the recipient does not manually remove the expired delegation, the original delegator will be permanently unable to delegate their boost.

  2. User Dependence: The original delegator's ability to re-delegate is entirely dependent on the recipient, which introduces a usability issue and creates an unnecessary dependency on the recipient’s action.

Impact

  • Inability to Re-delegate: Users may be unable to delegate their boost again if the recipient does not actively manage expired delegations, reducing the flexibility of the system.

  • Fairness Issues: The system places an unfair burden on the recipient to manage expired delegations, limiting the usability of the delegation feature for the original delegator.

Tools Used

  • Manual Code Review

Recommendations

Suggested Fixes

  1. Allow Re-delegation After Expiry: Modify the delegateBoost function to permit re-delegation after the delegation period has expired, but still prevent multiple active delegations.

    if (delegation.expiry > block.timestamp && delegation.amount > 0) {
    revert BoostAlreadyDelegated(); // Prevents re-delegation while active, allows after expiry
    }
  2. Automatically Clear Expired Delegations: To ensure that expired delegations do not block future delegations, clear expired delegations automatically before assigning a new one.

    if (delegation.expiry <= block.timestamp) {
    delete userBoosts[msg.sender][to]; // Automatically clear expired delegations
    }
Updates

Lead Judging Commences

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

BoostController: Users unable to remove their own expired boost delegations, creating dependency on recipients and preventing efficient reallocation of boosts

Support

FAQs

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

Give us feedback!