Core Contracts

The `removeBoostDelegation()` function in the `BoostController.sol` function is designed to be called only by the boost delegation recipient to remove an expired delegation. This design leaves the decision entirely in the hands of the recipient. If the recipient does not invoke the function after the delegation expires, the delegator is unable to reclaim their boost, potentially locking the boost indefinitely.

​

In the current implementation, the function allows only the boost recipient (i.e., the address stored in delegation.delegatedTo) to remove an expired boost delegation. The function verifies that the caller is the intended recipient and that the delegation has expired:

​

UserBoost storage delegation = userBoosts[from][msg.sender];

if (delegation.delegatedTo != msg.sender) revert DelegationNotFound();

if (delegation.expiry > block.timestamp) revert InvalidDelegationDuration();

Once these conditions are met, the function updates the pool boost totals, emits an event, and deletes the delegation record.

​

This design relies solely on the recipient to call `removeBoostDelegation()`. If the recipient is unwilling or forgets to remove the expired delegation, the boost remains delegated, and the original delegator never regains control of their boost.

​

Consider a scenario where:

​

A delegator assigns a boost to a recipient for a specified duration.

Once the delegation expires, the protocol expects the recipient to call `removeBoostDelegation()` to clear the expired delegation.

If the recipient chooses not to call this function (either out of negligence or because they benefit from keeping the boost), the delegation remains in place.

As a result, the delegator is unable to reclaim their boost, even though the delegation has expired, thereby locking the boost resource.

Locked Boost Resources: The delegator's boost remains locked in the system if the recipient does not call the removal function after expiry.

Inefficient Use of Boost: Boost resources that should be available for redelegation or reclamation by the delegator remain inaccessible, potentially distorting reward or participation calculations.

Unbalanced Incentives: The recipient might have little to no incentive to remove an expired delegation, which can leave the delegator disadvantaged and reduce overall system flexibility.

​

Allow Delegator-Initiated Removal:

Consider modifying the function or adding an alternative method that allows the delegator to remove an expired delegation if the recipient fails to do so. This change would help ensure that boost resources are not indefinitely locked.

​

Implement Automatic Removal:

Introduce an automatic removal mechanism that, upon expiry, clears expired boost delegations without requiring action from the recipient. This would guarantee that boost resources become available for redelegation or reclamation once the delegation period lapses.

​

Incentivize Removal by the Recipient:

Alternatively, design incentive mechanisms that encourage the recipient to remove expired delegations promptly, such as small rewards or penalties linked to the duration the delegation remains active past expiry.

​

By addressing these recommendations, the protocol can prevent indefinite locking of boost resources and ensure a fairer and more flexible boost delegation mechanism.